aboutsummaryrefslogtreecommitdiff
path: root/hmp.h
diff options
context:
space:
mode:
authorDavid Gibson <david@gibson.dropbear.id.au>2017-07-12 17:56:06 +1000
committerDavid Gibson <david@gibson.dropbear.id.au>2017-07-17 15:07:05 +1000
commit2772cf6be90e39919d0557ba3c57a77313ca9edf (patch)
tree5e763df3359b48a82e0cf45aef17d2fd57401441 /hmp.h
parent52b81ab5e95a64cb6973fc4d60d2319c4305ddf8 (diff)
pseries: Use smaller default hash page tables when guest can resize
We've now implemented a PAPR extension allowing PAPR guest to resize their hash page table (HPT) during runtime. This patch makes use of that facility to allocate smaller HPTs by default. Specifically when a guest is aware of the HPT resize facility, qemu sizes the HPT to the initial memory size, rather than the maximum memory size on the assumption that the guest will resize its HPT if necessary for hot plugged memory. When the initial memory size is much smaller than the maximum memory size (a common configuration with e.g. oVirt / RHEV) then this can save significant memory on the HPT. If the guest does *not* advertise HPT resize awareness when it makes the ibm,client-architecture-support call, qemu resizes the HPT for maxmimum memory size (unless it's been configured not to allow such guests at all). For now we make that reallocation assuming the guest has not yet used the HPT at all. That's true in practice, but not, strictly, an architectural or PAPR requirement. If we need to in future we can fix this by having the client-architecture-support call reboot the guest with the revised HPT size (the client-architecture-support call is explicitly permitted to trigger a reboot in this way). Signed-off-by: David Gibson <david@gibson.dropbear.id.au> Reviewed-by: Suraj Jitindar Singh <sjitindarsingh@gmail.com>
Diffstat (limited to 'hmp.h')
0 files changed, 0 insertions, 0 deletions