[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
[Qemu-commits] [qemu/qemu] 1667e2: accel/kvm/kvm-all: Refactor per-vcpu
|
From: |
Peter Maydell |
|
Subject: |
[Qemu-commits] [qemu/qemu] 1667e2: accel/kvm/kvm-all: Refactor per-vcpu dirty ring re... |
|
Date: |
Thu, 21 Jul 2022 03:12:15 -0700 |
Branch: refs/heads/master
Home: https://github.com/qemu/qemu
Commit: 1667e2b97ba2f268a77611db80230609523a83ee
https://github.com/qemu/qemu/commit/1667e2b97ba2f268a77611db80230609523a83ee
Author: Hyman Huang(黄勇) <huangy81@chinatelecom.cn>
Date: 2022-07-20 (Wed, 20 Jul 2022)
Changed paths:
M accel/kvm/kvm-all.c
Log Message:
-----------
accel/kvm/kvm-all: Refactor per-vcpu dirty ring reaping
Add a non-required argument 'CPUState' to kvm_dirty_ring_reap so
that it can cover single vcpu dirty-ring-reaping scenario.
Signed-off-by: Hyman Huang(黄勇) <huangy81@chinatelecom.cn>
Reviewed-by: Peter Xu <peterx@redhat.com>
Message-Id:
<c32001242875e83b0d9f78f396fe2dcd380ba9e8.1656177590.git.huangy81@chinatelecom.cn>
Signed-off-by: Dr. David Alan Gilbert <dgilbert@redhat.com>
Commit: ab1a161fe36be08eb1fbd0bc404e51a99e9d1471
https://github.com/qemu/qemu/commit/ab1a161fe36be08eb1fbd0bc404e51a99e9d1471
Author: Hyman Huang(黄勇) <huangy81@chinatelecom.cn>
Date: 2022-07-20 (Wed, 20 Jul 2022)
Changed paths:
M cpus-common.c
M include/exec/cpu-common.h
Log Message:
-----------
cpus: Introduce cpu_list_generation_id
Introduce cpu_list_generation_id to track cpu list generation so
that cpu hotplug/unplug can be detected during measurement of
dirty page rate.
cpu_list_generation_id could be used to detect changes of cpu
list, which is prepared for dirty page rate measurement.
Signed-off-by: Hyman Huang(黄勇) <huangy81@chinatelecom.cn>
Reviewed-by: Peter Xu <peterx@redhat.com>
Message-Id:
<06e1f1362b2501a471dce796abb065b04f320fa5.1656177590.git.huangy81@chinatelecom.cn>
Signed-off-by: Dr. David Alan Gilbert <dgilbert@redhat.com>
Commit: 8244166dec65eb295d09787021522d38171b06c7
https://github.com/qemu/qemu/commit/8244166dec65eb295d09787021522d38171b06c7
Author: Hyman Huang(黄勇) <huangy81@chinatelecom.cn>
Date: 2022-07-20 (Wed, 20 Jul 2022)
Changed paths:
A include/sysemu/dirtyrate.h
M migration/dirtyrate.c
M migration/dirtyrate.h
Log Message:
-----------
migration/dirtyrate: Refactor dirty page rate calculation
abstract out dirty log change logic into function
global_dirty_log_change.
abstract out dirty page rate calculation logic via
dirty-ring into function vcpu_calculate_dirtyrate.
abstract out mathematical dirty page rate calculation
into do_calculate_dirtyrate, decouple it from DirtyStat.
rename set_sample_page_period to dirty_stat_wait, which
is well-understood and will be reused in dirtylimit.
handle cpu hotplug/unplug scenario during measurement of
dirty page rate.
export util functions outside migration.
Signed-off-by: Hyman Huang(黄勇) <huangy81@chinatelecom.cn>
Reviewed-by: Peter Xu <peterx@redhat.com>
Message-Id:
<7b6f6f4748d5b3d017b31a0429e630229ae97538.1656177590.git.huangy81@chinatelecom.cn>
Signed-off-by: Dr. David Alan Gilbert <dgilbert@redhat.com>
Commit: cc2b33eab03710ae9dcb3ff68e8fcc634d1e9ad2
https://github.com/qemu/qemu/commit/cc2b33eab03710ae9dcb3ff68e8fcc634d1e9ad2
Author: Hyman Huang(黄勇) <huangy81@chinatelecom.cn>
Date: 2022-07-20 (Wed, 20 Jul 2022)
Changed paths:
M include/exec/memory.h
A include/sysemu/dirtylimit.h
A softmmu/dirtylimit.c
M softmmu/meson.build
Log Message:
-----------
softmmu/dirtylimit: Implement vCPU dirtyrate calculation periodically
Introduce the third method GLOBAL_DIRTY_LIMIT of dirty
tracking for calculate dirtyrate periodly for dirty page
rate limit.
Add dirtylimit.c to implement dirtyrate calculation periodly,
which will be used for dirty page rate limit.
Add dirtylimit.h to export util functions for dirty page rate
limit implementation.
Signed-off-by: Hyman Huang(黄勇) <huangy81@chinatelecom.cn>
Reviewed-by: Peter Xu <peterx@redhat.com>
Message-Id:
<5d0d641bffcb9b1c4cc3e323b6dfecb36050d948.1656177590.git.huangy81@chinatelecom.cn>
Signed-off-by: Dr. David Alan Gilbert <dgilbert@redhat.com>
Commit: 4a06a7cc053deae16864359a5149bcb4442f8d2a
https://github.com/qemu/qemu/commit/4a06a7cc053deae16864359a5149bcb4442f8d2a
Author: Hyman Huang(黄勇) <huangy81@chinatelecom.cn>
Date: 2022-07-20 (Wed, 20 Jul 2022)
Changed paths:
M accel/kvm/kvm-all.c
M accel/stubs/kvm-stub.c
M include/sysemu/kvm.h
Log Message:
-----------
accel/kvm/kvm-all: Introduce kvm_dirty_ring_size function
Introduce kvm_dirty_ring_size util function to help calculate
dirty ring ful time.
Signed-off-by: Hyman Huang(黄勇) <huangy81@chinatelecom.cn>
Acked-by: Peter Xu <peterx@redhat.com>
Message-Id:
<f9ce1f550bfc0e3a1f711e17b1dbc8f701700e56.1656177590.git.huangy81@chinatelecom.cn>
Signed-off-by: Dr. David Alan Gilbert <dgilbert@redhat.com>
Commit: baa609832e1849915b62be2abfbdc1d0e5909a7b
https://github.com/qemu/qemu/commit/baa609832e1849915b62be2abfbdc1d0e5909a7b
Author: Hyman Huang(黄勇) <huangy81@chinatelecom.cn>
Date: 2022-07-20 (Wed, 20 Jul 2022)
Changed paths:
M accel/kvm/kvm-all.c
M include/hw/core/cpu.h
M include/sysemu/dirtylimit.h
M softmmu/dirtylimit.c
M softmmu/trace-events
Log Message:
-----------
softmmu/dirtylimit: Implement virtual CPU throttle
Setup a negative feedback system when vCPU thread
handling KVM_EXIT_DIRTY_RING_FULL exit by introducing
throttle_us_per_full field in struct CPUState. Sleep
throttle_us_per_full microseconds to throttle vCPU
if dirtylimit is in service.
Signed-off-by: Hyman Huang(黄勇) <huangy81@chinatelecom.cn>
Reviewed-by: Peter Xu <peterx@redhat.com>
Message-Id:
<977e808e03a1cef5151cae75984658b6821be618.1656177590.git.huangy81@chinatelecom.cn>
Signed-off-by: Dr. David Alan Gilbert <dgilbert@redhat.com>
Commit: f3b2e38cfb2ecabe53b96752ebdf80b541a520ab
https://github.com/qemu/qemu/commit/f3b2e38cfb2ecabe53b96752ebdf80b541a520ab
Author: Hyman Huang(黄勇) <huangy81@chinatelecom.cn>
Date: 2022-07-20 (Wed, 20 Jul 2022)
Changed paths:
M hmp-commands-info.hx
M hmp-commands.hx
M include/monitor/hmp.h
M qapi/migration.json
M softmmu/dirtylimit.c
M tests/qtest/qmp-cmd-test.c
Log Message:
-----------
softmmu/dirtylimit: Implement dirty page rate limit
Implement dirtyrate calculation periodically basing on
dirty-ring and throttle virtual CPU until it reachs the quota
dirty page rate given by user.
Introduce qmp commands "set-vcpu-dirty-limit",
"cancel-vcpu-dirty-limit", "query-vcpu-dirty-limit"
to enable, disable, query dirty page limit for virtual CPU.
Meanwhile, introduce corresponding hmp commands
"set_vcpu_dirty_limit", "cancel_vcpu_dirty_limit",
"info vcpu_dirty_limit" so the feature can be more usable.
"query-vcpu-dirty-limit" success depends on enabling dirty
page rate limit, so just add it to the list of skipped
command to ensure qmp-cmd-test run successfully.
Signed-off-by: Hyman Huang(黄勇) <huangy81@chinatelecom.cn>
Acked-by: Markus Armbruster <armbru@redhat.com>
Reviewed-by: Peter Xu <peterx@redhat.com>
Message-Id:
<4143f26706d413dd29db0b672fe58b3d3fbe34bc.1656177590.git.huangy81@chinatelecom.cn>
Signed-off-by: Dr. David Alan Gilbert <dgilbert@redhat.com>
Commit: 8aff6f501d3561127e3425bbf0ebd936b3b92d0c
https://github.com/qemu/qemu/commit/8aff6f501d3561127e3425bbf0ebd936b3b92d0c
Author: Hyman Huang(黄勇) <huangy81@chinatelecom.cn>
Date: 2022-07-20 (Wed, 20 Jul 2022)
Changed paths:
M tests/qtest/migration-helpers.c
M tests/qtest/migration-helpers.h
M tests/qtest/migration-test.c
Log Message:
-----------
tests: Add dirty page rate limit test
Add dirty page rate limit test if kernel support dirty ring,
The following qmp commands are covered by this test case:
"calc-dirty-rate", "query-dirty-rate", "set-vcpu-dirty-limit",
"cancel-vcpu-dirty-limit" and "query-vcpu-dirty-limit".
Signed-off-by: Hyman Huang(黄勇) <huangy81@chinatelecom.cn>
Acked-by: Peter Xu <peterx@redhat.com>
Message-Id:
<eed5b847a6ef0a9c02a36383dbdd7db367dd1e7e.1656177590.git.huangy81@chinatelecom.cn>
Signed-off-by: Dr. David Alan Gilbert <dgilbert@redhat.com>
Commit: 007e179ef0e97eafda4c9ff2a9d665a1947c7c6d
https://github.com/qemu/qemu/commit/007e179ef0e97eafda4c9ff2a9d665a1947c7c6d
Author: Ilya Leoshkevich <iii@linux.ibm.com>
Date: 2022-07-20 (Wed, 20 Jul 2022)
Changed paths:
M migration/multifd-zlib.c
Log Message:
-----------
multifd: Copy pages before compressing them with zlib
zlib_send_prepare() compresses pages of a running VM. zlib does not
make any thread-safety guarantees with respect to changing deflate()
input concurrently with deflate() [1].
One can observe problems due to this with the IBM zEnterprise Data
Compression accelerator capable zlib [2]. When the hardware
acceleration is enabled, migration/multifd/tcp/plain/zlib test fails
intermittently [3] due to sliding window corruption. The accelerator's
architecture explicitly discourages concurrent accesses [4]:
Page 26-57, "Other Conditions":
As observed by this CPU, other CPUs, and channel
programs, references to the parameter block, first,
second, and third operands may be multiple-access
references, accesses to these storage locations are
not necessarily block-concurrent, and the sequence
of these accesses or references is undefined.
Mark Adler pointed out that vanilla zlib performs double fetches under
certain circumstances as well [5], therefore we need to copy data
before passing it to deflate().
[1] https://zlib.net/manual.html
[2] https://github.com/madler/zlib/pull/410
[3] https://lists.nongnu.org/archive/html/qemu-devel/2022-03/msg03988.html
[4] http://publibfp.dhe.ibm.com/epubs/pdf/a227832c.pdf
[5] https://lists.gnu.org/archive/html/qemu-devel/2022-07/msg00889.html
Signed-off-by: Ilya Leoshkevich <iii@linux.ibm.com>
Message-Id: <20220705203559.2960949-1-iii@linux.ibm.com>
Reviewed-by: Dr. David Alan Gilbert <dgilbert@redhat.com>
Signed-off-by: Dr. David Alan Gilbert <dgilbert@redhat.com>
Commit: ce5b0f4afc60124e2fdc81b27ef0de3875bbb9f0
https://github.com/qemu/qemu/commit/ce5b0f4afc60124e2fdc81b27ef0de3875bbb9f0
Author: Peter Xu <peterx@redhat.com>
Date: 2022-07-20 (Wed, 20 Jul 2022)
Changed paths:
M migration/migration.c
M migration/migration.h
M qapi/migration.json
Log Message:
-----------
migration: Add postcopy-preempt capability
Firstly, postcopy already preempts precopy due to the fact that we do
unqueue_page() first before looking into dirty bits.
However that's not enough, e.g., when there're host huge page enabled, when
sending a precopy huge page, a postcopy request needs to wait until the whole
huge page that is sending to finish. That could introduce quite some delay,
the bigger the huge page is the larger delay it'll bring.
This patch adds a new capability to allow postcopy requests to preempt existing
precopy page during sending a huge page, so that postcopy requests can be
serviced even faster.
Meanwhile to send it even faster, bypass the precopy stream by providing a
standalone postcopy socket for sending requested pages.
Since the new behavior will not be compatible with the old behavior, this will
not be the default, it's enabled only when the new capability is set on both
src/dst QEMUs.
This patch only adds the capability itself, the logic will be added in follow
up patches.
Reviewed-by: Dr. David Alan Gilbert <dgilbert@redhat.com>
Reviewed-by: Juan Quintela <quintela@redhat.com>
Signed-off-by: Peter Xu <peterx@redhat.com>
Message-Id: <20220707185342.26794-2-peterx@redhat.com>
Signed-off-by: Dr. David Alan Gilbert <dgilbert@redhat.com>
Commit: 36f62f11e44b8a0a653998da100be307ac98704d
https://github.com/qemu/qemu/commit/36f62f11e44b8a0a653998da100be307ac98704d
Author: Peter Xu <peterx@redhat.com>
Date: 2022-07-20 (Wed, 20 Jul 2022)
Changed paths:
M migration/migration.c
M migration/migration.h
M migration/postcopy-ram.c
M migration/postcopy-ram.h
M migration/ram.c
M migration/ram.h
M migration/savevm.c
M migration/socket.c
M migration/socket.h
M migration/trace-events
Log Message:
-----------
migration: Postcopy preemption preparation on channel creation
Create a new socket for postcopy to be prepared to send postcopy requested
pages via this specific channel, so as to not get blocked by precopy pages.
A new thread is also created on dest qemu to receive data from this new channel
based on the ram_load_postcopy() routine.
The ram_load_postcopy(POSTCOPY) branch and the thread has not started to
function, and that'll be done in follow up patches.
Cleanup the new sockets on both src/dst QEMUs, meanwhile look after the new
thread too to make sure it'll be recycled properly.
Reviewed-by: Daniel P. Berrangé <berrange@redhat.com>
Reviewed-by: Juan Quintela <quintela@redhat.com>
Signed-off-by: Peter Xu <peterx@redhat.com>
Message-Id: <20220707185502.27149-1-peterx@redhat.com>
Signed-off-by: Dr. David Alan Gilbert <dgilbert@redhat.com>
dgilbert: With Peter's fix to quieten compiler warning on
start_migration
Commit: c01b16edf6a22f28c2a943652c82d18fccc527b7
https://github.com/qemu/qemu/commit/c01b16edf6a22f28c2a943652c82d18fccc527b7
Author: Peter Xu <peterx@redhat.com>
Date: 2022-07-20 (Wed, 20 Jul 2022)
Changed paths:
M migration/migration.c
M migration/migration.h
M migration/ram.c
M migration/trace-events
Log Message:
-----------
migration: Postcopy preemption enablement
This patch enables postcopy-preempt feature.
It contains two major changes to the migration logic:
(1) Postcopy requests are now sent via a different socket from precopy
background migration stream, so as to be isolated from very high page
request delays.
(2) For huge page enabled hosts: when there's postcopy requests, they can now
intercept a partial sending of huge host pages on src QEMU.
After this patch, we'll live migrate a VM with two channels for postcopy: (1)
PRECOPY channel, which is the default channel that transfers background pages;
and (2) POSTCOPY channel, which only transfers requested pages.
There's no strict rule of which channel to use, e.g., if a requested page is
already being transferred on precopy channel, then we will keep using the same
precopy channel to transfer the page even if it's explicitly requested. In 99%
of the cases we'll prioritize the channels so we send requested page via the
postcopy channel as long as possible.
On the source QEMU, when we found a postcopy request, we'll interrupt the
PRECOPY channel sending process and quickly switch to the POSTCOPY channel.
After we serviced all the high priority postcopy pages, we'll switch back to
PRECOPY channel so that we'll continue to send the interrupted huge page again.
There's no new thread introduced on src QEMU.
On the destination QEMU, one new thread is introduced to receive page data from
the postcopy specific socket (done in the preparation patch).
This patch has a side effect: after sending postcopy pages, previously we'll
assume the guest will access follow up pages so we'll keep sending from there.
Now it's changed. Instead of going on with a postcopy requested page, we'll go
back and continue sending the precopy huge page (which can be intercepted by a
postcopy request so the huge page can be sent partially before).
Whether that's a problem is debatable, because "assuming the guest will
continue to access the next page" may not really suite when huge pages are
used, especially if the huge page is large (e.g. 1GB pages). So that locality
hint is much meaningless if huge pages are used.
Reviewed-by: Dr. David Alan Gilbert <dgilbert@redhat.com>
Signed-off-by: Peter Xu <peterx@redhat.com>
Message-Id: <20220707185504.27203-1-peterx@redhat.com>
Signed-off-by: Dr. David Alan Gilbert <dgilbert@redhat.com>
Commit: 60bb3c5871a7f7b7cfff5d0a30a035e30cce8e42
https://github.com/qemu/qemu/commit/60bb3c5871a7f7b7cfff5d0a30a035e30cce8e42
Author: Peter Xu <peterx@redhat.com>
Date: 2022-07-20 (Wed, 20 Jul 2022)
Changed paths:
M migration/migration.c
M migration/migration.h
M migration/postcopy-ram.c
M migration/qemu-file.c
M migration/qemu-file.h
M migration/savevm.c
M migration/trace-events
Log Message:
-----------
migration: Postcopy recover with preempt enabled
To allow postcopy recovery, the ram fast load (preempt-only) dest QEMU thread
needs similar handling on fault tolerance. When ram_load_postcopy() fails,
instead of stopping the thread it halts with a semaphore, preparing to be
kicked again when recovery is detected.
A mutex is introduced to make sure there's no concurrent operation upon the
socket. To make it simple, the fast ram load thread will take the mutex during
its whole procedure, and only release it if it's paused. The fast-path socket
will be properly released by the main loading thread safely when there's
network failures during postcopy with that mutex held.
Reviewed-by: Dr. David Alan Gilbert <dgilbert@redhat.com>
Signed-off-by: Peter Xu <peterx@redhat.com>
Message-Id: <20220707185506.27257-1-peterx@redhat.com>
Signed-off-by: Dr. David Alan Gilbert <dgilbert@redhat.com>
Commit: d0edb8a173b54cae4571c9040c88cf0c5a1c6e12
https://github.com/qemu/qemu/commit/d0edb8a173b54cae4571c9040c88cf0c5a1c6e12
Author: Peter Xu <peterx@redhat.com>
Date: 2022-07-20 (Wed, 20 Jul 2022)
Changed paths:
M migration/migration.c
M migration/migration.h
M migration/postcopy-ram.c
M migration/postcopy-ram.h
Log Message:
-----------
migration: Create the postcopy preempt channel asynchronously
This patch allows the postcopy preempt channel to be created
asynchronously. The benefit is that when the connection is slow, we won't
take the BQL (and potentially block all things like QMP) for a long time
without releasing.
A function postcopy_preempt_wait_channel() is introduced, allowing the
migration thread to be able to wait on the channel creation. The channel
is always created by the main thread, in which we'll kick a new semaphore
to tell the migration thread that the channel has created.
We'll need to wait for the new channel in two places: (1) when there's a
new postcopy migration that is starting, or (2) when there's a postcopy
migration to resume.
For the start of migration, we don't need to wait for this channel until
when we want to start postcopy, aka, postcopy_start(). We'll fail the
migration if we found that the channel creation failed (which should
probably not happen at all in 99% of the cases, because the main channel is
using the same network topology).
For a postcopy recovery, we'll need to wait in postcopy_pause(). In that
case if the channel creation failed, we can't fail the migration or we'll
crash the VM, instead we keep in PAUSED state, waiting for yet another
recovery.
Reviewed-by: Dr. David Alan Gilbert <dgilbert@redhat.com>
Reviewed-by: Manish Mishra <manish.mishra@nutanix.com>
Signed-off-by: Peter Xu <peterx@redhat.com>
Message-Id: <20220707185509.27311-1-peterx@redhat.com>
Signed-off-by: Dr. David Alan Gilbert <dgilbert@redhat.com>
Commit: c8750de11810ddca96026fc0edf87b64c1350f76
https://github.com/qemu/qemu/commit/c8750de11810ddca96026fc0edf87b64c1350f76
Author: Peter Xu <peterx@redhat.com>
Date: 2022-07-20 (Wed, 20 Jul 2022)
Changed paths:
M migration/migration.c
M migration/migration.h
M migration/ram.c
Log Message:
-----------
migration: Add property x-postcopy-preempt-break-huge
Add a property field that can conditionally disable the "break sending huge
page" behavior in postcopy preemption. By default it's enabled.
It should only be used for debugging purposes, and we should never remove
the "x-" prefix.
Reviewed-by: Dr. David Alan Gilbert <dgilbert@redhat.com>
Reviewed-by: Manish Mishra <manish.mishra@nutanix.com>
Signed-off-by: Peter Xu <peterx@redhat.com>
Message-Id: <20220707185511.27366-1-peterx@redhat.com>
Signed-off-by: Dr. David Alan Gilbert <dgilbert@redhat.com>
Commit: 85a8578ea501029f10f5d19d88115adee0ae10cc
https://github.com/qemu/qemu/commit/85a8578ea501029f10f5d19d88115adee0ae10cc
Author: Peter Xu <peterx@redhat.com>
Date: 2022-07-20 (Wed, 20 Jul 2022)
Changed paths:
M migration/channel.c
M migration/migration.c
M migration/multifd.c
M migration/tls.c
M migration/tls.h
Log Message:
-----------
migration: Add helpers to detect TLS capability
Add migrate_channel_requires_tls() to detect whether the specific channel
requires TLS, leveraging the recently introduced migrate_use_tls(). No
functional change intended.
Reviewed-by: Dr. David Alan Gilbert <dgilbert@redhat.com>
Signed-off-by: Peter Xu <peterx@redhat.com>
Message-Id: <20220707185513.27421-1-peterx@redhat.com>
Signed-off-by: Dr. David Alan Gilbert <dgilbert@redhat.com>
Commit: 9a2666275215048c73f1d66f7d57d7ea32328082
https://github.com/qemu/qemu/commit/9a2666275215048c73f1d66f7d57d7ea32328082
Author: Peter Xu <peterx@redhat.com>
Date: 2022-07-20 (Wed, 20 Jul 2022)
Changed paths:
M migration/migration.c
Log Message:
-----------
migration: Export tls-[creds|hostname|authz] params to cmdline too
It's useful for specifying tls credentials all in the cmdline (along with
the -object tls-creds-*), especially for debugging purpose.
The trick here is we must remember to not free these fields again in the
finalize() function of migration object, otherwise it'll cause double-free.
The thing is when destroying an object, we'll first destroy the properties
that bound to the object, then the object itself. To be explicit, when
destroy the object in object_finalize() we have such sequence of
operations:
object_property_del_all(obj);
object_deinit(obj, ti);
So after this change the two fields are properly released already even
before reaching the finalize() function but in object_property_del_all(),
hence we don't need to free them anymore in finalize() or it's double-free.
This also fixes a trivial memory leak for tls-authz as we forgot to free it
before this patch.
Reviewed-by: Daniel P. Berrange <berrange@redhat.com>
Signed-off-by: Peter Xu <peterx@redhat.com>
Message-Id: <20220707185515.27475-1-peterx@redhat.com>
Signed-off-by: Dr. David Alan Gilbert <dgilbert@redhat.com>
Commit: f0afaf6ce4995d37cd411ae26cf8ca1d6dde0f93
https://github.com/qemu/qemu/commit/f0afaf6ce4995d37cd411ae26cf8ca1d6dde0f93
Author: Peter Xu <peterx@redhat.com>
Date: 2022-07-20 (Wed, 20 Jul 2022)
Changed paths:
M migration/postcopy-ram.c
M migration/trace-events
Log Message:
-----------
migration: Enable TLS for preempt channel
This patch is based on the async preempt channel creation. It continues
wiring up the new channel with TLS handshake to destionation when enabled.
Note that only the src QEMU needs such operation; the dest QEMU does not
need any change for TLS support due to the fact that all channels are
established synchronously there, so all the TLS magic is already properly
handled by migration_tls_channel_process_incoming().
Reviewed-by: Daniel P. Berrange <berrange@redhat.com>
Signed-off-by: Peter Xu <peterx@redhat.com>
Message-Id: <20220707185518.27529-1-peterx@redhat.com>
Signed-off-by: Dr. David Alan Gilbert <dgilbert@redhat.com>
Commit: 82b54ef4c123bcfbcb0b854a5780adf2e3a3ed9a
https://github.com/qemu/qemu/commit/82b54ef4c123bcfbcb0b854a5780adf2e3a3ed9a
Author: Peter Xu <peterx@redhat.com>
Date: 2022-07-20 (Wed, 20 Jul 2022)
Changed paths:
M migration/ram.c
Log Message:
-----------
migration: Respect postcopy request order in preemption mode
With preemption mode on, when we see a postcopy request that was requesting
for exactly the page that we have preempted before (so we've partially sent
the page already via PRECOPY channel and it got preempted by another
postcopy request), currently we drop the request so that after all the
other postcopy requests are serviced then we'll go back to precopy stream
and start to handle that.
We dropped the request because we can't send it via postcopy channel since
the precopy channel already contains partial of the data, and we can only
send a huge page via one channel as a whole. We can't split a huge page
into two channels.
That's a very corner case and that works, but there's a change on the order
of postcopy requests that we handle since we're postponing this (unlucky)
postcopy request to be later than the other queued postcopy requests. The
problem is there's a possibility that when the guest was very busy, the
postcopy queue can be always non-empty, it means this dropped request will
never be handled until the end of postcopy migration. So, there's a chance
that there's one dest QEMU vcpu thread waiting for a page fault for an
extremely long time just because it's unluckily accessing the specific page
that was preempted before.
The worst case time it needs can be as long as the whole postcopy migration
procedure. It's extremely unlikely to happen, but when it happens it's not
good.
The root cause of this problem is because we treat pss->postcopy_requested
variable as with two meanings bound together, as the variable shows:
1. Whether this page request is urgent, and,
2. Which channel we should use for this page request.
With the old code, when we set postcopy_requested it means either both (1)
and (2) are true, or both (1) and (2) are false. We can never have (1)
and (2) to have different values.
However it doesn't necessarily need to be like that. It's very legal that
there's one request that has (1) very high urgency, but (2) we'd like to
use the precopy channel. Just like the corner case we were discussing
above.
To differenciate the two meanings better, introduce a new field called
postcopy_target_channel, showing which channel we should use for this page
request, so as to cover the old meaning (2) only. Then we leave the
postcopy_requested variable to stand only for meaning (1), which is the
urgency of this page request.
With this change, we can easily boost priority of a preempted precopy page
as long as we know that page is also requested as a postcopy page. So with
the new approach in get_queued_page() instead of dropping that request, we
send it right away with the precopy channel so we get back the ordering of
the page faults just like how they're requested on dest.
Reported-by: Manish Mishra <manish.mishra@nutanix.com>
Reviewed-by: Dr. David Alan Gilbert <dgilbert@redhat.com>
Reviewed-by: Manish Mishra <manish.mishra@nutanix.com>
Signed-off-by: Peter Xu <peterx@redhat.com>
Message-Id: <20220707185520.27583-1-peterx@redhat.com>
Signed-off-by: Dr. David Alan Gilbert <dgilbert@redhat.com>
Commit: 312e9dd08c50e09b80d97b626bd0082a625befdc
https://github.com/qemu/qemu/commit/312e9dd08c50e09b80d97b626bd0082a625befdc
Author: Peter Xu <peterx@redhat.com>
Date: 2022-07-20 (Wed, 20 Jul 2022)
Changed paths:
M tests/qtest/migration-test.c
Log Message:
-----------
tests: Move MigrateCommon upper
So that it can be used in postcopy tests too soon.
Reviewed-by: Daniel P. Berrange <berrange@redhat.com>
Signed-off-by: Peter Xu <peterx@redhat.com>
Message-Id: <20220707185522.27638-1-peterx@redhat.com>
Signed-off-by: Dr. David Alan Gilbert <dgilbert@redhat.com>
Commit: d1a27b169b2d42121a2015eb61ffec3fec3fade3
https://github.com/qemu/qemu/commit/d1a27b169b2d42121a2015eb61ffec3fec3fade3
Author: Peter Xu <peterx@redhat.com>
Date: 2022-07-20 (Wed, 20 Jul 2022)
Changed paths:
M tests/qtest/migration-test.c
Log Message:
-----------
tests: Add postcopy tls migration test
We just added TLS tests for precopy but not postcopy. Add the
corresponding test for vanilla postcopy.
Rename the vanilla postcopy to "postcopy/plain" because all postcopy tests
will only use unix sockets as channel.
Signed-off-by: Peter Xu <peterx@redhat.com>
Message-Id: <20220707185525.27692-1-peterx@redhat.com>
Reviewed-by: Dr. David Alan Gilbert <dgilbert@redhat.com>
Signed-off-by: Dr. David Alan Gilbert <dgilbert@redhat.com>
dgilbert: Manual merge
Commit: 767fa9cfbaa169df5d8a20a6bb010a761431c246
https://github.com/qemu/qemu/commit/767fa9cfbaa169df5d8a20a6bb010a761431c246
Author: Peter Xu <peterx@redhat.com>
Date: 2022-07-20 (Wed, 20 Jul 2022)
Changed paths:
M tests/qtest/migration-test.c
Log Message:
-----------
tests: Add postcopy tls recovery migration test
It's easy to build this upon the postcopy tls test. Rename the old
postcopy recovery test to postcopy/recovery/plain.
Reviewed-by: Dr. David Alan Gilbert <dgilbert@redhat.com>
Signed-off-by: Peter Xu <peterx@redhat.com>
Message-Id: <20220707185527.27747-1-peterx@redhat.com>
Signed-off-by: Dr. David Alan Gilbert <dgilbert@redhat.com>
dgilbert: Manual merge
Commit: 8f6fe91512cdc187e51108a4e57d7af6ccadd6d8
https://github.com/qemu/qemu/commit/8f6fe91512cdc187e51108a4e57d7af6ccadd6d8
Author: Peter Xu <peterx@redhat.com>
Date: 2022-07-20 (Wed, 20 Jul 2022)
Changed paths:
M tests/qtest/migration-test.c
Log Message:
-----------
tests: Add postcopy preempt tests
Four tests are added for preempt mode:
- Postcopy plain
- Postcopy recovery
- Postcopy tls
- Postcopy tls+recovery
Reviewed-by: Dr. David Alan Gilbert <dgilbert@redhat.com>
Signed-off-by: Peter Xu <peterx@redhat.com>
Message-Id: <20220707185530.27801-1-peterx@redhat.com>
Signed-off-by: Dr. David Alan Gilbert <dgilbert@redhat.com>
dgilbert: Manual merge
Commit: 5f87072e9532a92e6270577665aa2fa659ec0b3f
https://github.com/qemu/qemu/commit/5f87072e9532a92e6270577665aa2fa659ec0b3f
Author: Daniel P. Berrangé <berrange@redhat.com>
Date: 2022-07-20 (Wed, 20 Jul 2022)
Changed paths:
M migration/qemu-file.c
Log Message:
-----------
migration: remove unreachable code after reading data
The code calls qio_channel_read() in a loop when it reports
QIO_CHANNEL_ERR_BLOCK. This code is reported when errno==EAGAIN.
As such the later block of code will always hit the 'errno != EAGAIN'
condition, making the final 'else' unreachable.
Fixes: Coverity CID 1490203
Signed-off-by: Daniel P. Berrangé <berrange@redhat.com>
Message-Id: <20220627135318.156121-1-berrange@redhat.com>
Reviewed-by: Dr. David Alan Gilbert <dgilbert@redhat.com>
Signed-off-by: Dr. David Alan Gilbert <dgilbert@redhat.com>
Commit: 927f93e099c4f9184e60a1bc61624ac2d04d0223
https://github.com/qemu/qemu/commit/927f93e099c4f9184e60a1bc61624ac2d04d0223
Author: Leonardo Bras <leobras@redhat.com>
Date: 2022-07-20 (Wed, 20 Jul 2022)
Changed paths:
M io/channel-socket.c
Log Message:
-----------
QIOChannelSocket: Fix zero-copy flush returning code 1 when nothing sent
If flush is called when no buffer was sent with MSG_ZEROCOPY, it currently
returns 1. This return code should be used only when Linux fails to use
MSG_ZEROCOPY on a lot of sendmsg().
Fix this by returning early from flush if no sendmsg(...,MSG_ZEROCOPY)
was attempted.
Fixes: 2bc58ffc2926 ("QIOChannelSocket: Implement io_writev zero copy flag &
io_flush for CONFIG_LINUX")
Signed-off-by: Leonardo Bras <leobras@redhat.com>
Reviewed-by: Daniel P. Berrangé <berrange@redhat.com>
Acked-by: Daniel P. Berrangé <berrange@redhat.com>
Reviewed-by: Juan Quintela <quintela@redhat.com>
Reviewed-by: Peter Xu <peterx@redhat.com>
Message-Id: <20220711211112.18951-2-leobras@redhat.com>
Signed-off-by: Dr. David Alan Gilbert <dgilbert@redhat.com>
Commit: cf20c897338067ab4b70a4596fdccaf90c7e29a1
https://github.com/qemu/qemu/commit/cf20c897338067ab4b70a4596fdccaf90c7e29a1
Author: Leonardo Bras <leobras@redhat.com>
Date: 2022-07-20 (Wed, 20 Jul 2022)
Changed paths:
M migration/migration.c
M monitor/hmp-cmds.c
M qapi/migration.json
Log Message:
-----------
Add dirty-sync-missed-zero-copy migration stat
Signed-off-by: Leonardo Bras <leobras@redhat.com>
Acked-by: Markus Armbruster <armbru@redhat.com>
Acked-by: Peter Xu <peterx@redhat.com>
Reviewed-by: Daniel P. Berrangé <berrange@redhat.com>
Message-Id: <20220711211112.18951-3-leobras@redhat.com>
Signed-off-by: Dr. David Alan Gilbert <dgilbert@redhat.com>
Commit: d59c40cc483729f2e67c80e58df769ad19976fe9
https://github.com/qemu/qemu/commit/d59c40cc483729f2e67c80e58df769ad19976fe9
Author: Leonardo Bras <leobras@redhat.com>
Date: 2022-07-20 (Wed, 20 Jul 2022)
Changed paths:
M migration/multifd.c
M migration/ram.c
M migration/ram.h
Log Message:
-----------
migration/multifd: Report to user when zerocopy not working
Some errors, like the lack of Scatter-Gather support by the network
interface(NETIF_F_SG) may cause sendmsg(...,MSG_ZEROCOPY) to fail on using
zero-copy, which causes it to fall back to the default copying mechanism.
After each full dirty-bitmap scan there should be a zero-copy flush
happening, which checks for errors each of the previous calls to
sendmsg(...,MSG_ZEROCOPY). If all of them failed to use zero-copy, then
increment dirty_sync_missed_zero_copy migration stat to let the user know
about it.
Signed-off-by: Leonardo Bras <leobras@redhat.com>
Reviewed-by: Daniel P. Berrangé <berrange@redhat.com>
Acked-by: Peter Xu <peterx@redhat.com>
Message-Id: <20220711211112.18951-4-leobras@redhat.com>
Signed-off-by: Dr. David Alan Gilbert <dgilbert@redhat.com>
Commit: 4a8f19c95cf55aec5f63c64bd0a67f65a27c43de
https://github.com/qemu/qemu/commit/4a8f19c95cf55aec5f63c64bd0a67f65a27c43de
Author: Juan Quintela <quintela@redhat.com>
Date: 2022-07-20 (Wed, 20 Jul 2022)
Changed paths:
M migration/multifd.h
Log Message:
-----------
multifd: Document the locking of MultiFD{Send/Recv}Params
Reorder the structures so we can know if the fields are:
- Read only
- Their own locking (i.e. sems)
- Protected by 'mutex'
- Only for the multifd channel
Signed-off-by: Juan Quintela <quintela@redhat.com>
Message-Id: <20220531104318.7494-2-quintela@redhat.com>
Reviewed-by: Dr. David Alan Gilbert <dgilbert@redhat.com>
Signed-off-by: Dr. David Alan Gilbert <dgilbert@redhat.com>
dgilbert: Typo fixes from Chen Zhang
Commit: 90eb69e4f1a16b388d0483543bf6bfc69a9966e4
https://github.com/qemu/qemu/commit/90eb69e4f1a16b388d0483543bf6bfc69a9966e4
Author: Leonardo Bras <leobras@redhat.com>
Date: 2022-07-20 (Wed, 20 Jul 2022)
Changed paths:
M migration/migration.c
Log Message:
-----------
migration: Avoid false-positive on non-supported scenarios for zero-copy-send
Migration with zero-copy-send currently has it's limitations, as it can't
be used with TLS nor any kind of compression. In such scenarios, it should
output errors during parameter / capability setting.
But currently there are some ways of setting this not-supported scenarios
without printing the error message:
!) For 'compression' capability, it works by enabling it together with
zero-copy-send. This happens because the validity test for zero-copy uses
the helper unction migrate_use_compression(), which check for compression
presence in s->enabled_capabilities[MIGRATION_CAPABILITY_COMPRESS].
The point here is: the validity test happens before the capability gets
enabled. If all of them get enabled together, this test will not return
error.
In order to fix that, replace migrate_use_compression() by directly testing
the cap_list parameter migrate_caps_check().
2) For features enabled by parameters such as TLS & 'multifd_compression',
there was also a possibility of setting non-supported scenarios: setting
zero-copy-send first, then setting the unsupported parameter.
In order to fix that, also add a check for parameters conflicting with
zero-copy-send on migrate_params_check().
3) XBZRLE is also a compression capability, so it makes sense to also add
it to the list of capabilities which are not supported with zero-copy-send.
Fixes: 1abaec9a1b2c ("migration: Change zero_copy_send from migration parameter
to migration capability")
Signed-off-by: Leonardo Bras <leobras@redhat.com>
Message-Id: <20220719122345.253713-1-leobras@redhat.com>
Reviewed-by: Dr. David Alan Gilbert <dgilbert@redhat.com>
Signed-off-by: Dr. David Alan Gilbert <dgilbert@redhat.com>
Commit: db727a14108b5f7ee1273f94e8ccce428a646140
https://github.com/qemu/qemu/commit/db727a14108b5f7ee1273f94e8ccce428a646140
Author: Dr. David Alan Gilbert <dgilbert@redhat.com>
Date: 2022-07-20 (Wed, 20 Jul 2022)
Changed paths:
M .gitlab-ci.d/custom-runners/ubuntu-20.04-s390x.yml
M .travis.yml
Log Message:
-----------
Revert "gitlab: disable accelerated zlib for s390x"
This reverts commit 309df6acb29346f89e1ee542b1986f60cab12b87.
With Ilya's 'multifd: Copy pages before compressing them with zlib'
in the latest migration series, this shouldn't be a problem any more.
Suggested-by: Peter Maydell <peter.maydell@linaro.org>
Signed-off-by: Dr. David Alan Gilbert <dgilbert@redhat.com>
Reviewed-by: Thomas Huth <thuth@redhat.com>
Commit: fe16c833fdb74642c296fa96a472e39229cd4351
https://github.com/qemu/qemu/commit/fe16c833fdb74642c296fa96a472e39229cd4351
Author: Peter Maydell <peter.maydell@linaro.org>
Date: 2022-07-20 (Wed, 20 Jul 2022)
Changed paths:
M .gitlab-ci.d/custom-runners/ubuntu-20.04-s390x.yml
M .travis.yml
M accel/kvm/kvm-all.c
M accel/stubs/kvm-stub.c
M cpus-common.c
M hmp-commands-info.hx
M hmp-commands.hx
M include/exec/cpu-common.h
M include/exec/memory.h
M include/hw/core/cpu.h
M include/monitor/hmp.h
A include/sysemu/dirtylimit.h
A include/sysemu/dirtyrate.h
M include/sysemu/kvm.h
M io/channel-socket.c
M migration/channel.c
M migration/dirtyrate.c
M migration/dirtyrate.h
M migration/migration.c
M migration/migration.h
M migration/multifd-zlib.c
M migration/multifd.c
M migration/multifd.h
M migration/postcopy-ram.c
M migration/postcopy-ram.h
M migration/qemu-file.c
M migration/qemu-file.h
M migration/ram.c
M migration/ram.h
M migration/savevm.c
M migration/socket.c
M migration/socket.h
M migration/tls.c
M migration/tls.h
M migration/trace-events
M monitor/hmp-cmds.c
M qapi/migration.json
A softmmu/dirtylimit.c
M softmmu/meson.build
M softmmu/trace-events
M tests/qtest/migration-helpers.c
M tests/qtest/migration-helpers.h
M tests/qtest/migration-test.c
M tests/qtest/qmp-cmd-test.c
Log Message:
-----------
Merge tag 'pull-migration-20220720c' of https://gitlab.com/dagrh/qemu into
staging
Migration pull 2022-07-20
This replaces yesterdays pull and:
a) Fixes some test build errors without TLS
b) Reenabled the zlib acceleration on s390
now that we have Ilya's fix
Hyman's dirty page rate limit set
Ilya's fix for zlib vs migration
Peter's postcopy-preempt
Cleanup from Dan
zero-copy tidy ups from Leo
multifd doc fix from Juan
Revert disable of zlib acceleration on s390x
Signed-off-by: Dr. David Alan Gilbert <dgilbert@redhat.com>
# gpg: Signature made Wed 20 Jul 2022 12:18:56 BST
# gpg: using RSA key 45F5C71B4A0CB7FB977A9FA90516331EBC5BFDE7
# gpg: Good signature from "Dr. David Alan Gilbert (RH2) <dgilbert@redhat.com>"
[full]
# Primary key fingerprint: 45F5 C71B 4A0C B7FB 977A 9FA9 0516 331E BC5B FDE7
* tag 'pull-migration-20220720c' of https://gitlab.com/dagrh/qemu: (30 commits)
Revert "gitlab: disable accelerated zlib for s390x"
migration: Avoid false-positive on non-supported scenarios for zero-copy-send
multifd: Document the locking of MultiFD{Send/Recv}Params
migration/multifd: Report to user when zerocopy not working
Add dirty-sync-missed-zero-copy migration stat
QIOChannelSocket: Fix zero-copy flush returning code 1 when nothing sent
migration: remove unreachable code after reading data
tests: Add postcopy preempt tests
tests: Add postcopy tls recovery migration test
tests: Add postcopy tls migration test
tests: Move MigrateCommon upper
migration: Respect postcopy request order in preemption mode
migration: Enable TLS for preempt channel
migration: Export tls-[creds|hostname|authz] params to cmdline too
migration: Add helpers to detect TLS capability
migration: Add property x-postcopy-preempt-break-huge
migration: Create the postcopy preempt channel asynchronously
migration: Postcopy recover with preempt enabled
migration: Postcopy preemption enablement
migration: Postcopy preemption preparation on channel creation
...
Signed-off-by: Peter Maydell <peter.maydell@linaro.org>
Compare: https://github.com/qemu/qemu/compare/8ec4bc3c8c09...fe16c833fdb7