kvm: x86: replace kvm_spec_ctrl_test_value with runtime test on the host
To avoid complex and in some cases incorrect logic in
kvm_spec_ctrl_test_value, just try the guest's given value on the host
processor instead, and if it doesn't #GP, allow the guest to set it.
One such case is when host CPU supports STIBP mitigation
but doesn't support IBRS (as is the case with some Zen2 AMD cpus),
and in this case we were giving guest #GP when it tried to use STIBP
The reason why can can do the host test is that IA32_SPEC_CTRL msr is
passed to the guest, after the guest sets it to a non zero value
for the first time (due to performance reasons),
and as as result of this, it is pointless to emulate #GP condition on
this first access, in a different way than what the host CPU does.
This is based on a patch from Sean Christopherson, who suggested this idea.
The commit in question is marked for stable:
commit 841c2be09fe4f49 5fe5224952a419b d8c7e5b455
Author: Maxim Levitsky <email address hidden>
Date: Wed Jul 8 14:57:31 2020 +0300
kvm: x86: replace kvm_spec_ ctrl_test_ value with runtime test on the host
To avoid complex and in some cases incorrect logic in spec_ctrl_ test_value, just try the guest's given value on the host
kvm_
processor instead, and if it doesn't #GP, allow the guest to set it.
One such case is when host CPU supports STIBP mitigation
but doesn't support IBRS (as is the case with some Zen2 AMD cpus),
and in this case we were giving guest #GP when it tried to use STIBP
The reason why can can do the host test is that IA32_SPEC_CTRL msr is
passed to the guest, after the guest sets it to a non zero value
for the first time (due to performance reasons),
and as as result of this, it is pointless to emulate #GP condition on
this first access, in a different way than what the host CPU does.
This is based on a patch from Sean Christopherson, who suggested this idea.
Fixes: 6441fa6178f5 ("KVM: x86: avoid incorrect writes to host MSR_IA32_ SPEC_CTRL" )
Cc: <email address hidden>
Suggested-by: Sean Christopherson <email address hidden>
Signed-off-by: Maxim Levitsky <email address hidden>
Message-Id: <email address hidden>
Signed-off-by: Paolo Bonzini <email address hidden>
It appears to be in `v5.4.102` which is currently queued up for the cycle following the one just starting.