From: Pawan Gupta <pawan.kumar.gupta@linux.intel.com>
To: Jim Mattson <jmattson@google.com>
Cc: x86@kernel.org, David Kaplan <david.kaplan@amd.com>,
Nikolay Borisov <nik.borisov@suse.com>,
"H. Peter Anvin" <hpa@zytor.com>,
Josh Poimboeuf <jpoimboe@kernel.org>,
Sean Christopherson <seanjc@google.com>,
Paolo Bonzini <pbonzini@redhat.com>,
Borislav Petkov <bp@alien8.de>,
Dave Hansen <dave.hansen@linux.intel.com>,
linux-kernel@vger.kernel.org, kvm@vger.kernel.org,
Asit Mallick <asit.k.mallick@intel.com>,
Tao Zhang <tao1.zhang@intel.com>,
David Dunn <daviddunn@google.com>,
chao.gao@intel.com
Subject: Re: [PATCH v4 04/11] x86/bhi: Make clear_bhb_loop() effective on newer CPUs
Date: Fri, 6 Mar 2026 18:41:32 -0800 [thread overview]
Message-ID: <20260307024132.wleqtpovzd6wtvm7@desk> (raw)
In-Reply-To: <CALMp9eQGZcekQ3QtL=J7TqHJ9YfZ+SbrgY5P8fp14p4KNThYmw@mail.gmail.com>
On Fri, Mar 06, 2026 at 05:10:23PM -0800, Jim Mattson wrote:
> 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.
Patch 4/10 of that series is about BHI_DIS_S negotiation. A guest had to
set MITI_CTRL_BHB_CLEAR_SEQ_S_USED to indicate that it isn't aware of the
BHI_DIS_S control and is using the short sequence (ya, there is nothing
about the long sequence). When KVM sees this bit set, it deploys BHI_DIS_S
for that guest.
x86/bugs: Use Virtual MSRs to request BHI_DIS_S
https://lore.kernel.org/lkml/20240410143446.797262-5-chao.gao@intel.com/
next prev parent reply other threads:[~2026-03-07 2:41 UTC|newest]
Thread overview: 63+ messages / expand[flat|nested] mbox.gz Atom feed top
2025-11-20 6:17 [PATCH v4 00/11] VMSCAPE optimization for BHI variant Pawan Gupta
2025-11-20 6:17 ` [PATCH v4 01/11] x86/bhi: x86/vmscape: Move LFENCE out of clear_bhb_loop() Pawan Gupta
2025-11-20 16:15 ` Nikolay Borisov
2025-11-20 16:56 ` Pawan Gupta
2025-11-20 16:58 ` Nikolay Borisov
2025-11-20 6:18 ` [PATCH v4 02/11] x86/bhi: Move the BHB sequence to a macro for reuse Pawan Gupta
2025-11-20 16:28 ` Nikolay Borisov
2025-11-20 16:57 ` Pawan Gupta
2025-11-25 0:21 ` Pawan Gupta
2025-11-20 6:18 ` [PATCH v4 03/11] x86/bhi: Make the depth of BHB-clearing configurable Pawan Gupta
2025-11-20 17:02 ` Nikolay Borisov
2025-11-20 6:18 ` [PATCH v4 04/11] x86/bhi: Make clear_bhb_loop() effective on newer CPUs Pawan Gupta
2025-11-21 12:33 ` Nikolay Borisov
2025-11-21 16:40 ` Dave Hansen
2025-11-21 16:45 ` Nikolay Borisov
2025-11-21 16:50 ` Dave Hansen
2025-11-21 18:16 ` Pawan Gupta
2025-11-21 18:42 ` Dave Hansen
2025-11-21 21:26 ` Pawan Gupta
2025-11-21 21:36 ` Dave Hansen
2025-11-24 19:21 ` Pawan Gupta
2025-11-22 11:05 ` david laight
2025-11-24 19:31 ` Pawan Gupta
2025-11-25 11:34 ` david laight
2025-12-04 1:40 ` Pawan Gupta
2025-12-04 9:15 ` david laight
2025-12-04 21:56 ` Pawan Gupta
2025-12-05 9:21 ` david laight
2025-11-26 19:23 ` Pawan Gupta
2026-03-06 21:00 ` Jim Mattson
2026-03-06 22:32 ` Pawan Gupta
2026-03-06 22:57 ` Jim Mattson
2026-03-06 23:29 ` Pawan Gupta
2026-03-07 0:35 ` Jim Mattson
2026-03-07 1:00 ` Pawan Gupta
2026-03-07 1:10 ` Jim Mattson
2026-03-07 2:41 ` Pawan Gupta [this message]
2026-03-07 5:05 ` Jim Mattson
2026-03-09 22:29 ` Pawan Gupta
2026-03-09 23:05 ` Jim Mattson
2026-03-10 0:00 ` Pawan Gupta
2026-03-10 0:08 ` Jim Mattson
2026-03-10 0:52 ` Pawan Gupta
2025-11-20 6:18 ` [PATCH v4 05/11] x86/vmscape: Rename x86_ibpb_exit_to_user to x86_predictor_flush_exit_to_user Pawan Gupta
2025-11-20 6:19 ` [PATCH v4 06/11] x86/vmscape: Move mitigation selection to a switch() Pawan Gupta
2025-11-21 14:27 ` Nikolay Borisov
2025-11-24 23:09 ` Pawan Gupta
2025-11-25 10:19 ` Nikolay Borisov
2025-11-25 17:45 ` Pawan Gupta
2025-11-20 6:19 ` [PATCH v4 07/11] x86/vmscape: Use write_ibpb() instead of indirect_branch_prediction_barrier() Pawan Gupta
2025-11-21 12:59 ` Nikolay Borisov
2025-11-20 6:19 ` [PATCH v4 08/11] x86/vmscape: Use static_call() for predictor flush Pawan Gupta
2025-11-20 6:19 ` [PATCH v4 09/11] x86/vmscape: Deploy BHB clearing mitigation Pawan Gupta
2025-11-21 14:18 ` Nikolay Borisov
2025-11-21 18:29 ` Pawan Gupta
2025-11-21 14:23 ` Nikolay Borisov
2025-11-21 18:41 ` Pawan Gupta
2025-11-21 18:53 ` Nikolay Borisov
2025-11-21 21:29 ` Pawan Gupta
2025-11-20 6:20 ` [PATCH v4 10/11] x86/vmscape: Override conflicting attack-vector controls with =force Pawan Gupta
2025-11-21 18:04 ` Nikolay Borisov
2025-11-20 6:20 ` [PATCH v4 11/11] x86/vmscape: Add cmdline vmscape=on to override attack vector controls Pawan Gupta
2025-11-25 11:41 ` Nikolay Borisov
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20260307024132.wleqtpovzd6wtvm7@desk \
--to=pawan.kumar.gupta@linux.intel.com \
--cc=asit.k.mallick@intel.com \
--cc=bp@alien8.de \
--cc=chao.gao@intel.com \
--cc=dave.hansen@linux.intel.com \
--cc=david.kaplan@amd.com \
--cc=daviddunn@google.com \
--cc=hpa@zytor.com \
--cc=jmattson@google.com \
--cc=jpoimboe@kernel.org \
--cc=kvm@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=nik.borisov@suse.com \
--cc=pbonzini@redhat.com \
--cc=seanjc@google.com \
--cc=tao1.zhang@intel.com \
--cc=x86@kernel.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.