On 4/11/24 09:34, Nikolay Borisov wrote:
On 11.04.24 г. 10:24 ч., Alexandre Chartre wrote:
When a system is not affected by the BHI bug then KVM should
configure guests with BHI_NO to ensure they won't enable any
BHI mitigation.
Signed-off-by: Alexandre Chartre <alexandre.chartre@xxxxxxxxxx>
---
arch/x86/kvm/x86.c | 3 +++
1 file changed, 3 insertions(+)
diff --git a/arch/x86/kvm/x86.c b/arch/x86/kvm/x86.c
index 984ea2089efc..f43d3c15a6b7 100644
--- a/arch/x86/kvm/x86.c
+++ b/arch/x86/kvm/x86.c
@@ -1678,6 +1678,9 @@ static u64 kvm_get_arch_capabilities(void)
if (!boot_cpu_has_bug(X86_BUG_GDS) || gds_ucode_mitigated())
data |= ARCH_CAP_GDS_NO;
+ if (!boot_cpu_has_bug(X86_BUG_BHI))
+ data |= ARCH_CAP_BHI_NO;
+
But this is already handled since ARCH_CAP_BHI_NO is added to
KVM_SUPPORTED_ARCH_CAP so when the host caps are read that bit is
going to be set there, if it's set for the physical cpu of course.
Correct, if the host has ARCH_CAP_BHI_NO then it will be propagated to the
guest. But the host might not have ARCH_CAP_BHI_NO set and not be affected
by BHI.
That's the case for example of Skylake servers: they don't have ARCH_CAP_BHI_NO,
but they are not affected by BHI because they don't have eIBRS. However, a guest
will think it is affected because it doesn't know if eIBRS is present on the
system (because virtualization can hide it).
I tested on Skylake:
Without the patch, both host and guest are running 6.9.0-rc3, then BHI mitigations are:
- Host: BHI: Not affected
- Guest: BHI: SW loop, KVM: SW loop
=> so guest enables BHI SW loop mitigation although host doesn't need mitigation.
With the patch on the host, guest still running 6.9.0-rc3, then BHI mitigations are:
- Host: BHI: Not affected
- Guest: BHI: Not affected
=> now guest doesn't enable BHI mitigation, like the host.
Thanks,
alex.
