Re: [PATCH v2 3/4] x86/kvm/hyper-v: direct mode for synthetic timers

[Paolo Bonzini]

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