[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
[Qemu-commits] [qemu/qemu] b390af: migration/rdma: Fix out of order wrid
|
From: |
Richard Henderson |
|
Subject: |
[Qemu-commits] [qemu/qemu] b390af: migration/rdma: Fix out of order wrid |
|
Date: |
Tue, 02 Nov 2021 08:45:52 -0700 |
Branch: refs/heads/master
Home: https://github.com/qemu/qemu
Commit: b390afd8c50b18b3d6c7ed76e8e066dc64b8e206
https://github.com/qemu/qemu/commit/b390afd8c50b18b3d6c7ed76e8e066dc64b8e206
Author: Li Zhijian <lizhijian@cn.fujitsu.com>
Date: 2021-11-01 (Mon, 01 Nov 2021)
Changed paths:
M migration/rdma.c
Log Message:
-----------
migration/rdma: Fix out of order wrid
destination:
../qemu/build/qemu-system-x86_64 -enable-kvm -netdev
tap,id=hn0,script=/etc/qemu-ifup,downscript=/etc/qemu-ifdown -device
e1000,netdev=hn0,mac=50:52:54:00:11:22 -boot c -drive
if=none,file=./Fedora-rdma-server-migration.qcow2,id=drive-virtio-disk0 -device
virtio-blk-pci,bus=pci.0,addr=0x4,drive=drive-virtio-disk0,id=virtio-disk0 -m
2048 -smp 2 -device piix3-usb-uhci -device usb-tablet -monitor stdio -vga qxl
-spice streaming-video=filter,port=5902,disable-ticketing -incoming
rdma:192.168.22.23:8888
qemu-system-x86_64: -spice streaming-video=filter,port=5902,disable-ticketing:
warning: short-form boolean option 'disable-ticketing' deprecated
Please use disable-ticketing=on instead
QEMU 6.0.50 monitor - type 'help' for more information
(qemu) trace-event qemu_rdma_block_for_wrid_miss on
(qemu) dest_init RDMA Device opened: kernel name rxe_eth0 uverbs device name
uverbs2, infiniband_verbs class device path
/sys/class/infiniband_verbs/uverbs2, infiniband class device path
/sys/class/infiniband/rxe_eth0, transport: (2) Ethernet
qemu_rdma_block_for_wrid_miss A Wanted wrid CONTROL SEND (2000) but got CONTROL
RECV (4000)
source:
../qemu/build/qemu-system-x86_64 -enable-kvm -netdev
tap,id=hn0,script=/etc/qemu-ifup,downscript=/etc/qemu-ifdown -device
e1000,netdev=hn0,mac=50:52:54:00:11:22 -boot c -drive
if=none,file=./Fedora-rdma-server.qcow2,id=drive-virtio-disk0 -device
virtio-blk-pci,bus=pci.0,addr=0x4,drive=drive-virtio-disk0,id=virtio-disk0 -m
2048 -smp 2 -device piix3-usb-uhci -device usb-tablet -monitor stdio -vga qxl
-spice streaming-video=filter,port=5901,disable-ticketing -S
qemu-system-x86_64: -spice streaming-video=filter,port=5901,disable-ticketing:
warning: short-form boolean option 'disable-ticketing' deprecated
Please use disable-ticketing=on instead
QEMU 6.0.50 monitor - type 'help' for more information
(qemu)
(qemu) trace-event qemu_rdma_block_for_wrid_miss on
(qemu) migrate -d rdma:192.168.22.23:8888
source_resolve_host RDMA Device opened: kernel name rxe_eth0 uverbs device name
uverbs2, infiniband_verbs class device path
/sys/class/infiniband_verbs/uverbs2, infiniband class device path
/sys/class/infiniband/rxe_eth0, transport: (2) Ethernet
(qemu) qemu_rdma_block_for_wrid_miss A Wanted wrid WRITE RDMA (1) but got
CONTROL RECV (4000)
NOTE: we use soft RoCE as the rdma device.
[root@iaas-rpma images]# rdma link show rxe_eth0/1
link rxe_eth0/1 state ACTIVE physical_state LINK_UP netdev eth0
This migration could not be completed when out of order(OOO) CQ event occurs.
The send queue and receive queue shared a same completion queue, and
qemu_rdma_block_for_wrid() will drop the CQs it's not interested in. But
the dropped CQs by qemu_rdma_block_for_wrid() could be later CQs it wants.
So in this case, qemu_rdma_block_for_wrid() will block forever.
OOO cases will occur in both source side and destination side. And a
forever blocking happens on only SEND and RECV are out of order. OOO between
'WRITE RDMA' and 'RECV' doesn't matter.
below the OOO sequence:
source destination
rdma_write_one() qemu_rdma_registration_handle()
1. S1: post_recv X D1: post_recv Y
2. wait for recv CQ event X
3. D2: post_send X ---------------+
4. wait for send CQ send event X (D2) |
5. recv CQ event X reaches (D2) |
6. +-S2: post_send Y |
7. | wait for send CQ event Y |
8. | recv CQ event Y (S2) (drop it) |
9. +-send CQ event Y reaches (S2) |
10. send CQ event X reaches (D2) -----+
11. wait recv CQ event Y (dropped by (8))
Although a hardware IB works fine in my a hundred of runs, the IB specification
doesn't guaratee the CQ order in such case.
Here we introduce a independent send completion queue to distinguish
ibv_post_send completion queue from the original mixed completion queue.
It helps us to poll the specific CQE we are really interested in.
Signed-off-by: Li Zhijian <lizhijian@cn.fujitsu.com>
Reviewed-by: Juan Quintela <quintela@redhat.com>
Signed-off-by: Juan Quintela <quintela@redhat.com>
Commit: 7786ae40ba4e7d5b9ebbfd07924f4379e218c6ef
https://github.com/qemu/qemu/commit/7786ae40ba4e7d5b9ebbfd07924f4379e218c6ef
Author: Hyman Huang(黄勇) <huangy81@chinatelecom.cn>
Date: 2021-11-01 (Mon, 01 Nov 2021)
Changed paths:
M accel/kvm/kvm-all.c
M accel/stubs/kvm-stub.c
M include/hw/core/cpu.h
M include/sysemu/kvm.h
Log Message:
-----------
KVM: introduce dirty_pages and kvm_dirty_ring_enabled
dirty_pages is used to calculate dirtyrate via dirty ring, when
enabled, kvm-reaper will increase the dirty pages after gfns
being dirtied.
kvm_dirty_ring_enabled shows if kvm-reaper is working. dirtyrate
thread could use it to check if measurement can base on dirty
ring feature.
Signed-off-by: Hyman Huang(黄勇) <huangy81@chinatelecom.cn>
Message-Id:
<fee5fb2ab17ec2159405fc54a3cff8e02322f816.1624040308.git.huangy81@chinatelecom.cn>
Reviewed-by: Peter Xu <peterx@redhat.com>
Reviewed-by: Juan Quintela <quintela@redhat.com>
Signed-off-by: Juan Quintela <quintela@redhat.com>
Commit: 63b41db4bc776e71384d14d68a8ec6e0aae5ea3a
https://github.com/qemu/qemu/commit/63b41db4bc776e71384d14d68a8ec6e0aae5ea3a
Author: Hyman Huang(黄勇) <huangy81@chinatelecom.cn>
Date: 2021-11-01 (Mon, 01 Nov 2021)
Changed paths:
M hw/i386/xen/xen-hvm.c
M include/exec/memory.h
M include/exec/ram_addr.h
M migration/ram.c
M softmmu/memory.c
M softmmu/trace-events
Log Message:
-----------
memory: make global_dirty_tracking a bitmask
since dirty ring has been introduced, there are two methods
to track dirty pages of vm. it seems that "logging" has
a hint on the method, so rename the global_dirty_log to
global_dirty_tracking would make description more accurate.
dirty rate measurement may start or stop dirty tracking during
calculation. this conflict with migration because stop dirty
tracking make migration leave dirty pages out then that'll be
a problem.
make global_dirty_tracking a bitmask can let both migration and
dirty rate measurement work fine. introduce GLOBAL_DIRTY_MIGRATION
and GLOBAL_DIRTY_DIRTY_RATE to distinguish what current dirty
tracking aims for, migration or dirty rate.
Signed-off-by: Hyman Huang(黄勇) <huangy81@chinatelecom.cn>
Message-Id:
<9c9388657cfa0301bd2c1cfa36e7cf6da4aeca19.1624040308.git.huangy81@chinatelecom.cn>
Reviewed-by: Peter Xu <peterx@redhat.com>
Reviewed-by: Juan Quintela <quintela@redhat.com>
Signed-off-by: Juan Quintela <quintela@redhat.com>
Commit: 71864eadd9a9933ef7e9460ae2fc93b3af98a181
https://github.com/qemu/qemu/commit/71864eadd9a9933ef7e9460ae2fc93b3af98a181
Author: Hyman Huang(黄勇) <huangy81@chinatelecom.cn>
Date: 2021-11-01 (Mon, 01 Nov 2021)
Changed paths:
M migration/dirtyrate.c
M migration/dirtyrate.h
M qapi/migration.json
Log Message:
-----------
migration/dirtyrate: introduce struct and adjust DirtyRateStat
introduce "DirtyRateMeasureMode" to specify what method should be
used to calculate dirty rate, introduce "DirtyRateVcpu" to store
dirty rate for each vcpu.
use union to store stat data of specific mode
Signed-off-by: Hyman Huang(黄勇) <huangy81@chinatelecom.cn>
Message-Id:
<661c98c40f40e163aa58334337af8f3ddf41316a.1624040308.git.huangy81@chinatelecom.cn>
Reviewed-by: Peter Xu <peterx@redhat.com>
Reviewed-by: Juan Quintela <quintela@redhat.com>
Signed-off-by: Juan Quintela <quintela@redhat.com>
Commit: 15eb2d644cbda3dd2ad5989e273b211e83c16623
https://github.com/qemu/qemu/commit/15eb2d644cbda3dd2ad5989e273b211e83c16623
Author: Hyman Huang(黄勇) <huangy81@chinatelecom.cn>
Date: 2021-11-01 (Mon, 01 Nov 2021)
Changed paths:
M migration/dirtyrate.c
Log Message:
-----------
migration/dirtyrate: adjust order of registering thread
registering get_dirtyrate thread in advance so that both
page-sampling and dirty-ring mode can be covered.
Signed-off-by: Hyman Huang(黄勇) <huangy81@chinatelecom.cn>
Message-Id:
<d7727581a8e86d4a42fc3eacf7f310419b9ebf7e.1624040308.git.huangy81@chinatelecom.cn>
Reviewed-by: Peter Xu <peterx@redhat.com>
Reviewed-by: Juan Quintela <quintela@redhat.com>
Signed-off-by: Juan Quintela <quintela@redhat.com>
Commit: 9865d0f68fbb4785fcc80d5a28fece8913f4098a
https://github.com/qemu/qemu/commit/9865d0f68fbb4785fcc80d5a28fece8913f4098a
Author: Hyman Huang(黄勇) <huangy81@chinatelecom.cn>
Date: 2021-11-01 (Mon, 01 Nov 2021)
Changed paths:
M migration/dirtyrate.c
Log Message:
-----------
migration/dirtyrate: move init step of calculation to main thread
since main thread may "query dirty rate" at any time, it's better
to move init step into main thead so that synchronization overhead
between "main" and "get_dirtyrate" can be reduced.
Signed-off-by: Hyman Huang(黄勇) <huangy81@chinatelecom.cn>
Message-Id:
<109f8077518ed2f13068e3bfb10e625e964780f1.1624040308.git.huangy81@chinatelecom.cn>
Reviewed-by: Peter Xu <peterx@redhat.com>
Reviewed-by: Juan Quintela <quintela@redhat.com>
Signed-off-by: Juan Quintela <quintela@redhat.com>
Commit: 0e21bf24608b801bcdf6057f47808613061ecbe3
https://github.com/qemu/qemu/commit/0e21bf24608b801bcdf6057f47808613061ecbe3
Author: Hyman Huang(黄勇) <huangy81@chinatelecom.cn>
Date: 2021-11-01 (Mon, 01 Nov 2021)
Changed paths:
M hmp-commands.hx
M migration/dirtyrate.c
M migration/trace-events
M qapi/migration.json
Log Message:
-----------
migration/dirtyrate: implement dirty-ring dirtyrate calculation
use dirty ring feature to implement dirtyrate calculation.
introduce mode option in qmp calc_dirty_rate to specify what
method should be used when calculating dirtyrate, either
page-sampling or dirty-ring should be passed.
introduce "dirty_ring:-r" option in hmp calc_dirty_rate to
indicate dirty ring method should be used for calculation.
Signed-off-by: Hyman Huang(黄勇) <huangy81@chinatelecom.cn>
Message-Id:
<7db445109bd18125ce8ec86816d14f6ab5de6a7d.1624040308.git.huangy81@chinatelecom.cn>
Reviewed-by: Peter Xu <peterx@redhat.com>
Reviewed-by: Juan Quintela <quintela@redhat.com>
Signed-off-by: Juan Quintela <quintela@redhat.com>
Commit: 4c170330aae4a4ed75c3a8638b7d4c5d9f365244
https://github.com/qemu/qemu/commit/4c170330aae4a4ed75c3a8638b7d4c5d9f365244
Author: Peter Xu <peterx@redhat.com>
Date: 2021-11-01 (Mon, 01 Nov 2021)
Changed paths:
M migration/migration.c
Log Message:
-----------
migration: Make migration blocker work for snapshots too
save_snapshot() checks migration blocker, which looks sane. At the meantime we
should also teach the blocker add helper to fail if during a snapshot, just
like for migrations.
Reviewed-by: Marc-André Lureau <marcandre.lureau@redhat.com>
Signed-off-by: Peter Xu <peterx@redhat.com>
Reviewed-by: Juan Quintela <quintela@redhat.com>
Signed-off-by: Juan Quintela <quintela@redhat.com>
Commit: 60fd680193119e7e4d50eccff7b55a0aadc934ab
https://github.com/qemu/qemu/commit/60fd680193119e7e4d50eccff7b55a0aadc934ab
Author: Peter Xu <peterx@redhat.com>
Date: 2021-11-01 (Mon, 01 Nov 2021)
Changed paths:
M include/migration/blocker.h
M migration/migration.c
Log Message:
-----------
migration: Add migrate_add_blocker_internal()
An internal version that removes -only-migratable implications. It can be used
for temporary migration blockers like dump-guest-memory.
Reviewed-by: Marc-André Lureau <marcandre.lureau@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: b7bc6b182883bb3097dde2a25d041f28bde2b89c
https://github.com/qemu/qemu/commit/b7bc6b182883bb3097dde2a25d041f28bde2b89c
Author: Peter Xu <peterx@redhat.com>
Date: 2021-11-01 (Mon, 01 Nov 2021)
Changed paths:
M dump/dump.c
Log Message:
-----------
dump-guest-memory: Block live migration
Both dump-guest-memory and live migration caches vm state at the beginning.
Either of them entering the other one will cause race on the vm state, and even
more severe on that (please refer to the crash report in the bug link).
Let's block live migration in dump-guest-memory, and that'll also block
dump-guest-memory if it detected that we're during a live migration.
Side note: migrate_del_blocker() can be called even if the blocker is not
inserted yet, so it's safe to unconditionally delete that blocker in
dump_cleanup (g_slist_remove allows no-entry-found case).
Suggested-by: Dr. David Alan Gilbert <dgilbert@redhat.com>
Bugzilla: https://bugzilla.redhat.com/show_bug.cgi?id=1996609
Signed-off-by: Peter Xu <peterx@redhat.com>
Reviewed-by: Marc-André Lureau <marcandre.lureau@redhat.com>
Reviewed-by: Juan Quintela <quintela@redhat.com>
Signed-off-by: Juan Quintela <quintela@redhat.com>
Commit: adaf9d92f868e6b9f23cb9a3929635e1ba961b3b
https://github.com/qemu/qemu/commit/adaf9d92f868e6b9f23cb9a3929635e1ba961b3b
Author: David Hildenbrand <david@redhat.com>
Date: 2021-11-01 (Mon, 01 Nov 2021)
Changed paths:
M include/exec/memory.h
M softmmu/memory.c
Log Message:
-----------
memory: Introduce replay_discarded callback for RamDiscardManager
Introduce replay_discarded callback similar to our existing
replay_populated callback, to be used my migration code to never migrate
discarded memory.
Acked-by: Peter Xu <peterx@redhat.com>
Signed-off-by: David Hildenbrand <david@redhat.com>
Reviewed-by: Juan Quintela <quintela@redhat.com>
Signed-off-by: Juan Quintela <quintela@redhat.com>
Commit: 372aa6fd738ef4c13dc6201fa34d2c8b9a6dde29
https://github.com/qemu/qemu/commit/372aa6fd738ef4c13dc6201fa34d2c8b9a6dde29
Author: David Hildenbrand <david@redhat.com>
Date: 2021-11-01 (Mon, 01 Nov 2021)
Changed paths:
M hw/virtio/virtio-mem.c
Log Message:
-----------
virtio-mem: Implement replay_discarded RamDiscardManager callback
Implement it similar to the replay_populated callback.
Acked-by: Peter Xu <peterx@redhat.com>
Signed-off-by: David Hildenbrand <david@redhat.com>
Reviewed-by: Juan Quintela <quintela@redhat.com>
Signed-off-by: Juan Quintela <quintela@redhat.com>
Commit: be39b4cd20695b95a479c941b2bad7d53a6971de
https://github.com/qemu/qemu/commit/be39b4cd20695b95a479c941b2bad7d53a6971de
Author: David Hildenbrand <david@redhat.com>
Date: 2021-11-01 (Mon, 01 Nov 2021)
Changed paths:
M migration/ram.c
Log Message:
-----------
migration/ram: Handle RAMBlocks with a RamDiscardManager on the migration
source
We don't want to migrate memory that corresponds to discarded ranges as
managed by a RamDiscardManager responsible for the mapped memory region of
the RAMBlock. The content of these pages is essentially stale and
without any guarantees for the VM ("logically unplugged").
Depending on the underlying memory type, even reading memory might populate
memory on the source, resulting in an undesired memory consumption. Of
course, on the destination, even writing a zeropage consumes memory,
which we also want to avoid (similar to free page hinting).
Currently, virtio-mem tries achieving that goal (not migrating "unplugged"
memory that was discarded) by going via qemu_guest_free_page_hint() - but
it's hackish and incomplete.
For example, background snapshots still end up reading all memory, as
they don't do bitmap syncs. Postcopy recovery code will re-add
previously cleared bits to the dirty bitmap and migrate them.
Let's consult the RamDiscardManager after setting up our dirty bitmap
initially and when postcopy recovery code reinitializes it: clear
corresponding bits in the dirty bitmaps (e.g., of the RAMBlock and inside
KVM). It's important to fixup the dirty bitmap *after* our initial bitmap
sync, such that the corresponding dirty bits in KVM are actually cleared.
As colo is incompatible with discarding of RAM and inhibits it, we don't
have to bother.
Note: if a misbehaving guest would use discarded ranges after migration
started we would still migrate that memory: however, then we already
populated that memory on the migration source.
Reviewed-by: Peter Xu <peterx@redhat.com>
Signed-off-by: David Hildenbrand <david@redhat.com>
Reviewed-by: Juan Quintela <quintela@redhat.com>
Signed-off-by: Juan Quintela <quintela@redhat.com>
Commit: f4578df3992fa0b68a096346bb615b9c9e01128d
https://github.com/qemu/qemu/commit/f4578df3992fa0b68a096346bb615b9c9e01128d
Author: David Hildenbrand <david@redhat.com>
Date: 2021-11-01 (Mon, 01 Nov 2021)
Changed paths:
M hw/virtio/virtio-mem.c
M include/hw/virtio/virtio-mem.h
Log Message:
-----------
virtio-mem: Drop precopy notifier
Migration code now properly handles RAMBlocks which are indirectly managed
by a RamDiscardManager. No need for manual handling via the free page
optimization interface, let's get rid of it.
Acked-by: Michael S. Tsirkin <mst@redhat.com>
Acked-by: Peter Xu <peterx@redhat.com>
Signed-off-by: David Hildenbrand <david@redhat.com>
Reviewed-by: Juan Quintela <quintela@redhat.com>
Signed-off-by: Juan Quintela <quintela@redhat.com>
Commit: 9470c5e0829c1ebd3ccfc7960de065d4fd6f212d
https://github.com/qemu/qemu/commit/9470c5e0829c1ebd3ccfc7960de065d4fd6f212d
Author: David Hildenbrand <david@redhat.com>
Date: 2021-11-01 (Mon, 01 Nov 2021)
Changed paths:
M migration/postcopy-ram.c
M migration/ram.c
M migration/ram.h
Log Message:
-----------
migration/postcopy: Handle RAMBlocks with a RamDiscardManager on the
destination
Currently, when someone (i.e., the VM) accesses discarded parts inside a
RAMBlock with a RamDiscardManager managing the corresponding mapped memory
region, postcopy will request migration of the corresponding page from the
source. The source, however, will never answer, because it refuses to
migrate such pages with undefined content ("logically unplugged"): the
pages are never dirty, and get_queued_page() will consequently skip
processing these postcopy requests.
Especially reading discarded ("logically unplugged") ranges is supposed to
work in some setups (for example with current virtio-mem), although it
barely ever happens: still, not placing a page would currently stall the
VM, as it cannot make forward progress.
Let's check the state via the RamDiscardManager (the state e.g.,
of virtio-mem is migrated during precopy) and avoid sending a request
that will never get answered. Place a fresh zero page instead to keep
the VM working. This is the same behavior that would happen
automatically without userfaultfd being active, when accessing virtual
memory regions without populated pages -- "populate on demand".
For now, there are valid cases (as documented in the virtio-mem spec) where
a VM might read discarded memory; in the future, we will disallow that.
Then, we might want to handle that case differently, e.g., warning the
user that the VM seems to be mis-behaving.
Reviewed-by: Peter Xu <peterx@redhat.com>
Signed-off-by: David Hildenbrand <david@redhat.com>
Reviewed-by: Juan Quintela <quintela@redhat.com>
Signed-off-by: Juan Quintela <quintela@redhat.com>
Commit: 7648297d40649bbffb296b2d8f2f388f19868759
https://github.com/qemu/qemu/commit/7648297d40649bbffb296b2d8f2f388f19868759
Author: David Hildenbrand <david@redhat.com>
Date: 2021-11-01 (Mon, 01 Nov 2021)
Changed paths:
M migration/migration.c
M migration/postcopy-ram.c
M migration/ram.c
Log Message:
-----------
migration: Simplify alignment and alignment checks
Let's use QEMU_ALIGN_DOWN() and friends to make the code a bit easier to
read.
Reviewed-by: Peter Xu <peterx@redhat.com>
Signed-off-by: David Hildenbrand <david@redhat.com>
Reviewed-by: Philippe Mathieu-Daudé <philmd@redhat.com>
Reviewed-by: Juan Quintela <quintela@redhat.com>
Signed-off-by: Juan Quintela <quintela@redhat.com>
Commit: f7b9dcfbcf44aa38d132038e9b675ea7e714a570
https://github.com/qemu/qemu/commit/f7b9dcfbcf44aa38d132038e9b675ea7e714a570
Author: David Hildenbrand <david@redhat.com>
Date: 2021-11-01 (Mon, 01 Nov 2021)
Changed paths:
M migration/ram.c
Log Message:
-----------
migration/ram: Factor out populating pages readable in
ram_block_populate_pages()
Let's factor out prefaulting/populating to make further changes easier to
review and add a comment what we are actually expecting to happen. While at
it, use the actual page size of the ramblock, which defaults to
qemu_real_host_page_size for anonymous memory. Further, rename
ram_block_populate_pages() to ram_block_populate_read() as well, to make
it clearer what we are doing.
In the future, we might want to use MADV_POPULATE_READ to speed up
population.
Reviewed-by: Peter Xu <peterx@redhat.com>
Signed-off-by: David Hildenbrand <david@redhat.com>
Reviewed-by: Juan Quintela <quintela@redhat.com>
Signed-off-by: Juan Quintela <quintela@redhat.com>
Commit: 6fee3a1fd9ecde99c43e659cf8eb6c35c116d05e
https://github.com/qemu/qemu/commit/6fee3a1fd9ecde99c43e659cf8eb6c35c116d05e
Author: David Hildenbrand <david@redhat.com>
Date: 2021-11-01 (Mon, 01 Nov 2021)
Changed paths:
M migration/ram.c
Log Message:
-----------
migration/ram: Handle RAMBlocks with a RamDiscardManager on background
snapshots
We already don't ever migrate memory that corresponds to discarded ranges
as managed by a RamDiscardManager responsible for the mapped memory region
of the RAMBlock.
virtio-mem uses this mechanism to logically unplug parts of a RAMBlock.
Right now, we still populate zeropages for the whole usable part of the
RAMBlock, which is undesired because:
1. Even populating the shared zeropage will result in memory getting
consumed for page tables.
2. Memory backends without a shared zeropage (like hugetlbfs and shmem)
will populate an actual, fresh page, resulting in an unintended
memory consumption.
Discarded ("logically unplugged") parts have to remain discarded. As
these pages are never part of the migration stream, there is no need to
track modifications via userfaultfd WP reliably for these parts.
Further, any writes to these ranges by the VM are invalid and the
behavior is undefined.
Note that Linux only supports userfaultfd WP on private anonymous memory
for now, which usually results in the shared zeropage getting populated.
The issue will become more relevant once userfaultfd WP supports shmem
and hugetlb.
Acked-by: Peter Xu <peterx@redhat.com>
Signed-off-by: David Hildenbrand <david@redhat.com>
Reviewed-by: Juan Quintela <quintela@redhat.com>
Signed-off-by: Juan Quintela <quintela@redhat.com>
Commit: 4998a37e4bf2bc47f76775e6e6a0cd50bacfb16a
https://github.com/qemu/qemu/commit/4998a37e4bf2bc47f76775e6e6a0cd50bacfb16a
Author: Hyman Huang(黄勇) <huangy81@chinatelecom.cn>
Date: 2021-11-01 (Mon, 01 Nov 2021)
Changed paths:
M include/exec/ram_addr.h
M migration/dirtyrate.c
Log Message:
-----------
memory: introduce total_dirty_pages to stat dirty pages
introduce global var total_dirty_pages to stat dirty pages
along with memory_global_dirty_log_sync.
Signed-off-by: Hyman Huang(黄勇) <huangy81@chinatelecom.cn>
Reviewed-by: Peter Xu <peterx@redhat.com>
Reviewed-by: Juan Quintela <quintela@redhat.com>
Signed-off-by: Juan Quintela <quintela@redhat.com>
Commit: 826b8bc80cb191557a4ce7cf0e155b436d2d1afa
https://github.com/qemu/qemu/commit/826b8bc80cb191557a4ce7cf0e155b436d2d1afa
Author: Hyman Huang(黄勇) <huangy81@chinatelecom.cn>
Date: 2021-11-01 (Mon, 01 Nov 2021)
Changed paths:
M hmp-commands.hx
M migration/dirtyrate.c
M qapi/migration.json
Log Message:
-----------
migration/dirtyrate: implement dirty-bitmap dirtyrate calculation
introduce dirty-bitmap mode as the third method of calc-dirty-rate.
implement dirty-bitmap dirtyrate calculation, which can be used
to measuring dirtyrate in the absence of dirty-ring.
introduce "dirty_bitmap:-b" option in hmp calc_dirty_rate to
indicate dirty bitmap method should be used for calculation.
Signed-off-by: Hyman Huang(黄勇) <huangy81@chinatelecom.cn>
Reviewed-by: Peter Xu <peterx@redhat.com>
Reviewed-by: Juan Quintela <quintela@redhat.com>
Signed-off-by: Juan Quintela <quintela@redhat.com>
Commit: 91e8394415f9bc9cd81c02bfafe02012855d4f98
https://github.com/qemu/qemu/commit/91e8394415f9bc9cd81c02bfafe02012855d4f98
Author: Richard Henderson <richard.henderson@linaro.org>
Date: 2021-11-02 (Tue, 02 Nov 2021)
Changed paths:
M accel/kvm/kvm-all.c
M accel/stubs/kvm-stub.c
M dump/dump.c
M hmp-commands.hx
M hw/i386/xen/xen-hvm.c
M hw/virtio/virtio-mem.c
M include/exec/memory.h
M include/exec/ram_addr.h
M include/hw/core/cpu.h
M include/hw/virtio/virtio-mem.h
M include/migration/blocker.h
M include/sysemu/kvm.h
M migration/dirtyrate.c
M migration/dirtyrate.h
M migration/migration.c
M migration/postcopy-ram.c
M migration/ram.c
M migration/ram.h
M migration/rdma.c
M migration/trace-events
M qapi/migration.json
M softmmu/memory.c
M softmmu/trace-events
Log Message:
-----------
Merge remote-tracking branch
'remotes/juanquintela/tags/migration-20211031-pull-request' into staging
Migration Pull request
Hi
this includes pending bits of migration patches.
- virtio-mem support by David Hildenbrand
- dirtyrate improvements by Hyman Huang
- fix rdma wrid by Li Zhijian
- dump-guest-memory fixes by Peter Xu
Pleas apply.
Thanks, Juan.
# gpg: Signature made Mon 01 Nov 2021 06:03:44 PM EDT
# gpg: using RSA key 1899FF8EDEBF58CCEE034B82F487EF185872D723
# gpg: Good signature from "Juan Quintela <quintela@redhat.com>" [full]
# gpg: aka "Juan Quintela <quintela@trasno.org>" [full]
* remotes/juanquintela/tags/migration-20211031-pull-request:
migration/dirtyrate: implement dirty-bitmap dirtyrate calculation
memory: introduce total_dirty_pages to stat dirty pages
migration/ram: Handle RAMBlocks with a RamDiscardManager on background
snapshots
migration/ram: Factor out populating pages readable in
ram_block_populate_pages()
migration: Simplify alignment and alignment checks
migration/postcopy: Handle RAMBlocks with a RamDiscardManager on the
destination
virtio-mem: Drop precopy notifier
migration/ram: Handle RAMBlocks with a RamDiscardManager on the migration
source
virtio-mem: Implement replay_discarded RamDiscardManager callback
memory: Introduce replay_discarded callback for RamDiscardManager
dump-guest-memory: Block live migration
migration: Add migrate_add_blocker_internal()
migration: Make migration blocker work for snapshots too
migration/dirtyrate: implement dirty-ring dirtyrate calculation
migration/dirtyrate: move init step of calculation to main thread
migration/dirtyrate: adjust order of registering thread
migration/dirtyrate: introduce struct and adjust DirtyRateStat
memory: make global_dirty_tracking a bitmask
KVM: introduce dirty_pages and kvm_dirty_ring_enabled
migration/rdma: Fix out of order wrid
Signed-off-by: Richard Henderson <richard.henderson@linaro.org>
Compare: https://github.com/qemu/qemu/compare/f79bb385c0fb...91e8394415f9