On Fri, Dec 16, 2016 at 10:25:55AM +0100, Thomas Huth wrote: > On 15.12.2016 06:53, David Gibson wrote: > > This adds a new powerpc-specific KVM_CAP_SPAPR_RESIZE_HPT capability to > > advertise whether KVM is capable of handling the PAPR extensions for > > resizing the hashed page table during guest runtime. > > > > At present, HPT resizing is possible with KVM PR without kernel > > modification, since the HPT is managed within qemu. It's not possible yet > > with KVM HV, because the HPT is managed by KVM. At present, qemu has to > > use other capabilities which (by accident) reveal whether PR or HV is in > > use to know if it can advertise HPT resizing capability to the guest. > > > > To avoid ambiguity with existing kernels, the encoding is a bit odd. > > 0 means "unknown" since that's what previous kernels will return > > 1 means "HPT resize possible if available if and only if the HPT is allocated in > > userspace, rather than in the kernel". Userspace can check > > KVM_CAP_PPC_ALLOC_HTAB to determine if that's the case. In practice > > this will give the same results as userspace's fallback check. > > 2 will mean "HPT resize available and implemented via ioctl()s > > KVM_PPC_RESIZE_HPT_PREPARE and KVM_PPC_RESIZE_HPT_COMMIT" > > This encoding IMHO clearly needs some proper documentation in > Documentation/virtual/kvm/api.txt ... and maybe also some dedicated > #defines in an uapi header file. Ah, yeah. Actually I'm talking to paulus again to see if we can come up with a way to encode the necessary facts without something as weird as this one. -- David Gibson | I'll have my music baroque, and my code david AT gibson.dropbear.id.au | minimalist, thank you. NOT _the_ _other_ | _way_ _around_! http://www.ozlabs.org/~dgibson
Attachment:
signature.asc
Description: PGP signature
