hw/ppc/spapr_hcall: set htab_shift after kvmppc_resize_hpt_commit
commit9478956794c11239b7c1c3ef9ce95c883bb839a3
authorDaniel Henrique Barboza <danielhb@linux.vnet.ibm.com>
Tue, 13 Feb 2018 17:37:16 +0000 (13 15:37 -0200)
committerDavid Gibson <david@gibson.dropbear.id.au>
Fri, 16 Feb 2018 01:14:26 +0000 (16 12:14 +1100)
tree10951a64d42b952e96c2ce7f8bc4b01d4980d444
parent4b402e09e6aa40365a11ed0d258ac1e973d9725b
hw/ppc/spapr_hcall: set htab_shift after kvmppc_resize_hpt_commit

Newer kernels have a htab resize capability when adding or remove
memory. At these situations, the guest kernel might reallocate its
htab to a more suitable size based on the resulting memory.

However, we're not setting the new value back into the machine state
when a KVM guest resizes its htab. At first this doesn't seem harmful,
but when migrating or saving the guest state (via virsh managedsave,
for instance) this mismatch between the htab size of QEMU and the
kernel makes the guest hangs when trying to load its state.

Inside h_resize_hpt_commit, the hypercall that commits the hash page
resize changes, let's set spapr->htab_shift to the new value if we're
sure that kvmppc_resize_hpt_commit were successful.

While we're here, add a "not RADIX" sanity check as it is already done
in the related hypercall h_resize_hpt_prepare.

Fixes: https://github.com/open-power-host-os/qemu/issues/28
Reported-by: Satheesh Rajendran <sathnaga@linux.vnet.ibm.com>
Signed-off-by: Daniel Henrique Barboza <danielhb@linux.vnet.ibm.com>
Signed-off-by: David Gibson <david@gibson.dropbear.id.au>
hw/ppc/spapr_hcall.c