qemu-commits
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

[Qemu-commits] [qemu/qemu] c98ce2: tests: fix encoding of IP addresses i


From: Richard Henderson
Subject: [Qemu-commits] [qemu/qemu] c98ce2: tests: fix encoding of IP addresses in x509 certs
Date: Mon, 16 May 2022 14:21:32 -0700

  Branch: refs/heads/master
  Home:   https://github.com/qemu/qemu
  Commit: c98ce274dbd6373589ae01b652d88f93633db830
      
https://github.com/qemu/qemu/commit/c98ce274dbd6373589ae01b652d88f93633db830
  Author: Daniel P. Berrangé <berrange@redhat.com>
  Date:   2022-05-16 (Mon, 16 May 2022)

  Changed paths:
    M tests/unit/crypto-tls-x509-helpers.c
    M tests/unit/test-crypto-tlssession.c

  Log Message:
  -----------
  tests: fix encoding of IP addresses in x509 certs

We need to encode just the address bytes, not the whole struct sockaddr
data. Add a test case to validate that we're matching on SAN IP
addresses correctly.

Signed-off-by: Daniel P. Berrangé <berrange@redhat.com>
Message-Id: <20220426160048.812266-2-berrange@redhat.com>
Reviewed-by: Dr. David Alan Gilbert <dgilbert@redhat.com>
Signed-off-by: Dr. David Alan Gilbert <dgilbert@redhat.com>


  Commit: 5bc6364bfb496623cc7f856bdb0358ffbe3c18d2
      
https://github.com/qemu/qemu/commit/5bc6364bfb496623cc7f856bdb0358ffbe3c18d2
  Author: Daniel P. Berrangé <berrange@redhat.com>
  Date:   2022-05-16 (Mon, 16 May 2022)

  Changed paths:
    M tests/unit/crypto-tls-x509-helpers.h

  Log Message:
  -----------
  tests: add more helper macros for creating TLS x509 certs

These macros are more suited to the general consumers of certs in the
test suite, where we don't need to exercise every single possible
permutation.

Signed-off-by: Daniel P. Berrangé <berrange@redhat.com>
Message-Id: <20220426160048.812266-3-berrange@redhat.com>
Reviewed-by: Eric Blake <eblake@redhat.com>
Signed-off-by: Dr. David Alan Gilbert <dgilbert@redhat.com>


  Commit: 58d25e97f38214c04d5ba55950cc6d9fff574236
      
https://github.com/qemu/qemu/commit/58d25e97f38214c04d5ba55950cc6d9fff574236
  Author: Daniel P. Berrangé <berrange@redhat.com>
  Date:   2022-05-16 (Mon, 16 May 2022)

  Changed paths:
    M tests/qtest/meson.build
    M tests/qtest/migration-test.c
    M tests/unit/crypto-tls-psk-helpers.c
    M tests/unit/crypto-tls-psk-helpers.h

  Log Message:
  -----------
  tests: add migration tests of TLS with PSK credentials

This validates that we correctly handle migration success and failure
scenarios when using TLS with pre shared keys.

Signed-off-by: Daniel P. Berrangé <berrange@redhat.com>
Message-Id: <20220426160048.812266-4-berrange@redhat.com>
Reviewed-by: Eric Blake <eblake@redhat.com>
Signed-off-by: Dr. David Alan Gilbert <dgilbert@redhat.com>


  Commit: d47b83b118eed26e10ff4693fb1f0a433a38d0a0
      
https://github.com/qemu/qemu/commit/d47b83b118eed26e10ff4693fb1f0a433a38d0a0
  Author: Daniel P. Berrangé <berrange@redhat.com>
  Date:   2022-05-16 (Mon, 16 May 2022)

  Changed paths:
    M meson.build
    M tests/qtest/meson.build
    M tests/qtest/migration-test.c

  Log Message:
  -----------
  tests: add migration tests of TLS with x509 credentials

This validates that we correctly handle migration success and failure
scenarios when using TLS with x509 certificates. There are quite a few
different scenarios that matter in relation to hostname validation.

