Re: [PATCH v2 4/7] KVM: x86: hyper-v: always advertise HV_STIMER_DIRECT_MODE_AVAILABLE

[Paolo Bonzini]

On 29/09/20 12:36, Vitaly Kuznetsov wrote:
>> Sorry for the late reply.  I think this is making things worse.  It's
>> obviously okay to add a system KVM_GET_SUPPORTED_HV_CPUID, and I guess
>> it makes sense to have bits in there that require to enable a
>> capability.  For example, KVM_GET_SUPPORTED_CPUID has a couple bits such
>> as X2APIC, that we return even if they require in-kernel irqchip.
>>
>> For the vCPU version however we should be able to copy the returned
>> leaves to KVM_SET_CPUID2, meaning that unsupported features should be
>> masked.
> What I don't quite like about exposing HV_STIMER_DIRECT_MODE_AVAILABLE
> conditionally is that we're requiring userspace to have a certain
> control flow: first, it needs to create irqchip and only then call
> KVM_GET_SUPPORTED_HV_CPUID or it won't know that
> HV_STIMER_DIRECT_MODE_AVAILABLE is supported. 
> 
> Also, are you only concerned about HV_STIMER_DIRECT_MODE_AVAILABLE? E.g.
> PATCH3 of this series is somewhat similar, it exposes eVMCS even when
> the corresponding CAP wasn't enabled.

All of them, but this was only about the vCPU ioctl.  I agree with you
that the system ioctl should return everything unconditionally.

But perhaps the best thing to do is to deprecate the vCPU ioctl and just
leave it as is with all its quirks.

Paolo

> While I slightly prefer to get rid of this conditional feature exposure
> once and for all, I don't really feel very strong about it. We can have
> the system ioctl which always exposes all supported features and vCPU
> version which only exposes what is currently enabled. We would, however,
> need to preserve some inconsistency as a legacy: e.g. SynIC bits are now
> exposed unconditionally, even before KVM_CAP_HYPERV_SYNIC[2] is enabled
> (and if we change that we will break at least QEMU).