On 27/11/18 20:05, Roman Kagan wrote: >>> Capabilities are a well-established and unambiguous negotiation >>> mechanism, why invent another one? Besides, not all features map >>> conveniently onto cpuid bits, e.g. currently we have two versions of >>> SynIC support, which differ in the way the userspace deals with it, but >>> not in the cpuid bits we expose in the guest. IMO such an ioctl would >>> bring more complexity rather than less. >> >> Yes, in that case (for bugfixes basically) you'd have to use >> capabilities. But if the feature is completely hidden to userspace >> except for the CPUID bit, it seems like a ioctl would be more consistent >> with the rest of the KVM API. > > So there will be some features that are more equal than others? Well, it's already like that. Some features have to be explicitly KVM_ENABLE_CAP'd because userspace has to be aware of them. But in many cases they can be enabled blindly, and in that case a CPUID-based API can help. The CPUID-based API already works well for processor features, MSRs, KVM paravirt features, etc. Unfortunately we cannot just reuse KVM_GET_SUPPORTED_CPUID because userspace expects KVM features to be at 0x40000000 rather than Hyper-V ones. > I think that it's the current scheme which is more consistent: there are > features that are implemented in KVM, and there are caps for negotiating > them with userspace, and then -- separately -- there's a mix of bits to > show to the guest in response to CPUID, which only the userspace has to > bother with. The only issue is how to present the "features that are implemented in KVM". Since they _are_ expressed as CPUID bits, it makes sense if userspace only has to know about those instead of having both capabilities and CPUID bits. Paolo