Signed-off-by: Daniel P. Berrangé <berrange@redhat.com>
Message-Id: <20220426160048.812266-5-berrange@redhat.com>
Reviewed-by: Eric Blake <eblake@redhat.com>
Signed-off-by: Dr. David Alan Gilbert <dgilbert@redhat.com>
  dgilbert: Manual merge due to ifdef change in 3


  Commit: 83bcba1ec1f706eb3ec0d6fdeee2bc32f95d9b1a
      
https://github.com/qemu/qemu/commit/83bcba1ec1f706eb3ec0d6fdeee2bc32f95d9b1a
  Author: Daniel P. Berrangé <berrange@redhat.com>
  Date:   2022-05-16 (Mon, 16 May 2022)

  Changed paths:
    M tests/qtest/migration-test.c

  Log Message:
  -----------
  tests: convert XBZRLE migration test to use common helper

Most of the XBZRLE migration test logic is common with the rest of the
precopy tests, so it can use the helper with just one small tweak.

Reviewed-by: Peter Xu <peterx@redhat.com>
Signed-off-by: Daniel P. Berrangé <berrange@redhat.com>
Message-Id: <20220426160048.812266-6-berrange@redhat.com>
Signed-off-by: Dr. David Alan Gilbert <dgilbert@redhat.com>


  Commit: 490facffcf21647e7088f4f0c2c5a8f5f45625e3
      
https://github.com/qemu/qemu/commit/490facffcf21647e7088f4f0c2c5a8f5f45625e3
  Author: Daniel P. Berrangé <berrange@redhat.com>
  Date:   2022-05-16 (Mon, 16 May 2022)

  Changed paths:
    M tests/qtest/migration-test.c

  Log Message:
  -----------
  tests: convert multifd migration tests to use common helper

Most of the multifd migration test logic is common with the rest of the
precopy tests, so it can use the helper without difficulty. The only
exception of the multifd cancellation test which tries to run multiple
migrations in a row.

Reviewed-by: Peter Xu <peterx@redhat.com>
Signed-off-by: Daniel P. Berrangé <berrange@redhat.com>
Message-Id: <20220426160048.812266-7-berrange@redhat.com>
Signed-off-by: Dr. David Alan Gilbert <dgilbert@redhat.com>


  Commit: 4d6d2e872a9f5aef4b08eb285a1fd7221312d562
      
https://github.com/qemu/qemu/commit/4d6d2e872a9f5aef4b08eb285a1fd7221312d562
  Author: Daniel P. Berrangé <berrange@redhat.com>
  Date:   2022-05-16 (Mon, 16 May 2022)

  Changed paths:
    M tests/qtest/migration-test.c

  Log Message:
  -----------
  tests: add multifd migration tests of TLS with PSK credentials

This validates that we correctly handle multifd migration success
and failure scenarios when using TLS with pre shared keys.

Signed-off-by: Daniel P. Berrangé <berrange@redhat.com>
Message-Id: <20220426160048.812266-8-berrange@redhat.com>
Reviewed-by: Eric Blake <eblake@redhat.com>
Signed-off-by: Dr. David Alan Gilbert <dgilbert@redhat.com>


  Commit: ff32f1dd3281d77b86d195dd62c6ec66a881b6fe
      
https://github.com/qemu/qemu/commit/ff32f1dd3281d77b86d195dd62c6ec66a881b6fe
  Author: Daniel P. Berrangé <berrange@redhat.com>
  Date:   2022-05-16 (Mon, 16 May 2022)

  Changed paths:
    M tests/qtest/migration-test.c

  Log Message:
  -----------
  tests: add multifd migration tests of TLS with x509 credentials

This validates that we correctly handle multifd migration success
and failure scenarios when using TLS with x509 certificates. There
are quite a few different scenarios that matter in relation to
hostname validation, but we skip a couple as we can assume that
the non-multifd coverage applies to some extent.

Signed-off-by: Daniel P. Berrangé <berrange@redhat.com>
Message-Id: <20220426160048.812266-9-berrange@redhat.com>
Reviewed-by: Eric Blake <eblake@redhat.com>
Signed-off-by: Dr. David Alan Gilbert <dgilbert@redhat.com>


  Commit: fd3540adb96d6f7ee7541be14f972a74c93faf3a
      
