]> git.ipfire.org Git - thirdparty/qemu.git/commit
pseries: Use smaller default hash page tables when guest can resize
authorDavid Gibson <david@gibson.dropbear.id.au>
Wed, 12 Jul 2017 07:56:06 +0000 (17:56 +1000)
committerDavid Gibson <david@gibson.dropbear.id.au>
Mon, 17 Jul 2017 05:07:05 +0000 (15:07 +1000)
commit2772cf6be90e39919d0557ba3c57a77313ca9edf
tree5e763df3359b48a82e0cf45aef17d2fd57401441
parent52b81ab5e95a64cb6973fc4d60d2319c4305ddf8
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>
hw/ppc/spapr.c
hw/ppc/spapr_hcall.c
include/hw/ppc/spapr.h
include/hw/ppc/spapr_ovec.h