thread_pool_submit_aio() is always called on a pool taken from
qemu_get_current_aio_context(), and that is the only intended
use: each pool runs only in the same thread that is submitting
work to it, it can't run anywhere else.
Therefore simplify the thread_pool_submit* API and remove the
ThreadPool function parameter.
Signed-off-by: Emanuele Giuseppe Esposito <eesposit@redhat.com>
Message-Id: <20230203131731.851116-5-eesposit@redhat.com>
Reviewed-by: Kevin Wolf <kwolf@redhat.com>
Reviewed-by: Stefan Hajnoczi <stefanha@redhat.com>
Signed-off-by: Kevin Wolf <kwolf@redhat.com>
Use qemu_get_current_aio_context() where possible, since we always
submit work to the current thread anyways.
We want to also be sure that the thread submitting the work is
the same as the one processing the pool, to avoid adding
synchronization to the pool list.
Signed-off-by: Emanuele Giuseppe Esposito <eesposit@redhat.com>
Message-Id: <20230203131731.851116-4-eesposit@redhat.com>
Reviewed-by: Kevin Wolf <kwolf@redhat.com>
Reviewed-by: Stefan Hajnoczi <stefanha@redhat.com>
Signed-off-by: Kevin Wolf <kwolf@redhat.com>
Remove usage of aio_context_acquire by always submitting asynchronous
AIO to the current thread's LuringState.
In order to prevent mistakes from the caller side, avoid passing LuringState
in luring_io_{plug/unplug} and luring_co_submit, and document the functions
to make clear that they work in the current thread's AioContext.
Signed-off-by: Emanuele Giuseppe Esposito <eesposit@redhat.com>
Message-Id: <20230203131731.851116-3-eesposit@redhat.com>
Reviewed-by: Kevin Wolf <kwolf@redhat.com>
Reviewed-by: Stefan Hajnoczi <stefanha@redhat.com>
Signed-off-by: Kevin Wolf <kwolf@redhat.com>
Remove usage of aio_context_acquire by always submitting asynchronous
AIO to the current thread's LinuxAioState.
In order to prevent mistakes from the caller side, avoid passing LinuxAioState
in laio_io_{plug/unplug} and laio_co_submit, and document the functions
to make clear that they work in the current thread's AioContext.
Signed-off-by: Emanuele Giuseppe Esposito <eesposit@redhat.com>
Message-Id: <20230203131731.851116-2-eesposit@redhat.com>
Reviewed-by: Kevin Wolf <kwolf@redhat.com>
Reviewed-by: Stefan Hajnoczi <stefanha@redhat.com>
Signed-off-by: Kevin Wolf <kwolf@redhat.com>
Not a coroutine_fn, you say?
static int64_t bdrv_sum_allocated_file_size(BlockDriverState *bs)
{
BdrvChild *child;
int64_t child_size, sum = 0;
QLIST_FOREACH(child, &bs->children, next) {
if (child->role & (BDRV_CHILD_DATA | BDRV_CHILD_METADATA |
BDRV_CHILD_FILTERED))
{
child_size = bdrv_co_get_allocated_file_size(child->bs);
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
Well what do we have here?!
I rest my case, your honor.
Signed-off-by: Stefan Hajnoczi <stefanha@redhat.com>
Message-Id: <20230308211435.346375-1-stefanha@redhat.com>
Reviewed-by: Kevin Wolf <kwolf@redhat.com>
Signed-off-by: Kevin Wolf <kwolf@redhat.com>
Fixup a few minor typos
Signed-off-by: Wilfred Mallawa <wilfred.mallawa@wdc.com>
Message-Id: <20230313003744.55476-1-wilfred.mallawa@opensource.wdc.com>
Reviewed-by: Philippe Mathieu-Daudé <philmd@linaro.org>
Reviewed-by: Kevin Wolf <kwolf@redhat.com>
Signed-off-by: Kevin Wolf <kwolf@redhat.com>
monitor_cleanup() is called from the main loop thread. Calling
AIO_WAIT_WHILE(qemu_get_aio_context(), ...) from the main loop thread is
equivalent to AIO_WAIT_WHILE_UNLOCKED(NULL, ...) because neither unlocks
the AioContext and the latter's assertion that we're in the main loop
succeeds.
Reviewed-by: Philippe Mathieu-Daudé <philmd@linaro.org>
Tested-by: Philippe Mathieu-Daudé <philmd@linaro.org>
Reviewed-by: Markus Armbruster <armbru@redhat.com>
Reviewed-by: Kevin Wolf <kwolf@redhat.com>
Signed-off-by: Stefan Hajnoczi <stefanha@redhat.com>
Message-Id: <20230309190855.414275-7-stefanha@redhat.com>
Reviewed-by: Wilfred Mallawa <wilfred.mallawa@wdc.com>
Signed-off-by: Kevin Wolf <kwolf@redhat.com>
The HMP monitor runs in the main loop thread. Calling
AIO_WAIT_WHILE(qemu_get_aio_context(), ...) from the main loop thread is
equivalent to AIO_WAIT_WHILE_UNLOCKED(NULL, ...) because neither unlocks
the AioContext and the latter's assertion that we're in the main loop
succeeds.
Reviewed-by: Philippe Mathieu-Daudé <philmd@linaro.org>
Tested-by: Philippe Mathieu-Daudé <philmd@linaro.org>
Reviewed-by: Markus Armbruster <armbru@redhat.com>
Reviewed-by: Kevin Wolf <kwolf@redhat.com>
Signed-off-by: Stefan Hajnoczi <stefanha@redhat.com>
Message-Id: <20230309190855.414275-6-stefanha@redhat.com>
Reviewed-by: Wilfred Mallawa <wilfred.mallawa@wdc.com>
Signed-off-by: Kevin Wolf <kwolf@redhat.com>
Since the AioContext argument was already NULL, AIO_WAIT_WHILE() was
never going to unlock the AioContext. Therefore it is possible to
replace AIO_WAIT_WHILE() with AIO_WAIT_WHILE_UNLOCKED().
Reviewed-by: Philippe Mathieu-Daudé <philmd@linaro.org>
Tested-by: Philippe Mathieu-Daudé <philmd@linaro.org>
Reviewed-by: Kevin Wolf <kwolf@redhat.com>
Signed-off-by: Stefan Hajnoczi <stefanha@redhat.com>
Message-Id: <20230309190855.414275-5-stefanha@redhat.com>
Reviewed-by: Wilfred Mallawa <wilfred.mallawa@wdc.com>
Signed-off-by: Kevin Wolf <kwolf@redhat.com>
The following conversion is safe and does not change behavior:
GLOBAL_STATE_CODE();
...
- AIO_WAIT_WHILE(qemu_get_aio_context(), ...);
+ AIO_WAIT_WHILE_UNLOCKED(NULL, ...);
Since we're in GLOBAL_STATE_CODE(), qemu_get_aio_context() is our home
thread's AioContext. Thus AIO_WAIT_WHILE() does not unlock the
AioContext:
if (ctx_ && in_aio_context_home_thread(ctx_)) { \
while ((cond)) { \
aio_poll(ctx_, true); \
waited_ = true; \
} \
And that means AIO_WAIT_WHILE_UNLOCKED(NULL, ...) can be substituted.
Reviewed-by: Philippe Mathieu-Daudé <philmd@linaro.org>
Tested-by: Philippe Mathieu-Daudé <philmd@linaro.org>
Reviewed-by: Kevin Wolf <kwolf@redhat.com>
Signed-off-by: Stefan Hajnoczi <stefanha@redhat.com>
Message-Id: <20230309190855.414275-4-stefanha@redhat.com>
Reviewed-by: Wilfred Mallawa <wilfred.mallawa@wdc.com>
Signed-off-by: Kevin Wolf <kwolf@redhat.com>
There is no change in behavior. Switch to AIO_WAIT_WHILE_UNLOCKED()
instead of AIO_WAIT_WHILE() to document that this code has already been
audited and converted. The AioContext argument is already NULL so
aio_context_release() is never called anyway.
Reviewed-by: Philippe Mathieu-Daudé <philmd@linaro.org>
Tested-by: Philippe Mathieu-Daudé <philmd@linaro.org>
Reviewed-by: Kevin Wolf <kwolf@redhat.com>
Signed-off-by: Stefan Hajnoczi <stefanha@redhat.com>
Message-Id: <20230309190855.414275-3-stefanha@redhat.com>
Reviewed-by: Wilfred Mallawa <wilfred.mallawa@wdc.com>
Signed-off-by: Kevin Wolf <kwolf@redhat.com>
There is no need for the AioContext lock in bdrv_drain_all() because
nothing in AIO_WAIT_WHILE() needs the lock and the condition is atomic.
AIO_WAIT_WHILE_UNLOCKED() has no use for the AioContext parameter other
than performing a check that is nowadays already done by the
GLOBAL_STATE_CODE()/IO_CODE() macros. Set the ctx argument to NULL here
to help us keep track of all converted callers. Eventually all callers
will have been converted and then the argument can be dropped entirely.
Reviewed-by: Kevin Wolf <kwolf@redhat.com>
Signed-off-by: Stefan Hajnoczi <stefanha@redhat.com>
Message-Id: <20230309190855.414275-2-stefanha@redhat.com>
Reviewed-by: Kevin Wolf <kwolf@redhat.com>
Reviewed-by: Wilfred Mallawa <wilfred.mallawa@wdc.com>
Signed-off-by: Kevin Wolf <kwolf@redhat.com>
The CoQueue API offers thread-safety via the lock argument that
qemu_co_queue_wait() and qemu_co_enter_next() take. BlockBackend
currently does not make use of the lock argument. This means that
multiple threads submitting I/O requests can corrupt the CoQueue's
QSIMPLEQ.
Add a QemuMutex and pass it to CoQueue APIs so that the queue is
protected. While we're at it, also assert that the queue is empty when
the BlockBackend is deleted.
Signed-off-by: Stefan Hajnoczi <stefanha@redhat.com>
Reviewed-by: Hanna Czenczek <hreitz@redhat.com>
Message-Id: <20230307210427.269214-4-stefanha@redhat.com>
Reviewed-by: Kevin Wolf <kwolf@redhat.com>
Signed-off-by: Kevin Wolf <kwolf@redhat.com>
This field is accessed by multiple threads without a lock. Use explicit
qatomic_read()/qatomic_set() calls. There is no need for acquire/release
because blk_set_disable_request_queuing() doesn't provide any
guarantees (it helps that it's used at BlockBackend creation time and
not when there is I/O in flight).
Signed-off-by: Stefan Hajnoczi <stefanha@redhat.com>
Reviewed-by: Hanna Czenczek <hreitz@redhat.com>
Message-Id: <20230307210427.269214-3-stefanha@redhat.com>
Reviewed-by: Philippe Mathieu-Daudé <philmd@linaro.org>
Reviewed-by: Kevin Wolf <kwolf@redhat.com>
Signed-off-by: Kevin Wolf <kwolf@redhat.com>
The main loop thread increments/decrements BlockBackend->quiesce_counter
when drained sections begin/end. The counter is read in the I/O code
path. Therefore this field is used to communicate between threads
without a lock.
Acquire/release are not necessary because the BlockBackend->in_flight
counter already uses sequentially consistent accesses and running I/O
requests hold that counter when blk_wait_while_drained() is called.
qatomic_read() can be used.
Use qatomic_fetch_inc()/qatomic_fetch_dec() for modifications even
though sequentially consistent atomic accesses are not strictly required
here. They are, however, nicer to read than multiple calls to
qatomic_read() and qatomic_set(). Since beginning and ending drain is
not a hot path the extra cost doesn't matter.
Signed-off-by: Stefan Hajnoczi <stefanha@redhat.com>
Message-Id: <20230307210427.269214-2-stefanha@redhat.com>
Reviewed-by: Philippe Mathieu-Daudé <philmd@linaro.org>
Reviewed-by: Kevin Wolf <kwolf@redhat.com>
Signed-off-by: Kevin Wolf <kwolf@redhat.com>
Everything that was reviewed since last PULL request:
- fix to control flow (eric)
- rearrange of hmp commands (juan)
- Make capabilities more consistent and coherent (juan)
Not all of them reviewed yet, so only the ones reviewed.
Later, Juan.
PD. I am waiting to finish review of the compression fixes to send
them.
-----BEGIN PGP SIGNATURE-----
iQIzBAABCAAdFiEEGJn/jt6/WMzuA0uC9IfvGFhy1yMFAmRGf0kACgkQ9IfvGFhy
1yNojRAAhvOZoYRpTizbSo7wOr2TpO4F1R/opWECubBvw3/yTo3ifsVjovRo/nxe
zmCXnY/ykqxskb/OMNyLZQYG4MPT24nyf7dhT3VxcFjTYsaNU59yvJoBtvy7Oq5h
3Yk0459eKmsP39IXFlAMMRBwX+Hu3aE/8xAAHOowAhkmDkMFYjf7I1Lxpuarbhp+
k9O5eqdNchG21YUzWXUe4ivAWqZmvzXtkwCp+XJ/KizjIEKgsm8HO1nwm5mtpmnu
SS9Kkf957jYHqK73YXQhUV+iQ0kCVpclBPfZc2KuzudPi/aMG6LEVKfV//z5KIAz
amME/6D1oSBfpgtqoCCPELdNfZOz+ZIa+XJzXlWkuiBDu9yNpUP339EVClmStwFu
1UAOJIs8VUjPr9zTItgCDjZ17nh4Q0I04aMGuxgQIu82e8CTgS/QrnH2Tr2lUoMO
QLgYAetVIDGVVFAA9Clba4C7AbS5hBeWMnd9Qd4cP93d6Z/C65xUv0a9mI7edpMb
RNbvg73ZZCb6tye25cPSr07VaGTS+TELVMEh9RX3KZrfMTsHfGQ/ZHZv9wqJrQ04
0wCidqBIbBk+BN8AtJ9vwqtPpL/Nf/BwDKPiwOVuZHCcrP+veXtlKb00SwNpJwkN
x3Ld4cq22ZLeqO4dMueK16ij0ZpuXsF7jM/ptEvxrw6oxh/6xYQ=
=g5gx
-----END PGP SIGNATURE-----
Merge tag 'migration-20230424-pull-request' of https://gitlab.com/juan.quintela/qemu into staging
Migration Pull request
Everything that was reviewed since last PULL request:
- fix to control flow (eric)
- rearrange of hmp commands (juan)
- Make capabilities more consistent and coherent (juan)
Not all of them reviewed yet, so only the ones reviewed.
Later, Juan.
PD. I am waiting to finish review of the compression fixes to send
them.
# -----BEGIN PGP SIGNATURE-----
#
# iQIzBAABCAAdFiEEGJn/jt6/WMzuA0uC9IfvGFhy1yMFAmRGf0kACgkQ9IfvGFhy
# 1yNojRAAhvOZoYRpTizbSo7wOr2TpO4F1R/opWECubBvw3/yTo3ifsVjovRo/nxe
# zmCXnY/ykqxskb/OMNyLZQYG4MPT24nyf7dhT3VxcFjTYsaNU59yvJoBtvy7Oq5h
# 3Yk0459eKmsP39IXFlAMMRBwX+Hu3aE/8xAAHOowAhkmDkMFYjf7I1Lxpuarbhp+
# k9O5eqdNchG21YUzWXUe4ivAWqZmvzXtkwCp+XJ/KizjIEKgsm8HO1nwm5mtpmnu
# SS9Kkf957jYHqK73YXQhUV+iQ0kCVpclBPfZc2KuzudPi/aMG6LEVKfV//z5KIAz
# amME/6D1oSBfpgtqoCCPELdNfZOz+ZIa+XJzXlWkuiBDu9yNpUP339EVClmStwFu
# 1UAOJIs8VUjPr9zTItgCDjZ17nh4Q0I04aMGuxgQIu82e8CTgS/QrnH2Tr2lUoMO
# QLgYAetVIDGVVFAA9Clba4C7AbS5hBeWMnd9Qd4cP93d6Z/C65xUv0a9mI7edpMb
# RNbvg73ZZCb6tye25cPSr07VaGTS+TELVMEh9RX3KZrfMTsHfGQ/ZHZv9wqJrQ04
# 0wCidqBIbBk+BN8AtJ9vwqtPpL/Nf/BwDKPiwOVuZHCcrP+veXtlKb00SwNpJwkN
# x3Ld4cq22ZLeqO4dMueK16ij0ZpuXsF7jM/ptEvxrw6oxh/6xYQ=
# =g5gx
# -----END PGP SIGNATURE-----
# gpg: Signature made Mon 24 Apr 2023 02:08:25 PM BST
# gpg: using RSA key 1899FF8EDEBF58CCEE034B82F487EF185872D723
# gpg: Good signature from "Juan Quintela <quintela@redhat.com>" [undefined]
# gpg: aka "Juan Quintela <quintela@trasno.org>" [undefined]
# gpg: WARNING: This key is not certified with a trusted signature!
# gpg: There is no indication that the signature belongs to the owner.
# Primary key fingerprint: 1899 FF8E DEBF 58CC EE03 4B82 F487 EF18 5872 D723
* tag 'migration-20230424-pull-request' of https://gitlab.com/juan.quintela/qemu: (30 commits)
migration: Create migrate_max_bandwidth() function
migration: Move migrate_postcopy() to options.c
migration: Create migrate_cpu_throttle_tailslow() function
migration: Create migrate_cpu_throttle_increment() function
migration: Create migrate_cpu_throttle_initial() to option.c
migration: Move migrate_announce_params() to option.c
migration: Create migrate_max_cpu_throttle()
migration: Create migrate_checkpoint_delay()
migration: Create migrate_throttle_trigger_threshold()
migration: Move migrate_use_block_incremental() to option.c
migration: Use migrate_max_postcopy_bandwidth()
migration: Move parameters functions to option.c
migration: Move migrate_cap_set() to options.c
migration: Move qmp_migrate_set_capabilities() to options.c
migration: Move qmp_query_migrate_capabilities() to options.c
migration: Move migrate_caps_check() to options.c
migration: Create migrate_rdma_pin_all() function
migration: Move migrate_use_return() to options.c
migration: Move migrate_use_block() to options.c
migration: Move migrate_use_xbzrle() to options.c
...
Signed-off-by: Richard Henderson <richard.henderson@linaro.org>
To be consistent with every other parameter, rename to
migrate_block_incremental().
Signed-off-by: Juan Quintela <quintela@redhat.com>
Reviewed-by: Vladimir Sementsov-Ogievskiy <vsementsov@yandex-team.ru>
Signed-off-by: Juan Quintela <quintela@redhat.com>
Reviewed-by: Vladimir Sementsov-Ogievskiy <vsementsov@yandex-team.ru>
---
Fixed missing space after comma (fabiano)
Once that we are there, we rename the function to migrate_return_path()
to be consistent with all other capabilities.
Signed-off-by: Juan Quintela <quintela@redhat.com>
Reviewed-by: Vladimir Sementsov-Ogievskiy <vsementsov@yandex-team.ru>
Once that we are there, we rename the function to migrate_block()
to be consistent with all other capabilities.
Signed-off-by: Juan Quintela <quintela@redhat.com>
Reviewed-by: Vladimir Sementsov-Ogievskiy <vsementsov@yandex-team.ru>
Once that we are there, we rename the function to migrate_xbzrle()
to be consistent with all other capabilities.
We change the type to return bool also for consistency.
Signed-off-by: Juan Quintela <quintela@redhat.com>
Reviewed-by: Vladimir Sementsov-Ogievskiy <vsementsov@yandex-team.ru>
Once that we are there, we rename the function to
migrate_zero_copy_send() to be consistent with all other capabilities.
We can remove the CONFIG_LINUX guard. We already check that we can't
setup this capability in migrate_caps_check().
Signed-off-by: Juan Quintela <quintela@redhat.com>
Reviewed-by: Vladimir Sementsov-Ogievskiy <vsementsov@yandex-team.ru>
Once that we are there, we rename the function to migrate_multifd()
to be consistent with all other capabilities.
Signed-off-by: Juan Quintela <quintela@redhat.com>
Reviewed-by: Vladimir Sementsov-Ogievskiy <vsementsov@yandex-team.ru>
Once that we are there, we rename the function to migrate_events()
to be consistent with all other capabilities.
Signed-off-by: Juan Quintela <quintela@redhat.com>
Reviewed-by: Vladimir Sementsov-Ogievskiy <vsementsov@yandex-team.ru>
Once that we are there, we rename the function to migrate_compress()
to be consistent with all other capabilities.
Signed-off-by: Juan Quintela <quintela@redhat.com>
Reviewed-by: Vladimir Sementsov-Ogievskiy <vsementsov@yandex-team.ru>
Once that we are there, we rename the function to migrate_colo() to be
consistent with all other capabilities.
Signed-off-by: Juan Quintela <quintela@redhat.com>
Reviewed-by: Vladimir Sementsov-Ogievskiy <vsementsov@yandex-team.ru>
We move there all capabilities helpers from migration.c.
Signed-off-by: Juan Quintela <quintela@redhat.com>
Reviewed-by: Dr. David Alan Gilbert <dgilbert@redhat.com>
---
Following David advise:
- looked through the history, capabilities are newer than 2012, so we
can remove that bit of the header.
- This part is posterior to Anthony.
Original Author is Orit. Once there,
I put myself. Peter Xu also did quite a bit of work here.
Anyone else wants/needs to be there? I didn't search too hard
because nobody asked before to be added.
What do you think?
And remove the convoluted use of qmp_migrate_set_capabilities() to
enable disable MIGRATION_CAPABILITY_BLOCK.
Signed-off-by: Juan Quintela <quintela@redhat.com>
Reviewed-by: Fabiano Rosas <farosas@suse.de>
It has nothing to do with migration, except for the "migrate" in the
name of the command. Move it with the rest of the ui commands.
Signed-off-by: Juan Quintela <quintela@redhat.com>
Reviewed-by: Philippe Mathieu-Daudé <philmd@linaro.org>
It is only used there, so we can make it static.
Once there, remove spice.h that it is not used.
Signed-off-by: Juan Quintela <quintela@redhat.com>
Reviewed-by: Peter Xu <peterx@redhat.com>
Reviewed-by: Philippe Mathieu-Daudé <philmd@linaro.org>
---
fix David Edmonson ui/qemu-spice.h unintended removal
No need to declare a temporary variable.
Suggested-by: Juan Quintela <quintela@redhat.com>
Fixes: 1df36e8c6289 ("migration: Handle block device inactivation failures better")
Signed-off-by: Eric Blake <eblake@redhat.com>
Reviewed-by: Juan Quintela <quintela@redhat.com>
Signed-off-by: Juan Quintela <quintela@redhat.com>
Remove the two atomic patches that broke mips32.
Please, apply.
-----BEGIN PGP SIGNATURE-----
iQIzBAABCAAdFiEEGJn/jt6/WMzuA0uC9IfvGFhy1yMFAmRGYTkACgkQ9IfvGFhy
1yMD5RAApL8bJTMpmkZ8afxG124/CID7fvg/WMp3vOTG/6923XZHfosUwqrCCvzN
8qfSfOl4P5Gtv1dOU+ZBcgoFS3tj00Ud2YhcZiSVUy5LZPJNJEfv4YzIErDTJq3I
wcv/CgHvK1CKJ5DZ1g9hqnRvw9qYiodDEHS7UxvhGzckFExHps2oWt9nDuEZefKV
XptOX7YDFYmWE87fp8+rQMYGZEN/6Cc7p4HmSt9I11CgLbeaqTpmKuwTv89PU9qV
7/X9kfoHNsKsVKw5WosEdRvEqhVQbvcCCxq+TGpeQz6d5U2mY7RVxQSNJxXNdD3P
uz7uannx+UhESgzf5GnwOMIcxWD6UMAcDt349IAWFbq5d1QGaXJ9fVVHVJDV1Irl
XHqxkugNMxRVZ8hQy5gSE6UTpeIjkIpSoZGnGS7E/iLMZHZBgv7s5VK21mYxn/QF
F9g3Ewo2lF+kpQ/ZEnQ9mFyCYtqOHOAOLAUa7/6WdGnUMuqQ47Fh+jbb+KdEyCLg
l7yXk2gXAb8SN6957Tlvo9okOB4NzhDPDXgvewAG/1yW4zL9hA+YCMvEvy90N8Be
rRKO7H9YlsW4wKjA//i2YNAbtaZN5+zeAS39m0exYmXA54AMufjWq/a7Ya/ix5Jo
452LEz5hA4ckXXtP715pKQjqafxWXbHSS1qw9LBfMYr5TEEWC6c=
=JTxg
-----END PGP SIGNATURE-----
Merge tag 'migration-20230420-pull-request' of https://gitlab.com/juan.quintela/qemu into staging
Migration Pull request (take 2)
Remove the two atomic patches that broke mips32.
Please, apply.
# -----BEGIN PGP SIGNATURE-----
#
# iQIzBAABCAAdFiEEGJn/jt6/WMzuA0uC9IfvGFhy1yMFAmRGYTkACgkQ9IfvGFhy
# 1yMD5RAApL8bJTMpmkZ8afxG124/CID7fvg/WMp3vOTG/6923XZHfosUwqrCCvzN
# 8qfSfOl4P5Gtv1dOU+ZBcgoFS3tj00Ud2YhcZiSVUy5LZPJNJEfv4YzIErDTJq3I
# wcv/CgHvK1CKJ5DZ1g9hqnRvw9qYiodDEHS7UxvhGzckFExHps2oWt9nDuEZefKV
# XptOX7YDFYmWE87fp8+rQMYGZEN/6Cc7p4HmSt9I11CgLbeaqTpmKuwTv89PU9qV
# 7/X9kfoHNsKsVKw5WosEdRvEqhVQbvcCCxq+TGpeQz6d5U2mY7RVxQSNJxXNdD3P
# uz7uannx+UhESgzf5GnwOMIcxWD6UMAcDt349IAWFbq5d1QGaXJ9fVVHVJDV1Irl
# XHqxkugNMxRVZ8hQy5gSE6UTpeIjkIpSoZGnGS7E/iLMZHZBgv7s5VK21mYxn/QF
# F9g3Ewo2lF+kpQ/ZEnQ9mFyCYtqOHOAOLAUa7/6WdGnUMuqQ47Fh+jbb+KdEyCLg
# l7yXk2gXAb8SN6957Tlvo9okOB4NzhDPDXgvewAG/1yW4zL9hA+YCMvEvy90N8Be
# rRKO7H9YlsW4wKjA//i2YNAbtaZN5+zeAS39m0exYmXA54AMufjWq/a7Ya/ix5Jo
# 452LEz5hA4ckXXtP715pKQjqafxWXbHSS1qw9LBfMYr5TEEWC6c=
# =JTxg
# -----END PGP SIGNATURE-----
# gpg: Signature made Mon 24 Apr 2023 12:00:09 PM BST
# gpg: using RSA key 1899FF8EDEBF58CCEE034B82F487EF185872D723
# gpg: Good signature from "Juan Quintela <quintela@redhat.com>" [undefined]
# gpg: aka "Juan Quintela <quintela@trasno.org>" [undefined]
# gpg: WARNING: This key is not certified with a trusted signature!
# gpg: There is no indication that the signature belongs to the owner.
# Primary key fingerprint: 1899 FF8E DEBF 58CC EE03 4B82 F487 EF18 5872 D723
* tag 'migration-20230420-pull-request' of https://gitlab.com/juan.quintela/qemu:
migration: Pass migrate_caps_check() the old and new caps
migration: rename enabled_capabilities to capabilities
migration/postcopy: Detect file system on dest host
vl.c: Create late backends before migration object
util/mmap-alloc: qemu_fd_getfs()
migration: Handle block device inactivation failures better
migration: Rename normal to normal_pages
migration: Rename duplicate to zero_pages
migration: Make postcopy_requests atomic
migration: Make dirty_sync_count atomic
migration: Make downtime_bytes atomic
migration: Make precopy_bytes atomic
migration: Make dirty_sync_missed_zero_copy atomic
migration: Make multifd_bytes atomic
migration: Update atomic stats out of the mutex
migration: Merge ram_counters and ram_atomic_counters
migration: remove extra whitespace character for code style
Signed-off-by: Richard Henderson <richard.henderson@linaro.org>
We used to pass the old capabilities array and the new
capabilities as a list.
Signed-off-by: Juan Quintela <quintela@redhat.com>
Reviewed-by: Vladimir Sementsov-Ogievskiy <vsementsov@yandex-team.ru>
It is clear from the context what that means, and such a long name
with the extra long names of the capabilities make very difficilut to
stay inside the 80 columns limit.
Signed-off-by: Juan Quintela <quintela@redhat.com>
Reviewed-by: Vladimir Sementsov-Ogievskiy <vsementsov@yandex-team.ru>
Postcopy requires the memory support userfaultfd to work. Right now we
check it but it's a bit too late (when switching to postcopy migration).
Do that early right at enabling of postcopy.
Note that this is still only a best effort because ramblocks can be
dynamically created. We can add check in hostmem creations and fail if
postcopy enabled, but maybe that's too aggressive.
Still, we have chance to fail the most obvious where we know there's an
existing unsupported ramblock.
Signed-off-by: Peter Xu <peterx@redhat.com>
Reviewed-by: Juan Quintela <quintela@redhat.com>
Signed-off-by: Juan Quintela <quintela@redhat.com>