https://github.com/qemu/qemu/commit/fd3540adb96d6f7ee7541be14f972a74c93faf3a
  Author: Daniel P. Berrangé <berrange@redhat.com>
  Date:   2022-05-16 (Mon, 16 May 2022)

  Changed paths:
    M tests/qtest/migration-helpers.c
    M tests/qtest/migration-helpers.h
    M tests/qtest/migration-test.c

  Log Message:
  -----------
  tests: ensure migration status isn't reported as failed

Various methods in the migration test call 'query_migrate' to fetch the
current status and then access a particular field. Almost all of these
cases expect the migration to be in a non-failed state. In the case of
'wait_for_migration_pass' in particular, if the status is 'failed' then
it will get into an infinite loop. By validating that the status is
not 'failed' the test suite will assert rather than hang when getting
into an unexpected state.

Reviewed-by: Peter Xu <peterx@redhat.com>
Signed-off-by: Daniel P. Berrangé <berrange@redhat.com>
Message-Id: <20220426160048.812266-10-berrange@redhat.com>
Signed-off-by: Dr. David Alan Gilbert <dgilbert@redhat.com>


  Commit: 354081d43de44ebd3497fe08f7f0121a5517d528
      
https://github.com/qemu/qemu/commit/354081d43de44ebd3497fe08f7f0121a5517d528
  Author: Leonardo Bras <leobras@redhat.com>
  Date:   2022-05-16 (Mon, 16 May 2022)

  Changed paths:
    M meson.build

  Log Message:
  -----------
  meson.build: Fix docker-test-build@alpine when including linux/errqueue.h

A build error happens in alpine CI when linux/errqueue.h is included
in io/channel-socket.c, due to redefining of 'struct __kernel_timespec':

===
ninja: job failed: [...]
In file included from /usr/include/linux/errqueue.h:6,
                 from ../io/channel-socket.c:29:
