On Mon, 14 Jul 2014 19:03:35 +0200 Alexander Graf <agraf@xxxxxxx> wrote: > 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. I think this makes sense. It adds one situation we didn't have before, though: We now have the checking ioctl acting on a target where we also have the enabling ioctl. Previously, it made sense to advertise capabilities that can be enabled on the vcpus on the kvm fd; but what should happen for a capability that can be enabled on a vm if the vm fd is queried? Should it always be advertised, or only if it has been enabled? (I just noticed that we don't advertise KVM_CAP_S390_IRQCHIP, which is a capability that can be enabled per-vm...) -- 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
