summary refs log tree commit diff stats
path: root/bsd-user/netbsd/syscall_nr.h
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 /bsd-user/netbsd/syscall_nr.h
parent380ac2bcce466f3b8f93eb749c7e85bfcf476cd6 (diff)
downloadfocaccia-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