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

From: Paolo Bonzini
Date: Wed Nov 28 2018 - 03:43:44 EST

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.