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 /bsd-user/netbsd/syscall_nr.h | |
| parent | 380ac2bcce466f3b8f93eb749c7e85bfcf476cd6 (diff) | |
| download | focaccia-qemu-67db1306a253b87ea4a1fc4e4fc13758b74aa8b2.tar.gz focaccia-qemu-67db1306a253b87ea4a1fc4e4fc13758b74aa8b2.zip | |
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 'bsd-user/netbsd/syscall_nr.h')
0 files changed, 0 insertions, 0 deletions