aboutsummaryrefslogtreecommitdiffstats
path: root/tools/testing/selftests/kvm/x86/nested_exceptions_test.c
diff options
context:
space:
mode:
authorPaolo Bonzini <[email protected]>2025-02-04 16:13:24 +0000
committerPaolo Bonzini <[email protected]>2025-02-04 16:13:24 +0000
commitee3a66f431d689b796b9cb48aefd3d223540381c (patch)
tree0150cd864580bed980a9b920aa6310741ca5df48 /tools/testing/selftests/kvm/x86/nested_exceptions_test.c
parentLinux 6.14-rc1 (diff)
downloadkernel-ee3a66f431d689b796b9cb48aefd3d223540381c.tar.gz
kernel-ee3a66f431d689b796b9cb48aefd3d223540381c.zip
kvm: x86: SRSO_USER_KERNEL_NO is not synthesized
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 <[email protected]>
Diffstat (limited to 'tools/testing/selftests/kvm/x86/nested_exceptions_test.c')
0 files changed, 0 insertions, 0 deletions