I need a formletter for these...Oh, yes. This is only part of cpuid exposing process. Let me change the commit log.
GET_SUPPORTED_CPUID advertises support to userspace, it does not expose anything
to the guest.
Got it. Since XFD are separate feature from AMX, when trying to think about
On Sun, Feb 07, 2021, Jing Liu wrote:
Intel's Extended Feature Disable (XFD) feature is an extensionKVM must not advertise support until it actually has said support, i.e. this
to the XSAVE feature that allows an operating system to enable
a feature while preventing specific user threads from using
the feature. A processor that supports XFD enumerates
CPUID.(EAX=0DH,ECX=1):EAX[4] as 1.
Signed-off-by: Jing Liu <jing2.liu@xxxxxxxxxxxxxxx>
---
arch/x86/kvm/cpuid.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/arch/x86/kvm/cpuid.c b/arch/x86/kvm/cpuid.c
index 83637a2ff605..04a73c395c71 100644
--- a/arch/x86/kvm/cpuid.c
+++ b/arch/x86/kvm/cpuid.c
@@ -437,7 +437,7 @@ void kvm_set_cpu_caps(void)
);
kvm_cpu_cap_mask(CPUID_D_1_EAX,
- F(XSAVEOPT) | F(XSAVEC) | F(XGETBV1) | F(XSAVES)
+ F(XSAVEOPT) | F(XSAVEC) | F(XGETBV1) | F(XSAVES) | F(XFD)
patch needs to go at the end of the series.
Also, adding the kvm_cpu_cap flag in a separate patch isn't strictly required.
In most cases, I would go so far as to say that if there is additional enabling
to be done, advertising the feature should be done in the same patch that adds
the last bits of enabling. Putting the CPUID stuff in its own patch doesn't
usually add values, e.g. if there's a bug in the actual support code bisecting
will point at the wrong patch if userspace conditions its vCPU model on
GET_SUPPORTED_CPUID.
);
kvm_cpu_cap_mask(CPUID_8000_0001_ECX,
--
2.18.4