Paolo Bonzini <pbonzini@xxxxxxxxxx> writes: > 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. > Ok, I'll do exactly that. I'm not sure if there are any KVM_GET_SUPPORTED_HV_CPUID users out there bisedes QEMU/selftest but let's take the 'safest' approach. -- Vitaly
