s390x/s390-stattrib-kvm: prepare for memory devices and sparse memory layouts
authorDavid Hildenbrand <david@redhat.com>
Thu, 19 Dec 2024 14:41:09 +0000 (15:41 +0100)
committerDavid Hildenbrand <david@redhat.com>
Sat, 21 Dec 2024 14:59:59 +0000 (15:59 +0100)
commit241e6b2d27b090b17cda5b011b2064544b0c458b
tree91e6d07989218262c6184e00d9baa5a2fc181e4d
parentf7c168657816486527727d860b73747d41f0c5f6
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>
hw/s390x/s390-stattrib-kvm.c