On PowerPC we have a small problem :). We can run both HV and PR style VMs on the same kvm fd. While this is great, it means that anything that's different between the two needs to have a token in form of a VM fd to find out which one we're asking for. The one thing where this bites us are CAPs. We ask for them on the kvm fd, not the vm fd. So we can only take a random guess whether the user is asking for HV or PR capabilities. So far we got away with this reasonably well - most people will only load one of the two modules and the only thing that *really* breaks is hypercall exposure to user space, so a PR guest will not be able to do KVM hypercalls when HV KVM is loaded on the host, making the magic page unavailable to it. But this still isn't a great situation to be in. Instead, we really should just make the CHECK_EXTENSION ioctl available at VM level. Then we know for sure what user space is asking for. Alex Alexander Graf (3): KVM: Rename and add argument to check_extension KVM: Allow KVM_CHECK_EXTENSION on the vm fd KVM: PPC: Book3S: Provide different CAPs based on HV or PR mode Documentation/virtual/kvm/api.txt | 5 +++- arch/arm/kvm/arm.c | 2 +- arch/ia64/kvm/kvm-ia64.c | 2 +- arch/mips/kvm/mips.c | 2 +- arch/powerpc/kvm/powerpc.c | 14 +++++++--- arch/s390/kvm/kvm-s390.c | 2 +- arch/x86/kvm/x86.c | 2 +- include/linux/kvm_host.h | 2 +- virt/kvm/kvm_main.c | 59 ++++++++++++++++++++------------------- 9 files changed, 51 insertions(+), 39 deletions(-) -- 1.8.1.4 -- To unsubscribe from this list: send the line "unsubscribe kvm" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
