[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
[Qemu-commits] [qemu/qemu] 39e2bf: accel/kvm/kvm-all: Refactor per-vcpu
|
From: |
Peter Maydell |
|
Subject: |
[Qemu-commits] [qemu/qemu] 39e2bf: accel/kvm/kvm-all: Refactor per-vcpu dirty ring re... |
|
Date: |
Tue, 19 Jul 2022 12:26:06 -0700 |
Branch: refs/heads/staging
Home: https://github.com/qemu/qemu
Commit: 39e2bfcc206e8d9d05622f67d34fc1a58ebc67c1
https://github.com/qemu/qemu/commit/39e2bfcc206e8d9d05622f67d34fc1a58ebc67c1
Author: Hyman Huang(黄勇) <huangy81@chinatelecom.cn>
Date: 2022-07-19 (Tue, 19 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: 36ca01432bed727c18ecb6951005b7581db470eb
https://github.com/qemu/qemu/commit/36ca01432bed727c18ecb6951005b7581db470eb
Author: Hyman Huang(黄勇) <huangy81@chinatelecom.cn>
Date: 2022-07-19 (Tue, 19 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: 62700be4cbc5ff761aba1e9ab4d1ff9abd1e2d87
https://github.com/qemu/qemu/commit/62700be4cbc5ff761aba1e9ab4d1ff9abd1e2d87
Author: Hyman Huang(黄勇) <huangy81@chinatelecom.cn>
Date: 2022-07-19 (Tue, 19 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: 59150957d1fe57a88c467d453927465e18ee1e46
https://github.com/qemu/qemu/commit/59150957d1fe57a88c467d453927465e18ee1e46
Author: Hyman Huang(黄勇) <huangy81@chinatelecom.cn>
Date: 2022-07-19 (Tue, 19 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: fc6a2a92b0ec64e30c41388fcc3dc8d4434ec491
https://github.com/qemu/qemu/commit/fc6a2a92b0ec64e30c41388fcc3dc8d4434ec491
Author: Hyman Huang(黄勇) <huangy81@chinatelecom.cn>
Date: 2022-07-19 (Tue, 19 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: 324353c88309a6d6f9e8bae281fd970eac020e81
https://github.com/qemu/qemu/commit/324353c88309a6d6f9e8bae281fd970eac020e81
Author: Hyman Huang(黄勇) <huangy81@chinatelecom.cn>
Date: 2022-07-19 (Tue, 19 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: db65bff2c6ddab1bfe6247bc7102dc02df7a5d85
https://github.com/qemu/qemu/commit/db65bff2c6ddab1bfe6247bc7102dc02df7a5d85
Author: Hyman Huang(黄勇) <huangy81@chinatelecom.cn>
Date: 2022-07-19 (Tue, 19 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: fc48526ef2f82acdc42009942cf8be3838938c49
https://github.com/qemu/qemu/commit/fc48526ef2f82acdc42009942cf8be3838938c49
Author: Hyman Huang(黄勇) <huangy81@chinatelecom.cn>
Date: 2022-07-19 (Tue, 19 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: 53a352260061399547947236c1478be40198ccd8
https://github.com/qemu/qemu/commit/53a352260061399547947236c1478be40198ccd8
Author: Ilya Leoshkevich <iii@linux.ibm.com>
Date: 2022-07-19 (Tue, 19 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: 7f8254bd7aba2dfc8bc75eb4ab2ab6afb748fcb6
https://github.com/qemu/qemu/commit/7f8254bd7aba2dfc8bc75eb4ab2ab6afb748fcb6
Author: Peter Xu <peterx@redhat.com>
Date: 2022-07-19 (Tue, 19 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: 1e05530d16738a923581bf0148ea384aac970452
https://github.com/qemu/qemu/commit/1e05530d16738a923581bf0148ea384aac970452
Author: Peter Xu <peterx@redhat.com>
Date: 2022-07-19 (Tue, 19 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: 7c984bfa2e1b4f7caaf565e33556a3f8a290a015
https://github.com/qemu/qemu/commit/7c984bfa2e1b4f7caaf565e33556a3f8a290a015
Author: Peter Xu <peterx@redhat.com>
Date: 2022-07-19 (Tue, 19 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: 0a1d83f32182e8edd7885f7b1f49dd5b06ae58a5
https://github.com/qemu/qemu/commit/0a1d83f32182e8edd7885f7b1f49dd5b06ae58a5
Author: Peter Xu <peterx@redhat.com>
Date: 2022-07-19 (Tue, 19 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: 7699ca2b53c1093f0df2f0d198a3035e8a958af4
https://github.com/qemu/qemu/commit/7699ca2b53c1093f0df2f0d198a3035e8a958af4
Author: Peter Xu <peterx@redhat.com>
Date: 2022-07-19 (Tue, 19 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: 850fac1364b357b33032b64dee897b244cefc31b
https://github.com/qemu/qemu/commit/850fac1364b357b33032b64dee897b244cefc31b
Author: Peter Xu <peterx@redhat.com>
Date: 2022-07-19 (Tue, 19 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: efe9eeba349f691f07d66973b89fb5d40b0b491b
https://github.com/qemu/qemu/commit/efe9eeba349f691f07d66973b89fb5d40b0b491b
Author: Peter Xu <peterx@redhat.com>
Date: 2022-07-19 (Tue, 19 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: f8e2004b7710b4bfd6af9a4407db4617815222c4
https://github.com/qemu/qemu/commit/f8e2004b7710b4bfd6af9a4407db4617815222c4
Author: Peter Xu <peterx@redhat.com>
Date: 2022-07-19 (Tue, 19 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: a454531ad558652cd448002accf9af81eccb3636
https://github.com/qemu/qemu/commit/a454531ad558652cd448002accf9af81eccb3636
Author: Peter Xu <peterx@redhat.com>
Date: 2022-07-19 (Tue, 19 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: 219188492d23e76d49598d30965a4ff779aa36b1
https://github.com/qemu/qemu/commit/219188492d23e76d49598d30965a4ff779aa36b1
Author: Peter Xu <peterx@redhat.com>
Date: 2022-07-19 (Tue, 19 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: 36f185888a954dc1ad00da6618fa9e356257fab5
https://github.com/qemu/qemu/commit/36f185888a954dc1ad00da6618fa9e356257fab5
Author: Peter Xu <peterx@redhat.com>
Date: 2022-07-19 (Tue, 19 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: 03f7f517a794fc0980fb8b36b856b18fddadb127
https://github.com/qemu/qemu/commit/03f7f517a794fc0980fb8b36b856b18fddadb127
Author: Peter Xu <peterx@redhat.com>
Date: 2022-07-19 (Tue, 19 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: 0b6a90593f95b739465fcc62bfc4025329ed7032
https://github.com/qemu/qemu/commit/0b6a90593f95b739465fcc62bfc4025329ed7032
Author: Peter Xu <peterx@redhat.com>
Date: 2022-07-19 (Tue, 19 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: 34006335425fb347d05054df7eb3b443b76ddc6a
https://github.com/qemu/qemu/commit/34006335425fb347d05054df7eb3b443b76ddc6a
Author: Peter Xu <peterx@redhat.com>
Date: 2022-07-19 (Tue, 19 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: 4ee5caf75c1c8d13f85dce510c18b5dd6846e400
https://github.com/qemu/qemu/commit/4ee5caf75c1c8d13f85dce510c18b5dd6846e400
Author: Daniel P. Berrangé <berrange@redhat.com>
Date: 2022-07-19 (Tue, 19 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: d102e5de0b4572498dc0fa16da04cb0c620a2f78
https://github.com/qemu/qemu/commit/d102e5de0b4572498dc0fa16da04cb0c620a2f78
Author: Leonardo Bras <leobras@redhat.com>
Date: 2022-07-19 (Tue, 19 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: 7390c118229bbf8f5430019e95d31a3dbd9a7a60
https://github.com/qemu/qemu/commit/7390c118229bbf8f5430019e95d31a3dbd9a7a60
Author: Leonardo Bras <leobras@redhat.com>
Date: 2022-07-19 (Tue, 19 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: eb87400f40a4234a94b3db26a0292ecdd218f711
https://github.com/qemu/qemu/commit/eb87400f40a4234a94b3db26a0292ecdd218f711
Author: Leonardo Bras <leobras@redhat.com>
Date: 2022-07-19 (Tue, 19 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: a5799d97f55485296428ddef28abd030cd532aab
https://github.com/qemu/qemu/commit/a5799d97f55485296428ddef28abd030cd532aab
Author: Juan Quintela <quintela@redhat.com>
Date: 2022-07-19 (Tue, 19 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: ec0345c1000b3a57b557da4c2e3f2114dd23903a
https://github.com/qemu/qemu/commit/ec0345c1000b3a57b557da4c2e3f2114dd23903a
Author: Leonardo Bras <leobras@redhat.com>
Date: 2022-07-19 (Tue, 19 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: a14e75dda4034b9ce0389d25713661511e0ff02a
https://github.com/qemu/qemu/commit/a14e75dda4034b9ce0389d25713661511e0ff02a
Author: Peter Maydell <peter.maydell@linaro.org>
Date: 2022-07-19 (Tue, 19 Jul 2022)
Changed paths:
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-20220719c' of https://gitlab.com/dagrh/qemu into
staging
Migration pull 2022-07-19
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
Signed-off-by: Dr. David Alan Gilbert <dgilbert@redhat.com>
# gpg: Signature made Tue 19 Jul 2022 17:34:52 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-20220719c' of https://gitlab.com/dagrh/qemu: (29 commits)
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
migration: Add postcopy-preempt capability
...
Signed-off-by: Peter Maydell <peter.maydell@linaro.org>
Compare: https://github.com/qemu/qemu/compare/d48125de38f4...a14e75dda403
| [Prev in Thread] |
Current Thread |
[Next in Thread] |
- [Qemu-commits] [qemu/qemu] 39e2bf: accel/kvm/kvm-all: Refactor per-vcpu dirty ring re...,
Peter Maydell <=