[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [PATCH v4 16/21] i386: track explicit 'hv-*' features enablement/dis

From: Vitaly Kuznetsov
Subject: Re: [PATCH v4 16/21] i386: track explicit 'hv-*' features enablement/disablement
Date: Fri, 12 Feb 2021 09:45:52 +0100

Igor Mammedov <imammedo@redhat.com> writes:

> On Wed, 10 Feb 2021 17:40:28 +0100
> Vitaly Kuznetsov <vkuznets@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.


reply via email to

[Prev in Thread] Current Thread [Next in Thread]