aboutsummaryrefslogtreecommitdiff
path: root/trace
diff options
context:
space:
mode:
authorDavid Hildenbrand <david@redhat.com>2021-09-03 17:55:10 +0200
committerThomas Huth <thuth@redhat.com>2021-09-06 16:24:05 +0200
commit67db1306a253b87ea4a1fc4e4fc13758b74aa8b2 (patch)
tree5dcc598578638fd89416bc6de29ef505689c80bb /trace
parent380ac2bcce466f3b8f93eb749c7e85bfcf476cd6 (diff)
downloadqemu-67db1306a253b87ea4a1fc4e4fc13758b74aa8b2.zip
qemu-67db1306a253b87ea4a1fc4e4fc13758b74aa8b2.tar.gz
qemu-67db1306a253b87ea4a1fc4e4fc13758b74aa8b2.tar.bz2
hw/s390x/s390-skeys: use memory mapping to detect which storage keys to migrate
Let's use the guest_phys_blocks API to get physical memory regions that are well defined inside our physical address space and migrate the storage keys of these. This is a preparation for having memory besides initial ram defined in the guest physical address space, for example, via memory devices. We get rid of the ms->ram_size dependency. Please note that we will usually have very little (--> 1) physical ranges. With virtio-mem might have significantly more ranges in the future. If that turns out to be a problem (e.g., total memory footprint of the list), we could look into a memory mapping API that avoids creation of a list and instead triggers a callback for each range. Signed-off-by: David Hildenbrand <david@redhat.com> Reviewed-by: Thomas Huth <thuth@redhat.com> Message-Id: <20210903155514.44772-10-david@redhat.com> Signed-off-by: Thomas Huth <thuth@redhat.com>
Diffstat (limited to 'trace')
0 files changed, 0 insertions, 0 deletions