Messages in this thread |  | | From | Jim Mattson <> | | Date | Fri, 6 Mar 2026 17:10:23 -0800 | | Subject | Re: [PATCH v4 04/11] x86/bhi: Make clear_bhb_loop() effective on newer CPUs |
| |
On Fri, Mar 6, 2026 at 5:01 PM Pawan Gupta <pawan.kumar.gupta@linux.intel.com> wrote: > > +Chao > > On Fri, Mar 06, 2026 at 04:35:49PM -0800, Jim Mattson wrote: > > > > > > I think we need an explicit CPUID bit that a hypervisor can set to > > > > > > indicate that the underlying hardware might be SPR or later. > > > > > > > > > > Something similar was attempted via virtual-MSRs in the below series: > > > > > > > > > > [RFC PATCH v3 09/10] KVM: VMX: Advertise MITI_CTRL_BHB_CLEAR_SEQ_S_SUPPORT > > > > > https://lore.kernel.org/lkml/20240410143446.797262-10-chao.gao@intel.com/ > > > > > > > > > > Do you think a rework of this approach would help? > > > > > > > > No, I think that whole idea is ill-conceived. As I said above, the > > > > hypervisor should just set IA32_SPEC_CTRL.BHI_DIS_S on the guest's > > > > behalf when BHI_CTRL is not advertised to the guest. I don't see any > > > > value in predicating this mitigation on guest usage of the short BHB > > > > clearing sequence. Just do it. > > > > > > There are cases where this would be detrimental: > > > > > > 1. A guest disabling the mitigation in favor of performance. > > > 2. A guest deploying the long SW sequence would suffer from two mitigations > > > for the same vulnerability. > > > > The guest is already getting a performance boost from the newer > > microarchitecture, so I think this argument is moot. > > For a Linux guest this is mostly true. IIRC, there is atleast one major > non-Linux OS that suffers heavily from BHI_DIS_S.
Presumably, this guest OS wants to deploy the long sequence (if it may run on SPR and later) and doesn't want BHI_DIS_S foisted on it. I don't recall that negotiation being possible with MSR_VIRTUAL_MITIGATION_CTRL.
|  |