diff options
author | David Hildenbrand <david@redhat.com> | 2021-09-03 17:55:10 +0200 |
---|---|---|
committer | Thomas Huth <thuth@redhat.com> | 2021-09-06 16:24:05 +0200 |
commit | 67db1306a253b87ea4a1fc4e4fc13758b74aa8b2 (patch) | |
tree | 5dcc598578638fd89416bc6de29ef505689c80bb /trace | |
parent | 380ac2bcce466f3b8f93eb749c7e85bfcf476cd6 (diff) | |
download | qemu-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