diff options
| author | David Hildenbrand <david@redhat.com> | 2024-12-19 15:41:09 +0100 |
|---|---|---|
| committer | David Hildenbrand <david@redhat.com> | 2024-12-21 15:59:59 +0100 |
| commit | 241e6b2d27b090b17cda5b011b2064544b0c458b (patch) | |
| tree | 91e6d07989218262c6184e00d9baa5a2fc181e4d /rust/qemu-api/src/offset_of.rs | |
| parent | f7c168657816486527727d860b73747d41f0c5f6 (diff) | |
| download | focaccia-qemu-241e6b2d27b090b17cda5b011b2064544b0c458b.tar.gz focaccia-qemu-241e6b2d27b090b17cda5b011b2064544b0c458b.zip | |
s390x/s390-stattrib-kvm: prepare for memory devices and sparse memory layouts
With memory devices, we will have storage attributes for memory that exceeds the initial ram size. Further, we can easily have memory holes, for which there (currently) are no storage attributes. In particular, with memory holes, KVM_S390_SET_CMMA_BITS will fail to set some storage attributes. So let's do it like we handle storage keys migration, relying on guest_phys_blocks_append(). However, in contrast to storage key migration, we will handle it on the migration destination. This is a preparation for virtio-mem support. Note that ever since the "early migration" feature was added (x-early-migration), the state of device blocks (plugged/unplugged) is migrated early such that guest_phys_blocks_append() will properly consider all currently plugged memory blocks and skip any unplugged ones. In the future, we should try getting rid of the large temporary buffer and also not send any attributes for any memory holes, just so they get ignored on the destination. Message-ID: <20241219144115.2820241-9-david@redhat.com> Acked-by: Michael S. Tsirkin <mst@redhat.com> Reviewed-by: Thomas Huth <thuth@redhat.com> Signed-off-by: David Hildenbrand <david@redhat.com>
Diffstat (limited to 'rust/qemu-api/src/offset_of.rs')
0 files changed, 0 insertions, 0 deletions