summaryrefslogtreecommitdiffstats
path: root/hw/ppc405_uc.c
diff options
context:
space:
mode:
authorDavid Gibson2012-09-19 23:08:42 +0200
committerAlexander Graf2012-10-04 15:54:18 +0200
commitace9a2cbac9b2949aadc176ffa83a1d2a0873e2c (patch)
treef835fee8dd61d153e58a55bf0b33540abac7d701 /hw/ppc405_uc.c
parentpseries: Fix semantics of RTAS int-on, int-off and set-xive functions (diff)
downloadqemu-ace9a2cbac9b2949aadc176ffa83a1d2a0873e2c.tar.gz
qemu-ace9a2cbac9b2949aadc176ffa83a1d2a0873e2c.tar.xz
qemu-ace9a2cbac9b2949aadc176ffa83a1d2a0873e2c.zip
target-ppc: KVM: Fix some kernel version edge cases for kvmppc_reset_htab()
The kvmppc_reset_htab() function invokes the KVM_PPC_ALLOCATE_HTAB vm ioctl to request KVM to allocate and reset a hash page table for the guest - it returns the size of hash table allocated, or 0 to indicate that qemu needs to allocate the hash table itself. In practice qemu needs to allocate the htab for full emulation and with Book3sPR KVM, but the kernel has to allocate it for Book3sHV KVM (the hash table needs to be physically contiguous in that case). Unfortunately, the logic in this function is incorrect for some existing kernels. Specifically: * at least some PR KVM versions advertise the relevant capability but don't actually implement the ioctl(), returning ENOTTY. * For old kernels which don't have the capability, we currently return 0. This is correct for PV KVM, where we need to allocate the htab, but not for HV KVM - kernels of this era always allocate a 16MB hash table per guest. This patch corrects both of these edge cases. Signed-off-by: David Gibson <david@gibson.dropbear.id.au> Signed-off-by: Alexander Graf <agraf@suse.de>
Diffstat (limited to 'hw/ppc405_uc.c')
0 files changed, 0 insertions, 0 deletions