| Message ID | 20220117074531.76925-1-likexu@tencent.com (mailing list archive) |
|---|---|
| State | New, archived |
| Headers | show |
| Series | KVM: x86/cpuid: Clear XFD for component i if the base feature is missing | expand |
On 1/17/22 08:45, Like Xu wrote: > From: Like Xu <likexu@tencent.com> > > According to Intel extended feature disable (XFD) spec, the sub-function i > (i > 1) of CPUID function 0DH enumerates "details for state component i. > ECX[2] enumerates support for XFD support for this state component." > > If KVM does not report F(XFD) feature (e.g. due to CONFIG_X86_64), > then the corresponding XFD support for any state component i > should also be removed. Translate this dependency into KVM terms. > > Fixes: 690a757d610e ("kvm: x86: Add CPUID support for Intel AMX") > Signed-off-by: Like Xu <likexu@tencent.com> > --- > arch/x86/kvm/cpuid.c | 3 +++ > 1 file changed, 3 insertions(+) > > diff --git a/arch/x86/kvm/cpuid.c b/arch/x86/kvm/cpuid.c > index c55e57b30e81..e96efef4f048 100644 > --- a/arch/x86/kvm/cpuid.c > +++ b/arch/x86/kvm/cpuid.c > @@ -886,6 +886,9 @@ static inline int __do_cpuid_func(struct kvm_cpuid_array *array, u32 function) > --array->nent; > continue; > } > + > + if (!kvm_cpu_cap_has(X86_FEATURE_XFD)) > + entry->ecx &= ~BIT_ULL(2); > entry->edx = 0; > } > break; Generally this is something that is left to userspace. Apart from the usecase of "call KVM_GET_SUPPORTED_CPUID and pass it to KVM_SET_CPUID2", userspace should know what any changed bits mean. Paolo
On 18/1/2022 1:31 am, Paolo Bonzini wrote: > On 1/17/22 08:45, Like Xu wrote: >> From: Like Xu <likexu@tencent.com> >> >> According to Intel extended feature disable (XFD) spec, the sub-function i >> (i > 1) of CPUID function 0DH enumerates "details for state component i. >> ECX[2] enumerates support for XFD support for this state component." >> >> If KVM does not report F(XFD) feature (e.g. due to CONFIG_X86_64), >> then the corresponding XFD support for any state component i >> should also be removed. Translate this dependency into KVM terms. >> >> Fixes: 690a757d610e ("kvm: x86: Add CPUID support for Intel AMX") >> Signed-off-by: Like Xu <likexu@tencent.com> >> --- >> arch/x86/kvm/cpuid.c | 3 +++ >> 1 file changed, 3 insertions(+) >> >> diff --git a/arch/x86/kvm/cpuid.c b/arch/x86/kvm/cpuid.c >> index c55e57b30e81..e96efef4f048 100644 >> --- a/arch/x86/kvm/cpuid.c >> +++ b/arch/x86/kvm/cpuid.c >> @@ -886,6 +886,9 @@ static inline int __do_cpuid_func(struct kvm_cpuid_array >> *array, u32 function) >> --array->nent; >> continue; >> } >> + >> + if (!kvm_cpu_cap_has(X86_FEATURE_XFD)) >> + entry->ecx &= ~BIT_ULL(2); >> entry->edx = 0; >> } >> break; > > Generally this is something that is left to userspace. Apart from the usecase > of "call KVM_GET_SUPPORTED_CPUID and pass it to KVM_SET_CPUID2", userspace > should know what any changed bits mean. > > Paolo > I totally agree that setting the appropriate CPUID bits for a feature is a user space thing. But this patch is more focused on fixing a different type of problem, which is that the capabilities exposed by KVM should not *contradict each other* : a user space may be confused with the current code base : - why KVM does not have F(XFD) feature (MSR_IA32_XFD and XFD_ERR non-exit), - but KVM reports XFD support for state component i individually; This is like KVM reporting PEBS when no PMU capacity is reported (due to module param). Does this clarification help ? Thanks, Like Xu
On 1/18/22 07:43, Like Xu wrote: > On 18/1/2022 1:31 am, Paolo Bonzini wrote: >> On 1/17/22 08:45, Like Xu wrote: >>> From: Like Xu <likexu@tencent.com> >>> >>> According to Intel extended feature disable (XFD) spec, the >>> sub-function i >>> (i > 1) of CPUID function 0DH enumerates "details for state component i. >>> ECX[2] enumerates support for XFD support for this state component." >>> >>> If KVM does not report F(XFD) feature (e.g. due to CONFIG_X86_64), >>> then the corresponding XFD support for any state component i >>> should also be removed. Translate this dependency into KVM terms. >>> >>> Fixes: 690a757d610e ("kvm: x86: Add CPUID support for Intel AMX") >>> Signed-off-by: Like Xu <likexu@tencent.com> >>> --- >>> arch/x86/kvm/cpuid.c | 3 +++ >>> 1 file changed, 3 insertions(+) >>> >>> diff --git a/arch/x86/kvm/cpuid.c b/arch/x86/kvm/cpuid.c >>> index c55e57b30e81..e96efef4f048 100644 >>> --- a/arch/x86/kvm/cpuid.c >>> +++ b/arch/x86/kvm/cpuid.c >>> @@ -886,6 +886,9 @@ static inline int __do_cpuid_func(struct >>> kvm_cpuid_array *array, u32 function) >>> --array->nent; >>> continue; >>> } >>> + >>> + if (!kvm_cpu_cap_has(X86_FEATURE_XFD)) >>> + entry->ecx &= ~BIT_ULL(2); >>> entry->edx = 0; >>> } >>> break; >> >> Generally this is something that is left to userspace. Apart from the >> usecase of "call KVM_GET_SUPPORTED_CPUID and pass it to >> KVM_SET_CPUID2", userspace should know what any changed bits mean. >> >> Paolo >> > > I totally agree that setting the appropriate CPUID bits for a feature is > a user space thing. > > But this patch is more focused on fixing a different type of problem, > which is > that the capabilities exposed by KVM should not *contradict each other* : > > a user space may be confused with the current code base : > - why KVM does not have F(XFD) feature (MSR_IA32_XFD and XFD_ERR > non-exit), > - but KVM reports XFD support for state component i individually; Got it. Yeah, the patch makes sense for the sake of CONFIG_X86_64. Paolo > This is like KVM reporting PEBS when no PMU capacity is reported (due to > module param).
diff --git a/arch/x86/kvm/cpuid.c b/arch/x86/kvm/cpuid.c index c55e57b30e81..e96efef4f048 100644 --- a/arch/x86/kvm/cpuid.c +++ b/arch/x86/kvm/cpuid.c @@ -886,6 +886,9 @@ static inline int __do_cpuid_func(struct kvm_cpuid_array *array, u32 function) --array->nent; continue; } + + if (!kvm_cpu_cap_has(X86_FEATURE_XFD)) + entry->ecx &= ~BIT_ULL(2); entry->edx = 0; } break;