/usr/include/linux/time_types.h:7:8: error: redefinition of 'struct 
__kernel_timespec'
    7 | struct __kernel_timespec {
      |        ^~~~~~~~~~~~~~~~~
In file included from /usr/include/liburing.h:19,
                 from /builds/user/qemu/include/block/aio.h:18,
                 from /builds/user/qemu/include/io/channel.h:26,
                 from /builds/user/qemu/include/io/channel-socket.h:24,
                 from ../io/channel-socket.c:24:
/usr/include/liburing/compat.h:9:8: note: originally defined here
    9 | struct __kernel_timespec {
      |        ^~~~~~~~~~~~~~~~~
ninja: subcommand failed
===

As above error message suggests, 'struct __kernel_timespec' was already
defined by liburing/compat.h.

Fix alpine CI by adding test to disable liburing in configure step if a
redefinition happens between linux/errqueue.h and liburing/compat.h.

[dgilbert: This has been fixed in Alpine issue 13813 and liburing]

Signed-off-by: Leonardo Bras <leobras@redhat.com>
Message-Id: <20220513062836.965425-2-leobras@redhat.com>
Reviewed-by: Dr. David Alan Gilbert <dgilbert@redhat.com>
Signed-off-by: Dr. David Alan Gilbert <dgilbert@redhat.com>


  Commit: b88651cb4d4fa416fdbb6afaf5b26ec8c035eaad
      
https://github.com/qemu/qemu/commit/b88651cb4d4fa416fdbb6afaf5b26ec8c035eaad
  Author: Leonardo Bras <leobras@redhat.com>
  Date:   2022-05-16 (Mon, 16 May 2022)

  Changed paths:
    M chardev/char-io.c
    M hw/remote/mpqemu-link.c
    M include/io/channel.h
    M io/channel-buffer.c
    M io/channel-command.c
    M io/channel-file.c
    M io/channel-socket.c
    M io/channel-tls.c
    M io/channel-websock.c
    M io/channel.c
    M migration/rdma.c
    M scsi/pr-manager-helper.c
    M tests/unit/test-io-channel-socket.c

  Log Message:
  -----------
  QIOChannel: Add flags on io_writev and introduce io_flush callback

Add flags to io_writev and introduce io_flush as optional callback to
QIOChannelClass, allowing the implementation of zero copy writes by
subclasses.

How to use them:
- Write data using qio_channel_writev*(...,QIO_CHANNEL_WRITE_FLAG_ZERO_COPY),
- Wait write completion with qio_channel_flush().

Notes:
As some zero copy write implementations work asynchronously, it's
recommended to keep the write buffer untouched until the return of
qio_channel_flush(), to avoid the risk of sending an updated buffer
instead of the buffer state during write.

As io_flush callback is optional, if a subclass does not implement it, then:
- io_flush will return 0 without changing anything.

Also, some functions like qio_channel_writev_full_all() were adapted to
receive a flag parameter. That allows shared code between zero copy and
non-zero copy writev, and also an easier implementation on new flags.

Signed-off-by: Leonardo Bras <leobras@redhat.com>
Reviewed-by: Daniel P. Berrangé <berrange@redhat.com>
Reviewed-by: Peter Xu <peterx@redhat.com>
Reviewed-by: Juan Quintela <quintela@redhat.com>
Message-Id: <20220513062836.965425-3-leobras@redhat.com>
Signed-off-by: Dr. David Alan Gilbert <dgilbert@redhat.com>


  Commit: 2bc58ffc2926a4efdd03edfb5909861fefc68c3d
      
https://github.com/qemu/qemu/commit/2bc58ffc2926a4efdd03edfb5909861fefc68c3d
  Author: Leonardo Bras <leobras@redhat.com>
  Date:   2022-05-16 (Mon, 16 May 2022)

  Changed paths:
    M include/io/channel-socket.h
    M io/channel-socket.c

  Log Message:
  -----------
  QIOChannelSocket: Implement io_writev zero copy flag & io_flush for 
CONFIG_LINUX

For CONFIG_LINUX, implement the new zero copy flag and the optional callback
io_flush on QIOChannelSocket, but enables it only when MSG_ZEROCOPY
feature is available in the host kernel, which is checked on
qio_channel_socket_connect_sync()

qio_channel_socket_flush() was implemented by counting how many times
sendmsg(...,MSG_ZEROCOPY) was successfully called, and then reading the
socket's error queue, in order to find how many of them finished sending.
Flush will loop until those counters are the same, or until some error occurs.

Notes on using writev() with QIO_CHANNEL_WRITE_FLAG_ZERO_COPY:
1: Buffer
- As MSG_ZEROCOPY tells the kernel to use the same user buffer to avoid copying,
some caution is necessary to avoid overwriting any buffer before it's sent.
If something like this happen, a newer version of the buffer may be sent 
instead.
- If this is a problem, it's recommended to call qio_channel_flush() before 
freeing
or re-using the buffer.

2: Locked memory
- When using MSG_ZERCOCOPY, the buffer memory will be locked after queued, and
unlocked after it's sent.
- Depending on the size of each buffer, and how often it's sent, it may require
a larger amount of locked memory than usually available to non-root user.
- If the required amount of locked memory is not available, writev_zero_copy
will return an error, which can abort an operation like migration,
- Because of this, when an user code wants to add zero copy as a feature, it
requires a mechanism to disable it, so it can still be accessible to less
privileged users.

Signed-off-by: Leonardo Bras <leobras@redhat.com>
Reviewed-by: Peter Xu <peterx@redhat.com>
Reviewed-by: Daniel P. Berrangé <berrange@redhat.com>
Reviewed-by: Juan Quintela <quintela@redhat.com>
Message-Id: <20220513062836.965425-4-leobras@redhat.com>
Signed-off-by: Dr. David Alan Gilbert <dgilbert@redhat.com>


  Commit: abb6295b3ace5d17c3a65936913fc346616dbf14
      
https://github.com/qemu/qemu/commit/abb6295b3ace5d17c3a65936913fc346616dbf14
  Author: Leonardo Bras <leobras@redhat.com>
  Date:   2022-05-16 (Mon, 16 May 2022)

  Changed paths:
    M migration/migration.c
    M migration/migration.h
    M migration/socket.c
    M monitor/hmp-cmds.c
    M qapi/migration.json

  Log Message:
  -----------
  migration: Add zero-copy-send parameter for QMP/HMP for Linux

Add property that allows zero-copy migration of memory pages
on the sending side, and also includes a helper function
migrate_use_zero_copy_send() to check if it's enabled.

No code is introduced to actually do the migration, but it allow
future implementations to enable/disable this feature.

On non-Linux builds this parameter is compiled-out.

Signed-off-by: Leonardo Bras <leobras@redhat.com>
Reviewed-by: Peter Xu <peterx@redhat.com>
Reviewed-by: Daniel P. Berrangé <berrange@redhat.com>
Reviewed-by: Juan Quintela <quintela@redhat.com>
Acked-by: Markus Armbruster <armbru@redhat.com>
Message-Id: <20220513062836.965425-5-leobras@redhat.com>
Signed-off-by: Dr. David Alan Gilbert <dgilbert@redhat.com>


  Commit: d2fafb6a6814a8998607d0baf691265032996a0f
      
https://github.com/qemu/qemu/commit/d2fafb6a6814a8998607d0baf691265032996a0f
  Author: Leonardo Bras <leobras@redhat.com>
  Date:   2022-05-16 (Mon, 16 May 2022)

  Changed paths:
    M migration/channel.c
    M migration/migration.c
    M migration/migration.h
    M migration/multifd.c

  Log Message:
  -----------
  migration: Add migrate_use_tls() helper

A lot of places check parameters.tls_creds in order to evaluate if TLS is
in use, and sometimes call migrate_get_current() just for that test.

Add new helper function migrate_use_tls() in order to simplify testing
for TLS usage.

Signed-off-by: Leonardo Bras <leobras@redhat.com>
Reviewed-by: Juan Quintela <quintela@redhat.com>
Reviewed-by: Peter Xu <peterx@redhat.com>
Reviewed-by: Daniel P. Berrangé <berrange@redhat.com>
Message-Id: <20220513062836.965425-6-leobras@redhat.com>
Signed-off-by: Dr. David Alan Gilbert <dgilbert@redhat.com>


  Commit: 33d70973a3a6e8c6b62bcbc64d9e488961981007
      
https://github.com/qemu/qemu/commit/33d70973a3a6e8c6b62bcbc64d9e488961981007
  Author: Leonardo Bras <leobras@redhat.com>
  Date:   2022-05-16 (Mon, 16 May 2022)

  Changed paths:
    M migration/multifd.c
    M migration/multifd.h
    M migration/ram.c

  Log Message:
  -----------
  multifd: multifd_send_sync_main now returns negative on error

Even though multifd_send_sync_main() currently emits error_reports, it's
callers don't really check it before continuing.

Change multifd_send_sync_main() to return -1 on error and 0 on success.
Also change all it's callers to make use of this change and possibly fail
earlier.

(This change is important to next patch on  multifd zero copy
implementation, to make it sure an error in zero-copy flush does not go
unnoticed.

Signed-off-by: Leonardo Bras <leobras@redhat.com>
Reviewed-by: Daniel P. Berrangé <berrange@redhat.com>
Reviewed-by: Peter Xu <peterx@redhat.com>
Message-Id: <20220513062836.965425-7-leobras@redhat.com>
Signed-off-by: Dr. David Alan Gilbert <dgilbert@redhat.com>


  Commit: b7dbdd8e76cd03453c234dbb9578d20969859d74
      
https://github.com/qemu/qemu/commit/b7dbdd8e76cd03453c234dbb9578d20969859d74
  Author: Leonardo Bras <leobras@redhat.com>
  Date:   2022-05-16 (Mon, 16 May 2022)

  Changed paths:
    M migration/multifd.c

  Log Message:
  -----------
  multifd: Send header packet without flags if zero-copy-send is enabled

Since d48c3a0445 ("multifd: Use a single writev on the send side"),
sending the header packet and the memory pages happens in the same
writev, which can potentially make the migration faster.

Using channel-socket as example, this works well with the default copying
mechanism of sendmsg(), but with zero-copy-send=true, it will cause
the migration to often break.

This happens because the header packet buffer gets reused quite often,
and there is a high chance that by the time the MSG_ZEROCOPY mechanism get
to send the buffer, it has already changed, sending the wrong data and
causing the migration to abort.

It means that, as it is, the buffer for the header packet is not suitable
for sending with MSG_ZEROCOPY.

In order to enable zero copy for multifd, send the header packet on an
individual write(), without any flags, and the remanining pages with a
writev(), as it was happening before. This only changes how a migration
with zero-copy-send=true works, not changing any current behavior for
migrations with zero-copy-send=false.

Signed-off-by: Leonardo Bras <leobras@redhat.com>
Reviewed-by: Peter Xu <peterx@redhat.com>
Reviewed-by: Daniel P. Berrangé <berrange@redhat.com>
Message-Id: <20220513062836.965425-8-leobras@redhat.com>
Signed-off-by: Dr. David Alan Gilbert <dgilbert@redhat.com>


  Commit: 5b1d9bab2da4fca3a3caee97c430e5709cb32b7b
      
https://github.com/qemu/qemu/commit/5b1d9bab2da4fca3a3caee97c430e5709cb32b7b
  Author: Leonardo Bras <leobras@redhat.com>
  Date:   2022-05-16 (Mon, 16 May 2022)

  Changed paths:
    M migration/migration.c
    M migration/multifd.c
    M migration/multifd.h
    M migration/socket.c

  Log Message:
  -----------
  multifd: Implement zero copy write in multifd migration (multifd-zero-copy)

Implement zero copy send on nocomp_send_write(), by making use of QIOChannel
writev + flags & flush interface.

Change multifd_send_sync_main() so flush_zero_copy() can be called
after each iteration in order to make sure all dirty pages are sent before
a new iteration is started. It will also flush at the beginning and at the
end of migration.

Also make it return -1 if flush_zero_copy() fails, in order to cancel
the migration process, and avoid resuming the guest in the target host
without receiving all current RAM.

This will work fine on RAM migration because the RAM pages are not usually 
freed,
and there is no problem on changing the pages content between 
writev_zero_copy() and
the actual sending of the buffer, because this change will dirty the page and
cause it to be re-sent on a next iteration anyway.

A lot of locked memory may be needed in order to use multifd migration
with zero-copy enabled, so disabling the feature should be necessary for
low-privileged users trying to perform multifd migrations.

Signed-off-by: Leonardo Bras <leobras@redhat.com>
Reviewed-by: Peter Xu <peterx@redhat.com>
Reviewed-by: Daniel P. Berrangé <berrange@redhat.com>
Message-Id: <20220513062836.965425-9-leobras@redhat.com>
Signed-off-by: Dr. David Alan Gilbert <dgilbert@redhat.com>


  Commit: 54b592c427ca2575187082b35d5d6ae85db59f7b
      
https://github.com/qemu/qemu/commit/54b592c427ca2575187082b35d5d6ae85db59f7b
  Author: Richard Henderson <richard.henderson@linaro.org>
  Date:   2022-05-16 (Mon, 16 May 2022)

  Changed paths:
    M chardev/char-io.c
    M hw/remote/mpqemu-link.c
    M include/io/channel-socket.h
    M include/io/channel.h
    M io/channel-buffer.c
    M io/channel-command.c
    M io/channel-file.c
    M io/channel-socket.c
    M io/channel-tls.c
    M io/channel-websock.c
    M io/channel.c
    M meson.build
    M migration/channel.c
    M migration/migration.c
    M migration/migration.h
    M migration/multifd.c
    M migration/multifd.h
    M migration/ram.c
    M migration/rdma.c
    M migration/socket.c
    M monitor/hmp-cmds.c
    M qapi/migration.json
    M scsi/pr-manager-helper.c
    M tests/qtest/meson.build
    M tests/qtest/migration-helpers.c
    M tests/qtest/migration-helpers.h
    M tests/qtest/migration-test.c
    M tests/unit/crypto-tls-psk-helpers.c
    M tests/unit/crypto-tls-psk-helpers.h
    M tests/unit/crypto-tls-x509-helpers.c
    M tests/unit/crypto-tls-x509-helpers.h
    M tests/unit/test-crypto-tlssession.c
    M tests/unit/test-io-channel-socket.c

  Log Message:
  -----------
  Merge tag 'pull-migration-20220516a' of https://gitlab.com/dagrh/qemu into 
staging

Migration pull 2022-05-16

(This replaces the 28th April through 10th May sets)
Compared to that last set it just has the Alpine
uring check that Leo has added; although that's also
now fixed upstream in Alpine.

It contains:
  TLS test fixes from Dan
  Zerocopy migration feature from Leo

Signed-off-by: Dr. David Alan Gilbert <dgilbert@redhat.com>

# -----BEGIN PGP SIGNATURE-----
#
# iQIzBAABCAAdFiEERfXHG0oMt/uXep+pBRYzHrxb/ecFAmKCY80ACgkQBRYzHrxb
# /eeEEhAAoUogch7ifxFItr1EA0AU6Sgd3Dcn8wY9pm0NySVg7OcIpk1H++A3CgIh
# bubJSwRmpIxGw+5q5w5OvBukFCGYMlAK7J8k1tZmaqdKS8wD0ZwhpPyqTWd14Q/v
# xXSGOQfHMMvbBILiXPjSkfNw8yKJhZr+lW39uMz/kZRwZUmTcrdKAT3Q8PW+1DI9
# v3mNoFNXqtDlHcQ4nQ1TGk/RDO6oXDlTJwdnjoJT3Dopf8Jhl2etvZgVk2kOf4i5
# LmJbSVBr5FNOhJ6P4WL4OEQFOiXXquKdfuGTXIGGhkrW2WkPZulQwB6uO4Gv1wf2
# aj9bLDAFoPxFx2zYS6S/9L6rGeBMcTL9xHCfzyylM6YRjoscRdxXc67PClw71JUy
# regsoSQej0FpmsGx0uuAsDjCELleVIjeYzuQo5OYOP1BCg/5unLIrMgkyQw7COJI
# w+MIZq7IqvUTehU2yXpUGOqPkyDLBlib92dMRgqqG9r9UU7iL3BREbGW4ugW+GM2
# a9k8W9HjyDIIODsdXy1ugPHgjr/arHDAPgYosJMLvjTfdJDcIldAw6CbCcqhCDES
# UOjMVN9VS+716nY2AqvtEHxf47YwqmeRb+tg4SQ0dHLH5Pvfe2bk1sbZiiQpcelt
# Bd88yeBOpcmdzJVur2V4fEZXu5JB/qt/jeJeQa82hS3k93PWm/w=
# =Axhk
# -----END PGP SIGNATURE-----
# gpg: Signature made Mon 16 May 2022 07:46:37 AM PDT
# gpg:                using RSA key 45F5C71B4A0CB7FB977A9FA90516331EBC5BFDE7
# gpg: Good signature from "Dr. David Alan Gilbert (RH2) <dgilbert@redhat.com>" 
[full]

* tag 'pull-migration-20220516a' of https://gitlab.com/dagrh/qemu:
  multifd: Implement zero copy write in multifd migration (multifd-zero-copy)
  multifd: Send header packet without flags if zero-copy-send is enabled
  multifd: multifd_send_sync_main now returns negative on error
  migration: Add migrate_use_tls() helper
  migration: Add zero-copy-send parameter for QMP/HMP for Linux
  QIOChannelSocket: Implement io_writev zero copy flag & io_flush for 
CONFIG_LINUX
  QIOChannel: Add flags on io_writev and introduce io_flush callback
  meson.build: Fix docker-test-build@alpine when including linux/errqueue.h
  tests: ensure migration status isn't reported as failed
  tests: add multifd migration tests of TLS with x509 credentials
  tests: add multifd migration tests of TLS with PSK credentials
  tests: convert multifd migration tests to use common helper
  tests: convert XBZRLE migration test to use common helper
  tests: add migration tests of TLS with x509 credentials
  tests: add migration tests of TLS with PSK credentials
  tests: add more helper macros for creating TLS x509 certs
  tests: fix encoding of IP addresses in x509 certs

Signed-off-by: Richard Henderson <richard.henderson@linaro.org>


Compare: https://github.com/qemu/qemu/compare/b935385c351d...54b592c427ca



reply via email to

[Prev in Thread] Current Thread [Next in Thread]