Igor Mammedov <imamm...@redhat.com> writes: > On Wed, 10 Feb 2021 17:40:28 +0100 > Vitaly Kuznetsov <vkuzn...@redhat.com> wrote: > >> Sometimes we'd like to know which features were explicitly enabled and which >> were explicitly disabled on the command line. E.g. it seems logical to handle >> 'hv_passthrough,hv_feature=off' as "enable everything supported by the host >> except for hv_feature" but this doesn't seem to be possible with the current >> 'hyperv_features' bit array. Introduce 'hv_features_on'/'hv_features_off' >> add-ons and track explicit enablement/disablement there. >> >> Note, it doesn't seem to be possible to fill 'hyperv_features' array during >> CPU creation time when 'hv-passthrough' is specified and we're running on >> an older kernel without KVM_CAP_SYS_HYPERV_CPUID support. To get the list >> of the supported Hyper-V features we need to actually create KVM VCPU and >> this happens much later. > > seems to me that we are returning back to +-feat parsing, this time only for > hyperv. > I'm not sure I like it back, especially considering we are going to > drop "-feat" priority for x86. > > now about impossible, see arm/kvm/virt, they create a 'sample' VCPU at KVM > init time to probe for some CPU features in advance. You can use similar > approach to prepare value for hyperv_features. >
KVM_CAP_SYS_HYPERV_CPUID is supported since 5.11 and eventually it'll make it to all kernels we care about so I'd really like to avoid any 'sample' CPUs for the time being. On/off parsing looks like a much lesser evil. -- Vitaly
