| Message ID | 20250204161336.251962-1-pbonzini@redhat.com (mailing list archive) |
|---|---|
| State | New |
| Headers | show |
| Series | kvm: x86: SRSO_USER_KERNEL_NO is not synthesized | expand |
On Tue, Feb 04, 2025, Paolo Bonzini wrote: > SYNTHESIZED_F() generally is used together with setup_force_cpu_cap(), > i.e. when it makes sense to present the feature even if cpuid does not > have it *and* the VM is not able to see the difference. For example, > it can be used when mitigations on the host automatically protect > the guest as well. > > The "SYNTHESIZED_F(SRSO_USER_KERNEL_NO)" line came in as a conflict > resolution between the CPUID overhaul from the KVM tree and support > for the feature in the x86 tree. Using it right now does not hurt, > or make a difference for that matter, because there is no > setup_force_cpu_cap(X86_FEATURE_SRSO_USER_KERNEL_NO). However, it > is a little less future proof in case such a setup_force_cpu_cap() > appears later, for a case where the kernel somehow is not vulnerable > but the guest would have to apply the mitigation. > > Signed-off-by: Paolo Bonzini <pbonzini@redhat.com> > --- Reviewed-by: Sean Christopherson <seanjc@google.com>
diff --git a/arch/x86/kvm/cpuid.c b/arch/x86/kvm/cpuid.c index 2cbb3874ad39..8eb3a88707f2 100644 --- a/arch/x86/kvm/cpuid.c +++ b/arch/x86/kvm/cpuid.c @@ -1180,7 +1180,7 @@ void kvm_set_cpu_caps(void) SYNTHESIZED_F(SBPB), SYNTHESIZED_F(IBPB_BRTYPE), SYNTHESIZED_F(SRSO_NO), - SYNTHESIZED_F(SRSO_USER_KERNEL_NO), + F(SRSO_USER_KERNEL_NO), ); kvm_cpu_cap_init(CPUID_8000_0022_EAX,
SYNTHESIZED_F() generally is used together with setup_force_cpu_cap(), i.e. when it makes sense to present the feature even if cpuid does not have it *and* the VM is not able to see the difference. For example, it can be used when mitigations on the host automatically protect the guest as well. The "SYNTHESIZED_F(SRSO_USER_KERNEL_NO)" line came in as a conflict resolution between the CPUID overhaul from the KVM tree and support for the feature in the x86 tree. Using it right now does not hurt, or make a difference for that matter, because there is no setup_force_cpu_cap(X86_FEATURE_SRSO_USER_KERNEL_NO). However, it is a little less future proof in case such a setup_force_cpu_cap() appears later, for a case where the kernel somehow is not vulnerable but the guest would have to apply the mitigation. Signed-off-by: Paolo Bonzini <pbonzini@redhat.com> --- arch/x86/kvm/cpuid.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-)