> Am 15.07.2014 um 08:50 schrieb Cornelia Huck <cornelia.huck@xxxxxxxxxx>: > > 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? Check_extension tells us what we can potentially enable, not what is enabled. So it should always be advertised :). Alex > > (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
