The shortlog (and changelog intro) are wrong. KVM isn't allowing FRED/LKGS to
be advertised to the guest. Userspace can advertise whatever it wants. The guest
will break badly without KVM support, but that doesn't stop userspace from
advertising a bogus vCPU model.
KVM: x86: Advertise support for FRED/LKGS to userspace
On Fri, Mar 28, 2025, Xin Li (Intel) wrote:
From: Xin Li <xin3.li@xxxxxxxxx>
Allow FRED/LKGS to be advertised to guests after changes required to
Please explain what LKGS is early in the changelog. I assumed it was a feature
of sorts; turns out it's a new instruction.
Actually, why wait this long to enumerate support for LKGS? I.e. why not have a
patch at the head of the series to enumerate support for LKGS? IIUC, LKGS doesn't
depend on FRED.
enable FRED in a KVM guest are in place.
LKGS is introduced with FRED to completely eliminate the need to swapgs
explicilty, because
1) FRED transitions ensure that an operating system can always operate
with its own GS base address.
2) LKGS behaves like the MOV to GS instruction except that it loads
the base address into the IA32_KERNEL_GS_BASE MSR instead of the
GS segment’s descriptor cache, which is exactly what Linux kernel
does to load a user level GS base. Thus there is no need to SWAPGS
away from the kernel GS base and an execution of SWAPGS causes #UD
if FRED transitions are enabled.
A FRED CPU must enumerate LKGS. When LKGS is not available, FRED must
not be enabled.
Signed-off-by: Xin Li <xin3.li@xxxxxxxxx>
Signed-off-by: Xin Li (Intel) <xin@xxxxxxxxx>
Tested-by: Shan Kang <shan.kang@xxxxxxxxx>
---
arch/x86/kvm/cpuid.c | 2 ++
1 file changed, 2 insertions(+)
diff --git a/arch/x86/kvm/cpuid.c b/arch/x86/kvm/cpuid.c
index 5e4d4934c0d3..8f290273aee1 100644
--- a/arch/x86/kvm/cpuid.c
+++ b/arch/x86/kvm/cpuid.c
@@ -992,6 +992,8 @@ void kvm_set_cpu_caps(void)
F(FZRM),
F(FSRS),
F(FSRC),
+ F(FRED),
+ F(LKGS),
These need to be X86_64_F, no?