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(-)

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,
-- 
2.43.5

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>