[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
[Qemu-commits] [qemu/qemu] a52670: migration: Fix migration crash when t
|
From: |
Peter Maydell |
|
Subject: |
[Qemu-commits] [qemu/qemu] a52670: migration: Fix migration crash when target psize l... |
|
Date: |
Fri, 03 Feb 2023 11:00:42 -0800 |
Branch: refs/heads/staging
Home: https://github.com/qemu/qemu
Commit: a526701b03b773429853e684cada87fe58c29c11
https://github.com/qemu/qemu/commit/a526701b03b773429853e684cada87fe58c29c11
Author: Peter Xu <peterx@redhat.com>
Date: 2023-02-02 (Thu, 02 Feb 2023)
Changed paths:
M migration/ram.c
Log Message:
-----------
migration: Fix migration crash when target psize larger than host
Commit d9e474ea56 overlooked the case where the target psize is even larger
than the host psize. One example is Alpha has 8K page size and migration
will start to crash the source QEMU when running Alpha migration on x86.
Fix it by detecting that case and set host start/end just to cover the
single page to be migrated.
This will slightly optimize the common case where host psize equals to
guest psize so we don't even need to do the roundups, but that's trivial.
Cc: qemu-stable@nongnu.org
Reported-by: Thomas Huth <thuth@redhat.com>
Resolves: https://gitlab.com/qemu-project/qemu/-/issues/1456
Fixes: d9e474ea56 ("migration: Teach PSS about host page")
Signed-off-by: Peter Xu <peterx@redhat.com>
Reviewed-by: Thomas Huth <thuth@redhat.com>
Reviewed-by: Juan Quintela <quintela@redhat.com>
Signed-off-by: Juan Quintela <quintela@redhat.com>
Commit: c0b15c63fe2ac351d8a66ad76ad439266aa06092
https://github.com/qemu/qemu/commit/c0b15c63fe2ac351d8a66ad76ad439266aa06092
Author: Juan Quintela <quintela@redhat.com>
Date: 2023-02-02 (Thu, 02 Feb 2023)
Changed paths:
M hw/s390x/s390-stattrib.c
M hw/vfio/migration.c
M include/migration/register.h
M migration/block-dirty-bitmap.c
M migration/block.c
M migration/migration.c
M migration/ram.c
M migration/savevm.c
M migration/savevm.h
Log Message:
-----------
migration: No save_live_pending() method uses the QEMUFile parameter
So remove it everywhere.
Signed-off-by: Juan Quintela <quintela@redhat.com>
Reviewed-by: Dr. David Alan Gilbert <dgilbert@redhat.com>
Commit: 3d4f76371ada00a244753e18658d63bc31dfaf9d
https://github.com/qemu/qemu/commit/3d4f76371ada00a244753e18658d63bc31dfaf9d
Author: Juan Quintela <quintela@redhat.com>
Date: 2023-02-02 (Thu, 02 Feb 2023)
Changed paths:
M docs/devel/migration.rst
M docs/devel/vfio-migration.rst
M hw/s390x/s390-stattrib.c
M hw/vfio/migration.c
M hw/vfio/trace-events
M include/migration/register.h
M migration/block-dirty-bitmap.c
M migration/block.c
M migration/migration.c
M migration/ram.c
M migration/savevm.c
M migration/savevm.h
M migration/trace-events
Log Message:
-----------
migration: Split save_live_pending() into state_pending_*
We split the function into to:
- state_pending_estimate: We estimate the remaining state size without
stopping the machine.
- state pending_exact: We calculate the exact amount of remaining
state.
The only "device" that implements different functions for _estimate()
and _exact() is ram.
Signed-off-by: Juan Quintela <quintela@redhat.com>
Reviewed-by: Dr. David Alan Gilbert <dgilbert@redhat.com>
Commit: 1ae9dc04f6cc68005d379df0cf6e81b4c1517caa
https://github.com/qemu/qemu/commit/1ae9dc04f6cc68005d379df0cf6e81b4c1517caa
Author: Juan Quintela <quintela@redhat.com>
Date: 2023-02-02 (Thu, 02 Feb 2023)
Changed paths:
M hw/s390x/s390-stattrib.c
M hw/vfio/migration.c
M include/migration/register.h
M migration/block-dirty-bitmap.c
M migration/block.c
M migration/migration.c
M migration/ram.c
M migration/savevm.c
M migration/savevm.h
M migration/trace-events
Log Message:
-----------
migration: Remove unused threshold_size parameter
Until previous commit, save_live_pending() was used for ram. Now with
the split into state_pending_estimate() and state_pending_exact() it
is not needed anymore, so remove them.
Signed-off-by: Juan Quintela <quintela@redhat.com>
Reviewed-by: Dr. David Alan Gilbert <dgilbert@redhat.com>
Commit: eb7781ff79e7133b4ad960e6a163f6293b0ccbbf
https://github.com/qemu/qemu/commit/eb7781ff79e7133b4ad960e6a163f6293b0ccbbf
Author: Juan Quintela <quintela@redhat.com>
Date: 2023-02-02 (Thu, 02 Feb 2023)
Changed paths:
M migration/migration.c
Log Message:
-----------
migration: simplify migration_iteration_run()
Signed-off-by: Juan Quintela <quintela@redhat.com>
Reviewed-by: Dr. David Alan Gilbert <dgilbert@redhat.com>
Commit: 5cd7a0f62b8dc3730a3c3efd3fd1360135054283
https://github.com/qemu/qemu/commit/5cd7a0f62b8dc3730a3c3efd3fd1360135054283
Author: Peter Xu <peterx@redhat.com>
Date: 2023-02-02 (Thu, 02 Feb 2023)
Changed paths:
M include/qemu/userfaultfd.h
M migration/postcopy-ram.c
M tests/qtest/migration-test.c
M util/userfaultfd.c
Log Message:
-----------
util/userfaultfd: Add uffd_open()
Add a helper to create the uffd handle.
Reviewed-by: Philippe Mathieu-Daudé <philmd@linaro.org>
Reviewed-by: Juan Quintela <quintela@redhat.com>
Signed-off-by: Peter Xu <peterx@redhat.com>
Signed-off-by: Juan Quintela <quintela@redhat.com>
Commit: 95fb0f4ab6bed07ef888d4347faaa96d69cf0275
https://github.com/qemu/qemu/commit/95fb0f4ab6bed07ef888d4347faaa96d69cf0275
Author: David Hildenbrand <david@redhat.com>
Date: 2023-02-02 (Thu, 02 Feb 2023)
Changed paths:
M migration/ram.c
Log Message:
-----------
migration/ram: Fix populate_read_range()
Unfortunately, commit f7b9dcfbcf44 broke populate_read_range(): the loop
end condition is very wrong, resulting in that function not populating the
full range. Lets' fix that.
Fixes: f7b9dcfbcf44 ("migration/ram: Factor out populating pages readable in
ram_block_populate_pages()")
Cc: qemu-stable@nongnu.org
Reviewed-by: Peter Xu <peterx@redhat.com>
Reviewed-by: Juan Quintela <quintela@redhat.com>
Signed-off-by: David Hildenbrand <david@redhat.com>
Signed-off-by: Juan Quintela <quintela@redhat.com>
Commit: 5c2d7fcb694c9f948b13529dc3117789334350b4
https://github.com/qemu/qemu/commit/5c2d7fcb694c9f948b13529dc3117789334350b4
Author: David Hildenbrand <david@redhat.com>
Date: 2023-02-02 (Thu, 02 Feb 2023)
Changed paths:
M migration/ram.c
Log Message:
-----------
migration/ram: Fix error handling in ram_write_tracking_start()
If something goes wrong during uffd_change_protection(), we would miss
to unregister uffd-wp and not release our reference. Fix it by
performing the uffd_change_protection(true) last.
Note that a uffd_change_protection(false) on the recovery path without a
prior uffd_change_protection(false) is fine.
Fixes: 278e2f551a09 ("migration: support UFFD write fault processing in
ram_save_iterate()")
Cc: qemu-stable@nongnu.org
Reviewed-by: Peter Xu <peterx@redhat.com>
Reviewed-by: Juan Quintela <quintela@redhat.com>
Signed-off-by: David Hildenbrand <david@redhat.com>
Signed-off-by: Juan Quintela <quintela@redhat.com>
Commit: e00fe26f7837461a62cd31cbea060ba0bd79fb64
https://github.com/qemu/qemu/commit/e00fe26f7837461a62cd31cbea060ba0bd79fb64
Author: David Hildenbrand <david@redhat.com>
Date: 2023-02-02 (Thu, 02 Feb 2023)
Changed paths:
M migration/ram.c
Log Message:
-----------
migration/ram: Don't explicitly unprotect when unregistering uffd-wp
When unregistering uffd-wp, older kernels before commit f369b07c86143
("mm/uffd:reset write protection when unregister with wp-mode") won't
clear the uffd-wp PTE bit. When re-registering uffd-wp, the previous
uffd-wp PTE bits would trigger again. With above commit, the kernel will
clear the uffd-wp PTE bits when unregistering itself.
Consequently, we'll clear the uffd-wp PTE bits now twice -- whereby we
don't care about clearing them at all: a new background snapshot will
re-register uffd-wp and re-protect all memory either way.
So let's skip the manual clearing of uffd-wp. If ever relevant, we
could clear conditionally in uffd_unregister_memory() -- we just need a
way to figure out more recent kernels.
Reviewed-by: Peter Xu <peterx@redhat.com>
Reviewed-by: Juan Quintela <quintela@redhat.com>
Signed-off-by: David Hildenbrand <david@redhat.com>
Signed-off-by: Juan Quintela <quintela@redhat.com>
Commit: 31cc8e2e87de0d05f34f1438ad707990d917f167
https://github.com/qemu/qemu/commit/31cc8e2e87de0d05f34f1438ad707990d917f167
Author: David Hildenbrand <david@redhat.com>
Date: 2023-02-02 (Thu, 02 Feb 2023)
Changed paths:
M migration/ram.c
Log Message:
-----------
migration/ram: Rely on used_length for uffd_change_protection()
ram_mig_ram_block_resized() will abort migration (including background
snapshots) when resizing a RAMBlock. ram_block_populate_read() will only
populate RAM up to used_length, so at least for anonymous memory
protecting everything between used_length and max_length won't
actually be protected and is just a NOP.
So let's only protect everything up to used_length.
Note: it still makes sense to register uffd-wp for max_length, such
that RAM_UF_WRITEPROTECT is independent of a changing used_length.
Reviewed-by: Peter Xu <peterx@redhat.com>
Reviewed-by: Juan Quintela <quintela@redhat.com>
Signed-off-by: David Hildenbrand <david@redhat.com>
Signed-off-by: Juan Quintela <quintela@redhat.com>
Commit: cbb8175b4fcf2ad02cab1c8d2f125f18e5f7c071
https://github.com/qemu/qemu/commit/cbb8175b4fcf2ad02cab1c8d2f125f18e5f7c071
Author: David Hildenbrand <david@redhat.com>
Date: 2023-02-02 (Thu, 02 Feb 2023)
Changed paths:
M migration/ram.c
Log Message:
-----------
migration/ram: Optimize ram_write_tracking_start() for RamDiscardManager
ram_block_populate_read() already optimizes for RamDiscardManager.
However, ram_write_tracking_start() will still try protecting discarded
memory ranges.
Let's optimize, because discarded ranges don't map any pages and
(1) For anonymous memory, trying to protect using uffd-wp without a mapped
page is ignored by the kernel and consequently a NOP.
(2) For shared/file-backed memory, we will fill present page tables in the
range with PTE markers. However, we will even allocate page tables
just to fill them with unnecessary PTE markers and effectively
waste memory.
So let's exclude these ranges, just like ram_block_populate_read()
already does.
Reviewed-by: Peter Xu <peterx@redhat.com>
Reviewed-by: Juan Quintela <quintela@redhat.com>
Signed-off-by: David Hildenbrand <david@redhat.com>
Signed-off-by: Juan Quintela <quintela@redhat.com>
Commit: 182b80fa5b792eb28dde7f6cf9d62b7a02604ac6
https://github.com/qemu/qemu/commit/182b80fa5b792eb28dde7f6cf9d62b7a02604ac6
Author: David Hildenbrand <david@redhat.com>
Date: 2023-02-02 (Thu, 02 Feb 2023)
Changed paths:
M migration/savevm.c
Log Message:
-----------
migration/savevm: Move more savevm handling into vmstate_save()
Let's move more code into vmstate_save(), reducing code duplication and
preparing for reuse of vmstate_save() in qemu_savevm_state_setup(). We
have to move vmstate_save() to make the compiler happy.
We'll now also trace from qemu_save_device_state(), triggering the same
tracepoints as previously called from
qemu_savevm_state_complete_precopy_non_iterable() only. Note that
qemu_save_device_state() ignores iterable device state, such as RAM,
and consequently doesn't trigger some other trace points (e.g.,
trace_savevm_state_setup()).
Reviewed-by: Peter Xu <peterx@redhat.com>
Reviewed-by: Michael S. Tsirkin <mst@redhat.com>
Reviewed-by: Juan Quintela <quintela@redhat.com>
Signed-off-by: David Hildenbrand <david@redhat.com>
Signed-off-by: Juan Quintela <quintela@redhat.com>
Commit: fb0fa7320e0713228706851011a5a445d0ccf020
https://github.com/qemu/qemu/commit/fb0fa7320e0713228706851011a5a445d0ccf020
Author: David Hildenbrand <david@redhat.com>
Date: 2023-02-02 (Thu, 02 Feb 2023)
Changed paths:
M migration/migration.c
M migration/migration.h
M migration/savevm.c
Log Message:
-----------
migration/savevm: Prepare vmdesc json writer in qemu_savevm_state_setup()
... and store it in the migration state. This is a preparation for
storing selected vmds's already in qemu_savevm_state_setup().
Reviewed-by: Dr. David Alan Gilbert <dgilbert@redhat.com>
Reviewed-by: Peter Xu <peterx@redhat.com>
Reviewed-by: Michael S. Tsirkin <mst@redhat.com>
Reviewed-by: Juan Quintela <quintela@redhat.com>
Signed-off-by: David Hildenbrand <david@redhat.com>
Signed-off-by: Juan Quintela <quintela@redhat.com>
Commit: 582cd6763bbb1420a730fd35ef2e63e5466313e8
https://github.com/qemu/qemu/commit/582cd6763bbb1420a730fd35ef2e63e5466313e8
Author: David Hildenbrand <david@redhat.com>
Date: 2023-02-02 (Thu, 02 Feb 2023)
Changed paths:
M include/migration/vmstate.h
M migration/savevm.c
Log Message:
-----------
migration/savevm: Allow immutable device state to be migrated early (i.e.,
before RAM)
For virtio-mem, we want to have the plugged/unplugged state of memory
blocks available before migrating any actual RAM content, and perform
sanity checks before touching anything on the destination. This
information is immutable on the migration source while migration is active,
We want to use this information for proper preallocation support with
migration: currently, we don't preallocate memory on the migration target,
and especially with hugetlb, we can easily run out of hugetlb pages during
RAM migration and will crash (SIGBUS) instead of catching this gracefully
via preallocation.
Migrating device state via a VMSD before we start iterating is currently
impossible: the only approach that would be possible is avoiding a VMSD
and migrating state manually during save_setup(), to be restored during
load_state().
Let's allow for migrating device state via a VMSD early, during the
setup phase in qemu_savevm_state_setup(). To keep it simple, we
indicate applicable VMSD's using an "early_setup" flag.
Note that only very selected devices (i.e., ones seriously messing with
RAM setup) are supposed to make use of such early state migration.
While at it, also use a bool for the "unmigratable" member.
Reviewed-by: Peter Xu <peterx@redhat.com>
Reviewed-by: Michael S. Tsirkin <mst@redhat.com>
Reviewed-by: Juan Quintela <quintela@redhat.com>S
Signed-off-by: David Hildenbrand <david@redhat.com>
Signed-off-by: Juan Quintela <quintela@redhat.com>
Commit: de67ab27a5775560bdfc097d8b24686b80c4646a
https://github.com/qemu/qemu/commit/de67ab27a5775560bdfc097d8b24686b80c4646a
Author: David Hildenbrand <david@redhat.com>
Date: 2023-02-02 (Thu, 02 Feb 2023)
Changed paths:
M include/migration/vmstate.h
Log Message:
-----------
migration/vmstate: Introduce VMSTATE_WITH_TMP_TEST() and VMSTATE_BITMAP_TEST()
We'll make use of both next in the context of virtio-mem.
Reviewed-by: Dr. David Alan Gilbert <dgilbert@redhat.com>
Reviewed-by: Peter Xu <peterx@redhat.com>
Reviewed-by: Michael S. Tsirkin <mst@redhat.com>
Reviewed-by: Juan Quintela <quintela@redhat.com>S
Signed-off-by: David Hildenbrand <david@redhat.com>
Signed-off-by: Juan Quintela <quintela@redhat.com>
Commit: 62a6d789fdf686d5f882ee848f58f87fcd59e5b4
https://github.com/qemu/qemu/commit/62a6d789fdf686d5f882ee848f58f87fcd59e5b4
Author: David Hildenbrand <david@redhat.com>
Date: 2023-02-02 (Thu, 02 Feb 2023)
Changed paths:
M include/migration/misc.h
M migration/migration.c
M migration/ram.c
Log Message:
-----------
migration/ram: Factor out check for advised postcopy
Let's factor out this check, to be used in virtio-mem context next.
While at it, fix a spelling error in a related comment.
Reviewed-by: Peter Xu <peterx@redhat.com>
Reviewed-by: Michael S. Tsirkin <mst@redhat.com>
Reviewed-by: Juan Quintela <quintela@redhat.com>S
Signed-off-by: David Hildenbrand <david@redhat.com>
Signed-off-by: Juan Quintela <quintela@redhat.com>
Commit: 9dc0c81267a6fc83c7aa306b45bfafe300b25d72
https://github.com/qemu/qemu/commit/9dc0c81267a6fc83c7aa306b45bfafe300b25d72
Author: David Hildenbrand <david@redhat.com>
Date: 2023-02-02 (Thu, 02 Feb 2023)
Changed paths:
M hw/virtio/virtio-mem.c
Log Message:
-----------
virtio-mem: Fail if a memory backend with "prealloc=on" is specified
"prealloc=on" for the memory backend does not work as expected, as
virtio-mem will simply discard all preallocated memory immediately again.
In the best case, it's an expensive NOP. In the worst case, it's an
unexpected allocation error.
Instead, "prealloc=on" should be specified for the virtio-mem device only,
such that virtio-mem will try preallocating memory before plugging
memory dynamically to the guest. Fail if such a memory backend is
provided.
Tested-by: Michal Privoznik <mprivozn@redhat.com>
Reviewed-by: Dr. David Alan Gilbert <dgilbert@redhat.com>
Reviewed-by: Peter Xu <peterx@redhat.com>
Reviewed-by: Michael S. Tsirkin <mst@redhat.com>
Reviewed-by: Juan Quintela <quintela@redhat.com>S
Signed-off-by: David Hildenbrand <david@redhat.com>
Signed-off-by: Juan Quintela <quintela@redhat.com>
Commit: 31c0a9292f88d9560213d8a1224dbf44de370ae5
https://github.com/qemu/qemu/commit/31c0a9292f88d9560213d8a1224dbf44de370ae5
Author: David Hildenbrand <david@redhat.com>
Date: 2023-02-02 (Thu, 02 Feb 2023)
Changed paths:
M hw/core/machine.c
M hw/virtio/virtio-mem.c
M include/hw/virtio/virtio-mem.h
Log Message:
-----------
virtio-mem: Migrate immutable properties early
The bitmap and the size are immutable while migration is active: see
virtio_mem_is_busy(). We can migrate this information early, before
migrating any actual RAM content. Further, all information we need for
sanity checks is immutable as well.
Having this information in place early will, for example, allow for
properly preallocating memory before touching these memory locations
during RAM migration: this way, we can make sure that all memory was
actually preallocated and that any user errors (e.g., insufficient
hugetlb pages) can be handled gracefully.
In contrast, usable_region_size and requested_size can theoretically
still be modified on the source while the VM is running. Keep migrating
these properties the usual, late, way.
Use a new device property to keep behavior of compat machines
unmodified.
Reviewed-by: Peter Xu <peterx@redhat.com>
Reviewed-by: Michael S. Tsirkin <mst@redhat.com>
Reviewed-by: Juan Quintela <quintela@redhat.com>S
Signed-off-by: David Hildenbrand <david@redhat.com>
Signed-off-by: Juan Quintela <quintela@redhat.com>
Commit: ad0c67da5822ccc0519945ae36ca91b2879c5ae9
https://github.com/qemu/qemu/commit/ad0c67da5822ccc0519945ae36ca91b2879c5ae9
Author: David Hildenbrand <david@redhat.com>
Date: 2023-02-02 (Thu, 02 Feb 2023)
Changed paths:
M hw/virtio/virtio-mem.c
Log Message:
-----------
virtio-mem: Proper support for preallocation with migration
Ordinary memory preallocation runs when QEMU starts up and creates the
memory backends, before processing the incoming migration stream. With
virtio-mem, we don't know which memory blocks to preallocate before
migration started. Now that we migrate the virtio-mem bitmap early, before
migrating any RAM content, we can safely preallocate memory for all plugged
memory blocks before migrating any RAM content.
This is especially relevant for the following cases:
(1) User errors
With hugetlb/files, if we don't have sufficient backend memory available on
the migration destination, we'll crash QEMU (SIGBUS) during RAM migration
when running out of backend memory. Preallocating memory before actual
RAM migration allows for failing gracefully and informing the user about
the setup problem.
(2) Excluded memory ranges during migration
For example, virtio-balloon free page hinting will exclude some pages
from getting migrated. In that case, we won't crash during RAM
migration, but later, when running the VM on the destination, which is
bad.
To fix this for new QEMU machines that migrate the bitmap early,
preallocate the memory early, before any RAM migration. Warn with old
QEMU machines.
Getting postcopy right is a bit tricky, but we essentially now implement
the same (problematic) preallocation logic as ordinary preallocation:
preallocate memory early and discard it again before precopy starts. During
ordinary preallocation, discarding of RAM happens when postcopy is advised.
As the state (bitmap) is loaded after postcopy was advised but before
postcopy starts listening, we have to discard memory we preallocated
immediately again ourselves.
Note that nothing (not even hugetlb reservations) guarantees for postcopy
that backend memory (especially, hugetlb pages) are still free after they
were freed ones while discarding RAM. Still, allocating that memory at
least once helps catching some basic setup problems.
Before this change, trying to restore a VM when insufficient hugetlb
pages are around results in the process crashing to to a "Bus error"
(SIGBUS). With this change, QEMU fails gracefully:
qemu-system-x86_64: qemu_prealloc_mem: preallocating memory failed: Bad
address
qemu-system-x86_64: error while loading state for instance 0x0 of device
'0000:00:03.0/virtio-mem-device-early'
qemu-system-x86_64: load of migration failed: Cannot allocate memory
And we can even introspect the early migration data, including the
bitmap:
$ ./scripts/analyze-migration.py -f STATEFILE
{
"ram (2)": {
"section sizes": {
"0000:00:03.0/mem0": "0x0000000780000000",
"0000:00:04.0/mem1": "0x0000000780000000",
"pc.ram": "0x0000000100000000",
"/rom@etc/acpi/tables": "0x0000000000020000",
"pc.bios": "0x0000000000040000",
"0000:00:02.0/e1000.rom": "0x0000000000040000",
"pc.rom": "0x0000000000020000",
"/rom@etc/table-loader": "0x0000000000001000",
"/rom@etc/acpi/rsdp": "0x0000000000001000"
}
},
"0000:00:03.0/virtio-mem-device-early (51)": {
"tmp": "00 00 00 01 40 00 00 00 00 00 00 07 80 00 00 00 00 00 00 00 00 20
00 00 00 00 00 00",
"size": "0x0000000040000000",
"bitmap": "ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff [...]
},
"0000:00:04.0/virtio-mem-device-early (53)": {
"tmp": "00 00 00 08 c0 00 00 00 00 00 00 07 80 00 00 00 00 00 00 00 00 20
00 00 00 00 00 00",
"size": "0x00000001fa400000",
"bitmap": "ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff [...]
},
[...]
Reported-by: Jing Qi <jinqi@redhat.com>
Reviewed-by: Dr. David Alan Gilbert <dgilbert@redhat.com>
Reviewed-by: Peter Xu <peterx@redhat.com>
Reviewed-by: Michael S. Tsirkin <mst@redhat.com>
Reviewed-by: Juan Quintela <quintela@redhat.com>S
Signed-off-by: David Hildenbrand <david@redhat.com>
Signed-off-by: Juan Quintela <quintela@redhat.com>
Commit: 92338885f9f2fc264945adafd8285da3729fe8f3
https://github.com/qemu/qemu/commit/92338885f9f2fc264945adafd8285da3729fe8f3
Author: Peter Xu <peterx@redhat.com>
Date: 2023-02-02 (Thu, 02 Feb 2023)
Changed paths:
M migration/migration.c
Log Message:
-----------
migration: Show downtime during postcopy phase
The downtime should be displayed during postcopy phase because the
switchover phase is done. OTOH it's weird to show "expected downtime"
which can confuse what does that mean if the switchover has already
happened anyway.
This is a slight ABI change on QMP, but I assume it shouldn't affect
anyone.
Reviewed-by: Leonardo Bras <leobras@redhat.com>
Reviewed-by: Juan Quintela <quintela@redhat.com>
Signed-off-by: Peter Xu <peterx@redhat.com>
Signed-off-by: Juan Quintela <quintela@redhat.com>
Commit: 737efef5b9f22b22b4825f34fa2a16f99b5f99d7
https://github.com/qemu/qemu/commit/737efef5b9f22b22b4825f34fa2a16f99b5f99d7
Author: Fiona Ebner <f.ebner@proxmox.com>
Date: 2023-02-02 (Thu, 02 Feb 2023)
Changed paths:
M migration/rdma.c
Log Message:
-----------
migration/rdma: fix return value for qio_channel_rdma_{readv,writev}
upon errors. As the documentation in include/io/channel.h states, only
-1 and QIO_CHANNEL_ERR_BLOCK should be returned upon error. Other
values have the potential to confuse the call sites.
error_setg is used rather than error_setg_errno, because there are
certain code paths where -1 (as a non-errno) is propagated up (e.g.
starting from qemu_rdma_block_for_wrid or qemu_rdma_post_recv_control)
all the way to qio_channel_rdma_{readv,writev}.
Similar to a216ec85b7 ("migration/channel-block: fix return value for
qio_channel_block_{readv,writev}").
Suggested-by: Zhang Chen <chen.zhang@intel.com>
Reviewed-by: Juan Quintela <quintela@redhat.com>
Signed-off-by: Fiona Ebner <f.ebner@proxmox.com>
Signed-off-by: Juan Quintela <quintela@redhat.com>
Commit: 73d87536e8bcd0a318801f2a2b454e59926de186
https://github.com/qemu/qemu/commit/73d87536e8bcd0a318801f2a2b454e59926de186
Author: Dr. David Alan Gilbert <dgilbert@redhat.com>
Date: 2023-02-02 (Thu, 02 Feb 2023)
Changed paths:
M include/migration/vmstate.h
M migration/savevm.c
M migration/vmstate.c
Log Message:
-----------
migration: Add canary to VMSTATE_END_OF_LIST
We fairly regularly forget VMSTATE_END_OF_LIST markers off descriptions;
given that the current check is only for ->name being NULL, sometimes
we get unlucky and the code apparently works and no one spots the error.
Explicitly add a flag, VMS_END that should be set, and assert it is
set during the traversal.
Note: This can't go in until we update the copy of vmstate.h in slirp.
Suggested-by: Peter Maydell <peter.maydell@linaro.org>
Signed-off-by: Dr. David Alan Gilbert <dgilbert@redhat.com>
Reviewed-by: Peter Maydell <peter.maydell@linaro.org>
Reviewed-by: Philippe Mathieu-Daudé <f4bug@amsat.org>
Reviewed-by: Juan Quintela <quintela@redhat.com>
Signed-off-by: Juan Quintela <quintela@redhat.com>
Commit: 2840c3f56b151f6dc69115a688ee2dad970bb6c6
https://github.com/qemu/qemu/commit/2840c3f56b151f6dc69115a688ee2dad970bb6c6
Author: Dr. David Alan Gilbert <dgilbert@redhat.com>
Date: 2023-02-02 (Thu, 02 Feb 2023)
Changed paths:
M migration/savevm.c
Log Message:
-----------
migration: Perform vmsd structure check during tests
Perform a check on vmsd structures during test runs in the hope
of catching any missing terminators and other simple screwups.
Signed-off-by: Dr. David Alan Gilbert <dgilbert@redhat.com>
Reviewed-by: Peter Maydell <peter.maydell@linaro.org>
Reviewed-by: Juan Quintela <quintela@redhat.com>
Signed-off-by: Juan Quintela <quintela@redhat.com>
Commit: 71d028b9220bf0857a209a19a4e884a2ebd3721e
https://github.com/qemu/qemu/commit/71d028b9220bf0857a209a19a4e884a2ebd3721e
Author: Zhenzhong Duan <zhenzhong.duan@intel.com>
Date: 2023-02-02 (Thu, 02 Feb 2023)
Changed paths:
M migration/dirtyrate.c
Log Message:
-----------
migration/dirtyrate: Show sample pages only in page-sampling mode
The value of "Sample Pages" is confusing in mode other than page-sampling.
See below:
(qemu) calc_dirty_rate -b 10 520
(qemu) info dirty_rate
Status: measuring
Start Time: 11646834 (ms)
Sample Pages: 520 (per GB)
Period: 10 (sec)
Mode: dirty-bitmap
Dirty rate: (not ready)
(qemu) info dirty_rate
Status: measured
Start Time: 11646834 (ms)
Sample Pages: 0 (per GB)
Period: 10 (sec)
Mode: dirty-bitmap
Dirty rate: 2 (MB/s)
While it's totally useless in dirty-ring and dirty-bitmap mode, fix to
show it only in page-sampling mode.
Signed-off-by: Zhenzhong Duan <zhenzhong.duan@intel.com>
Reviewed-by: Peter Xu <peterx@redhat.com>
Reviewed-by: Juan Quintela <quintela@redhat.com>
Signed-off-by: Juan Quintela <quintela@redhat.com>
Commit: 0ae218e2de44061f09a81fc86a3f6d3f2027be0b
https://github.com/qemu/qemu/commit/0ae218e2de44061f09a81fc86a3f6d3f2027be0b
Author: manish.mishra <manish.mishra@nutanix.com>
Date: 2023-02-02 (Thu, 02 Feb 2023)
Changed paths:
M chardev/char-socket.c
M include/io/channel.h
M io/channel-buffer.c
M io/channel-command.c
M io/channel-file.c
M io/channel-null.c
M io/channel-socket.c
M io/channel-tls.c
M io/channel-websock.c
M io/channel.c
M migration/channel-block.c
M migration/rdma.c
M scsi/qemu-pr-helper.c
M tests/qtest/tpm-emu.c
M tests/unit/test-io-channel-socket.c
M util/vhost-user-server.c
Log Message:
-----------
io: Add support for MSG_PEEK for socket channel
MSG_PEEK peeks at the channel, The data is treated as unread and
the next read shall still return this data. This support is
currently added only for socket class. Extra parameter 'flags'
is added to io_readv calls to pass extra read flags like MSG_PEEK.
Reviewed-by: Peter Xu <peterx@redhat.com>
Reviewed-by: Daniel P. Berrange <berrange@redhat.com>
Reviewed-by: Juan Quintela <quintela@redhat.com>
Suggested-by: Daniel P. Berrange <berrange@redhat.com>
Signed-off-by: manish.mishra <manish.mishra@nutanix.com>
Signed-off-by: Juan Quintela <quintela@redhat.com>
Commit: 5ee6d3d1eeccd85aa2a835e82b8d9e1b4f7441e1
https://github.com/qemu/qemu/commit/5ee6d3d1eeccd85aa2a835e82b8d9e1b4f7441e1
Author: manish.mishra <manish.mishra@nutanix.com>
Date: 2023-02-02 (Thu, 02 Feb 2023)
Changed paths:
M migration/channel.c
M migration/channel.h
M migration/migration.c
M migration/multifd.c
M migration/multifd.h
M migration/postcopy-ram.c
M migration/postcopy-ram.h
Log Message:
-----------
migration: check magic value for deciding the mapping of channels
Current logic assumes that channel connections on the destination side are
always established in the same order as the source and the first one will
always be the main channel followed by the multifid or post-copy
preemption channel. This may not be always true, as even if a channel has a
connection established on the source side it can be in the pending state on
the destination side and a newer connection can be established first.
Basically causing out of order mapping of channels on the destination side.
Currently, all channels except post-copy preempt send a magic number, this
patch uses that magic number to decide the type of channel. This logic is
applicable only for precopy(multifd) live migration, as mentioned, the
post-copy preempt channel does not send any magic number. Also, tls live
migrations already does tls handshake before creating other channels, so
this issue is not possible with tls, hence this logic is avoided for tls
live migrations. This patch uses read peek to check the magic number of
channels so that current data/control stream management remains
un-effected.
Reviewed-by: Peter Xu <peterx@redhat.com>
Reviewed-by: Daniel P. Berrange <berrange@redhat.com>
Reviewed-by: Juan Quintela <quintela@redhat.com>
Suggested-by: Daniel P. Berrange <berrange@redhat.com>
Signed-off-by: manish.mishra <manish.mishra@nutanix.com>
Signed-off-by: Juan Quintela <quintela@redhat.com>
Commit: a48d3563efaf350c6a3820df6bd07677154bc003
https://github.com/qemu/qemu/commit/a48d3563efaf350c6a3820df6bd07677154bc003
Author: Peter Maydell <peter.maydell@linaro.org>
Date: 2023-02-03 (Fri, 03 Feb 2023)
Changed paths:
M chardev/char-socket.c
M docs/devel/migration.rst
M docs/devel/vfio-migration.rst
M hw/core/machine.c
M hw/s390x/s390-stattrib.c
M hw/vfio/migration.c
M hw/vfio/trace-events
M hw/virtio/virtio-mem.c
M include/hw/virtio/virtio-mem.h
M include/io/channel.h
M include/migration/misc.h
M include/migration/register.h
M include/migration/vmstate.h
M include/qemu/userfaultfd.h
M io/channel-buffer.c
M io/channel-command.c
M io/channel-file.c
M io/channel-null.c
M io/channel-socket.c
M io/channel-tls.c
M io/channel-websock.c
M io/channel.c
M migration/block-dirty-bitmap.c
M migration/block.c
M migration/channel-block.c
M migration/channel.c
M migration/channel.h
M migration/dirtyrate.c
M migration/migration.c
M migration/migration.h
M migration/multifd.c
M migration/multifd.h
M migration/postcopy-ram.c
M migration/postcopy-ram.h
M migration/ram.c
M migration/rdma.c
M migration/savevm.c
M migration/savevm.h
M migration/trace-events
M migration/vmstate.c
M scsi/qemu-pr-helper.c
M tests/qtest/migration-test.c
M tests/qtest/tpm-emu.c
M tests/unit/test-io-channel-socket.c
M util/userfaultfd.c
M util/vhost-user-server.c
Log Message:
-----------
Merge tag 'next-pull-request' of https://gitlab.com/juan.quintela/qemu into
staging
Migration PULL request, new try
Hi
It includes:
- David Hildenbrand fixes for virtio-men
- David Gilbert canary to detect problems
- Fix for rdma return values (Fiona)
- Peter Xu uffd_open fixes
- Peter Xu show right downtime for postcopy
- manish.mishra msg fix fixes
- my vfio changes.
Please apply.
Please, apply.
# -----BEGIN PGP SIGNATURE-----
#
# iQIzBAABCAAdFiEEGJn/jt6/WMzuA0uC9IfvGFhy1yMFAmPb34EACgkQ9IfvGFhy
# 1yMXoQ/+I8Sl19g+rmOox0PMFvx18PlHT9SCWBkBnQW8Q9fs3Vj/qADU7uztyrOc
# v+UeCK84ncuEftV4fWXq6c24PPVrAnaEw+Bvoj89iTj8TbE4nJo4sPnnHKrJi1fG
# l+pDdtvsPtW3yUUYnWHRDgeO+yTL6Ss1xbxRxK+KJBsPyRc9aUOlt+XwIOJVulRs
# CGpy2kXKCAgqalthKPTfKAUkd8Vya0eAu/G/pLq8jFv43SLg28jonkdDSlHQWdM1
# Ndmwx81kNf8lnA6ghhA4cxuj6ldK8nn9gJNuzgVVs2grWp4KJzsxf//48kR1DxGX
# vH7elA1Flo/pEo2TCKTyF3sAQq62bJvmor8co/TgWdyzfIa60eZFM79vRrwA8Pjd
# xyvX1YTDMmnOZVfWllYnfMVLcSEAJO1/jgY0JhW2zGPSwr2ONIGU/lht81FCzTcr
# R7721VHjtFLoX7Dwf+BK8Umg/A9AgWAXsZNACufxiiNPqIqNEkftK1fjL11ayCY0
# mcvcV0jZMeer5VKBDOW3ijSuSuVtl+39USQRYRSabXrvumRTD2TaDVww9LN6YtMn
# YY7WYjL4yeKLt7QV7+5P91oY2w1P8x6dwmn+3FNWJNP+wjK6vCFWDut4UrKSxZTc
# Fe18gts43Pyu+JlCSqmjSbSvAn8XRPcmQgCJlFunWcNNNfLQxIY=
# =Vv7q
# -----END PGP SIGNATURE-----
# gpg: Signature made Thu 02 Feb 2023 16:06:25 GMT
# gpg: using RSA key 1899FF8EDEBF58CCEE034B82F487EF185872D723
# gpg: Good signature from "Juan Quintela <quintela@redhat.com>" [full]
# gpg: aka "Juan Quintela <quintela@trasno.org>" [full]
# Primary key fingerprint: 1899 FF8E DEBF 58CC EE03 4B82 F487 EF18 5872 D723
* tag 'next-pull-request' of https://gitlab.com/juan.quintela/qemu: (26 commits)
migration: check magic value for deciding the mapping of channels
io: Add support for MSG_PEEK for socket channel
migration/dirtyrate: Show sample pages only in page-sampling mode
migration: Perform vmsd structure check during tests
migration: Add canary to VMSTATE_END_OF_LIST
migration/rdma: fix return value for qio_channel_rdma_{readv,writev}
migration: Show downtime during postcopy phase
virtio-mem: Proper support for preallocation with migration
virtio-mem: Migrate immutable properties early
virtio-mem: Fail if a memory backend with "prealloc=on" is specified
migration/ram: Factor out check for advised postcopy
migration/vmstate: Introduce VMSTATE_WITH_TMP_TEST() and VMSTATE_BITMAP_TEST()
migration/savevm: Allow immutable device state to be migrated early (i.e.,
before RAM)
migration/savevm: Prepare vmdesc json writer in qemu_savevm_state_setup()
migration/savevm: Move more savevm handling into vmstate_save()
migration/ram: Optimize ram_write_tracking_start() for RamDiscardManager
migration/ram: Rely on used_length for uffd_change_protection()
migration/ram: Don't explicitly unprotect when unregistering uffd-wp
migration/ram: Fix error handling in ram_write_tracking_start()
migration/ram: Fix populate_read_range()
...
Signed-off-by: Peter Maydell <peter.maydell@linaro.org>
Compare: https://github.com/qemu/qemu/compare/0730eab4d38f...a48d3563efaf
| [Prev in Thread] |
Current Thread |
[Next in Thread] |
- [Qemu-commits] [qemu/qemu] a52670: migration: Fix migration crash when target psize l...,
Peter Maydell <=