From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mail-ed1-f43.google.com (mail-ed1-f43.google.com [209.85.208.43]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id DB3D538F93E for ; Fri, 3 Apr 2026 23:22:45 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=pass smtp.client-ip=209.85.208.43 ARC-Seal:i=2; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1775258567; cv=pass; b=SlZyguhgbQ9zw5dNzPjNX2bXqthntwoE0Bu9AdqGKQDUhRKpCLBpsuqCjbec3xCQ1O3WaQlLM7P/w4xnPwW8tghYZvPFeo9oUeWU8EKhcMRokw/tT54GDdKw/5hL3asueJvsbI92B5oh9q5xIA7Kh1UwcdEJSZVErbnCgiId3xQ= ARC-Message-Signature:i=2; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1775258567; c=relaxed/simple; bh=5ha26Itsrk1we0z4g/15zsHRq/Q6+Nd3OhVvBZghBLY=; h=MIME-Version:References:In-Reply-To:From:Date:Message-ID:Subject: To:Cc:Content-Type; b=oTN/Cqg8iUmfeNWdDMCcQO/cb+Q3x3fL5GWZlmtd7PiVDgglVuIrZgrnYHYH9uwfwNzn5q5t6NaMaHuoZ6dqPHCIJzMNm4B5evaIfhyLLoWDP7jctA8s+166iWfTkFOFPj/s1TjSGhz+X7QAheaK7lLXPCE8pFB5yPLrBP/qAb4= ARC-Authentication-Results:i=2; smtp.subspace.kernel.org; dmarc=pass (p=reject dis=none) header.from=google.com; spf=pass smtp.mailfrom=google.com; dkim=pass (2048-bit key) header.d=google.com header.i=@google.com header.b=dwVdFK9u; arc=pass smtp.client-ip=209.85.208.43 Authentication-Results: smtp.subspace.kernel.org; dmarc=pass (p=reject dis=none) header.from=google.com Authentication-Results: smtp.subspace.kernel.org; spf=pass smtp.mailfrom=google.com Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=google.com header.i=@google.com header.b="dwVdFK9u" Received: by mail-ed1-f43.google.com with SMTP id 4fb4d7f45d1cf-66ba6d3dab3so15348a12.0 for ; Fri, 03 Apr 2026 16:22:45 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1775258564; cv=none; d=google.com; s=arc-20240605; b=eJmquaoQz0rm/W3EtBtnLrHa0DzdwNjMV15zfmi2RWHZY7cHA/kR3hR4WzZ11HL4gk f43StdymXUkZtbfX4PYKrbRcTpF0wsoOilOKYEKVFePwEjfTD5wierd0gWIRpawCocVD +qGr52HxnL9GKI+xBNcaz+iVQK8LOxnQT03540gl3jcLapN0eA20JmD8ocsXZZbm+a1K 3Wvptib5q8JzyXG9qagmd6DctktNFqbubnbN2Kue0yB9vLX7R4KLRXMQSXa6/rJwg46V 8FIi8WQhyfqLYizyI64c/r6lymMoYHHx8UEClRm4Fx/qVpB7owNfUSTo+ENrsLsmvqkA pwxw== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20240605; h=content-transfer-encoding:cc:to:subject:message-id:date:from :in-reply-to:references:mime-version:dkim-signature; bh=u3rtAvIvVBacn8fCtsxK6Q16SI3iclsRvlQKxK9ic18=; fh=YqRs4TezLvqpjPeWXz2s5YocHN7292TRolky6QECuT0=; b=eYYHdjrRe6VZDekcGMPjOV7twyZgNozrjdzLBQJm9HhKKG4rE4PxMkTyqXQa8OMGFx bcmBkvcgsuoh33m+EoeQ+OUZUzdhFXWrJYWkcJaAIlvqlVPMBX8Nry3VXyu4ZBYv9PyZ bqMl2Y7BHHQdv/6b7n+hExQia6VRdqPAYIY16BneyJdNKbTEualFajgQTb0pEHRq3P/D jKHJutWMeBI16Y835bhHFVqqRmJjKTuo/1sgopyKFyemhUinQatb0YQH2THiMK/EwRVk NeDrZWmZD6hVbSKR8pvaugp0JouFctcdqRfm7CyXqLt+llmIlb1A418H2ies+RmMqdAD xJJA==; darn=vger.kernel.org ARC-Authentication-Results: i=1; mx.google.com; arc=none DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20251104; t=1775258564; x=1775863364; darn=vger.kernel.org; h=content-transfer-encoding:cc:to:subject:message-id:date:from :in-reply-to:references:mime-version:from:to:cc:subject:date :message-id:reply-to; bh=u3rtAvIvVBacn8fCtsxK6Q16SI3iclsRvlQKxK9ic18=; b=dwVdFK9uGQM05UwOIVXgiEmwS7Gpwagus3F7nNsIWzjbkm3v1km3f3Ji8MHY3VHAPm TeiJQFiH7XxLbFgdd4oH1LG30PLyWSF5nZ1kKWsSO+oB+UPMoPknGoHhIns+Nh8+kszu /uTywAfN8r8SlmC6HGP2OBx/EGl93PR8QWMT4Fo4QHZighyFqHmK79nOVdlcdW69hioX IQ1KG+la9br0DKAqMErIYtshg3pa6pphA+YrVQYHHDHt9GrDO+URY3PuJdzRdFmJmLm8 p04YDFusCpq+D2KBG1O8+4Bcmu7M7M1hXjb1ttwUem+gqDQyUrg+5Xu4V66ls8aVQOa/ ougA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20251104; t=1775258564; x=1775863364; h=content-transfer-encoding:cc:to:subject:message-id:date:from :in-reply-to:references:mime-version:x-gm-gg:x-gm-message-state:from :to:cc:subject:date:message-id:reply-to; bh=u3rtAvIvVBacn8fCtsxK6Q16SI3iclsRvlQKxK9ic18=; b=XptzzD9FjGliEFatE+InPuk70VxCCKpndKwv00rkwCOJ+PfZTR/dE84y1152sp1q3A elkjfYVi8dHry92pELf7xKBkGJsrcNF9yp2rGQ9cHXOVimnz6OUTzmDr8OrL/0dpgMBS MUl1j8mIGps/2op3vM9G+MfXVJRmfiFvsPtTfTw3wrxVXucfp0Y9W4FNqTZSw7tUVD1u vr/emRiSJCJIKdx+rTSrNZrgiaEmqmQH9hNwP70wEMvU8dzFDXfpZ1oGWUePXxFrP6NM msB7NM/hHyTVG33kezJ2MDRJ0PLRbnaFupEC0uIuH0rdddw7okeAQ7/be1V3xXMwgoWg 8LGQ== X-Forwarded-Encrypted: i=1; AJvYcCUd+TdqxHVm7NvyOZzWW5pgiDP9iLBi25ZVK+hCf1Q7Fdb22sPj67/ouJmybsM07dY/SUJTd6YeIqF2daU=@vger.kernel.org X-Gm-Message-State: AOJu0YwAUy5mSUp8Ic68pDLw0PKJ7c7wLCqs0TwNCWeRNrJakVghg1yC v6Zd7Xd4Pexhp3H2EZMd9kxHXbpEfStU9S5jjW2DgJE3nqZ5/O8LwYjtS1t5pok4dFDMEZ/scs2 ZdS/irytSHpSP9ZODg+wtxMQ0R5T6Q9x4Dw6WpAGI X-Gm-Gg: AeBDiet5uRr/4mNl8GndltKrXyFrBJFdqxmLxPmPCuvDZTGQn+COw0SoAtMPgBI8prA AZGQifOtbrVozZx3nMU7xV4BP6iDuhJXrdYCJz9b4auZ8aCeVFA0EhWf919NgYP1JYwbjD8Qn4m ArAY1SXxagPCmiwr2N1bqN6sOMhuICN04VZYoR29gIY8Vv8qNYybN6UVm4SvqjPOd61yPPCYxAj Hx1HK49XXd1jPwMmsJSRcAcjrWDAoEPjKDHRm7fuwcvf0+l2soDjZQBYfPvZ04UAAC61Vp3tsmS EyEYHV8= X-Received: by 2002:aa7:cfc8:0:b0:66c:309b:243b with SMTP id 4fb4d7f45d1cf-66e43ce15ddmr28797a12.1.1775258563658; Fri, 03 Apr 2026 16:22:43 -0700 (PDT) Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 References: <20260402-vmscape-bhb-v9-0-94d16bc29774@linux.intel.com> <20260402-vmscape-bhb-v9-2-94d16bc29774@linux.intel.com> <20260403185236.sjgetnkha3o3a4d3@desk> <20260403213445.xzb4rxbfbg5un7li@desk> <20260403231608.zopnhnypdclzqlx7@desk> In-Reply-To: <20260403231608.zopnhnypdclzqlx7@desk> From: Jim Mattson Date: Fri, 3 Apr 2026 16:22:28 -0700 X-Gm-Features: AQROBzDbM3KZyF-NHHTCgXNIMcFvHYIysNjC-tVAW-RoWsiBLJTzU6zFbRUlRWk Message-ID: Subject: Re: [PATCH v9 02/10] x86/bhi: Make clear_bhb_loop() effective on newer CPUs To: Pawan Gupta Cc: x86@kernel.org, Jon Kohler , Nikolay Borisov , "H. Peter Anvin" , Josh Poimboeuf , David Kaplan , Sean Christopherson , Borislav Petkov , Dave Hansen , Peter Zijlstra , Alexei Starovoitov , Daniel Borkmann , Andrii Nakryiko , KP Singh , Jiri Olsa , "David S. Miller" , David Laight , Andy Lutomirski , Thomas Gleixner , Ingo Molnar , David Ahern , Martin KaFai Lau , Eduard Zingerman , Song Liu , Yonghong Song , John Fastabend , Stanislav Fomichev , Hao Luo , Paolo Bonzini , Jonathan Corbet , linux-kernel@vger.kernel.org, kvm@vger.kernel.org, Asit Mallick , Tao Zhang , bpf@vger.kernel.org, netdev@vger.kernel.org, linux-doc@vger.kernel.org, chao.gao@intel.com Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable On Fri, Apr 3, 2026 at 4:16=E2=80=AFPM Pawan Gupta wrote: > > On Fri, Apr 03, 2026 at 02:59:33PM -0700, Jim Mattson wrote: > > On Fri, Apr 3, 2026 at 2:34=E2=80=AFPM Pawan Gupta > > wrote: > > > > > > On Fri, Apr 03, 2026 at 01:19:17PM -0700, Jim Mattson wrote: > > > > On Fri, Apr 3, 2026 at 11:52=E2=80=AFAM Pawan Gupta > > > > wrote: > > > > > > > > > > On Fri, Apr 03, 2026 at 11:10:08AM -0700, Jim Mattson wrote: > > > > > > On Thu, Apr 2, 2026 at 5:32=E2=80=AFPM Pawan Gupta > > > > > > wrote: > > > > > > > > > > > > > > As a mitigation for BHI, clear_bhb_loop() executes branches t= hat overwrite > > > > > > > the Branch History Buffer (BHB). On Alder Lake and newer part= s this > > > > > > > sequence is not sufficient because it doesn't clear enough en= tries. This > > > > > > > was not an issue because these CPUs use the BHI_DIS_S hardwar= e mitigation > > > > > > > in the kernel. > > > > > > > > > > > > > > Now with VMSCAPE (BHI variant) it is also required to isolate= branch > > > > > > > history between guests and userspace. Since BHI_DIS_S only pr= otects the > > > > > > > kernel, the newer CPUs also use IBPB. > > > > > > > > > > > > > > A cheaper alternative to the current IBPB mitigation is clear= _bhb_loop(). > > > > > > > But it currently does not clear enough BHB entries to be effe= ctive on newer > > > > > > > CPUs with larger BHB. At boot, dynamically set the loop count= of > > > > > > > clear_bhb_loop() such that it is effective on newer CPUs too.= Use the > > > > > > > X86_FEATURE_BHI_CTRL feature flag to select the appropriate l= oop count. > > > > > > > > > > > > > > Suggested-by: Dave Hansen > > > > > > > Signed-off-by: Pawan Gupta > > > > > > > --- > > > > > > > arch/x86/entry/entry_64.S | 8 +++++--- > > > > > > > arch/x86/include/asm/nospec-branch.h | 2 ++ > > > > > > > arch/x86/kernel/cpu/bugs.c | 13 +++++++++++++ > > > > > > > 3 files changed, 20 insertions(+), 3 deletions(-) > > > > > > > > > > > > > > diff --git a/arch/x86/entry/entry_64.S b/arch/x86/entry/entry= _64.S > > > > > > > index 3a180a36ca0e..bbd4b1c7ec04 100644 > > > > > > > --- a/arch/x86/entry/entry_64.S > > > > > > > +++ b/arch/x86/entry/entry_64.S > > > > > > > @@ -1536,7 +1536,9 @@ SYM_FUNC_START(clear_bhb_loop) > > > > > > > ANNOTATE_NOENDBR > > > > > > > push %rbp > > > > > > > mov %rsp, %rbp > > > > > > > - movl $5, %ecx > > > > > > > + > > > > > > > + movzbl bhb_seq_outer_loop(%rip), %ecx > > > > > > > + > > > > > > > ANNOTATE_INTRA_FUNCTION_CALL > > > > > > > call 1f > > > > > > > jmp 5f > > > > > > > @@ -1556,8 +1558,8 @@ SYM_FUNC_START(clear_bhb_loop) > > > > > > > * This should be ideally be: .skip 32 - (.Lret2 - 2f= ), 0xcc > > > > > > > * but some Clang versions (e.g. 18) don't like this. > > > > > > > */ > > > > > > > - .skip 32 - 18, 0xcc > > > > > > > -2: movl $5, %eax > > > > > > > + .skip 32 - 20, 0xcc > > > > > > > +2: movzbl bhb_seq_inner_loop(%rip), %eax > > > > > > > 3: jmp 4f > > > > > > > nop > > > > > > > 4: sub $1, %eax > > > > > > > diff --git a/arch/x86/include/asm/nospec-branch.h b/arch/x86/= include/asm/nospec-branch.h > > > > > > > index 70b377fcbc1c..87b83ae7c97f 100644 > > > > > > > --- a/arch/x86/include/asm/nospec-branch.h > > > > > > > +++ b/arch/x86/include/asm/nospec-branch.h > > > > > > > @@ -548,6 +548,8 @@ DECLARE_PER_CPU(u64, x86_spec_ctrl_curren= t); > > > > > > > extern void update_spec_ctrl_cond(u64 val); > > > > > > > extern u64 spec_ctrl_current(void); > > > > > > > > > > > > > > +extern u8 bhb_seq_inner_loop, bhb_seq_outer_loop; > > > > > > > + > > > > > > > /* > > > > > > > * With retpoline, we must use IBRS to restrict branch predi= ction > > > > > > > * before calling into firmware. > > > > > > > diff --git a/arch/x86/kernel/cpu/bugs.c b/arch/x86/kernel/cpu= /bugs.c > > > > > > > index 83f51cab0b1e..2cb4a96247d8 100644 > > > > > > > --- a/arch/x86/kernel/cpu/bugs.c > > > > > > > +++ b/arch/x86/kernel/cpu/bugs.c > > > > > > > @@ -2047,6 +2047,10 @@ enum bhi_mitigations { > > > > > > > static enum bhi_mitigations bhi_mitigation __ro_after_init = =3D > > > > > > > IS_ENABLED(CONFIG_MITIGATION_SPECTRE_BHI) ? BHI_MITIG= ATION_AUTO : BHI_MITIGATION_OFF; > > > > > > > > > > > > > > +/* Default to short BHB sequence values */ > > > > > > > +u8 bhb_seq_outer_loop __ro_after_init =3D 5; > > > > > > > +u8 bhb_seq_inner_loop __ro_after_init =3D 5; > > > > > > > + > > > > > > > static int __init spectre_bhi_parse_cmdline(char *str) > > > > > > > { > > > > > > > if (!str) > > > > > > > @@ -3242,6 +3246,15 @@ void __init cpu_select_mitigations(voi= d) > > > > > > > x86_spec_ctrl_base &=3D ~SPEC_CTRL_MITIGATION= S_MASK; > > > > > > > } > > > > > > > > > > > > > > + /* > > > > > > > + * Switch to long BHB clear sequence on newer CPUs (w= ith BHI_CTRL > > > > > > > + * support), see Intel's BHI guidance. > > > > > > > + */ > > > > > > > + if (cpu_feature_enabled(X86_FEATURE_BHI_CTRL)) { > > > > > > > + bhb_seq_outer_loop =3D 12; > > > > > > > + bhb_seq_inner_loop =3D 7; > > > > > > > + } > > > > > > > + > > > > > > > > > > > > How does this work for VMs in a heterogeneous migration pool th= at > > > > > > spans the Alder Lake boundary? They can't advertise BHI_CTRL, b= ecause > > > > > > it isn't available on all hosts in the migration pool, but they= need > > > > > > the long sequence when running on Alder Lake or newer. > > > > > > > > > > As we discussed elsewhere, support for migration pool is much mor= e > > > > > involved. It should be dealt in a separate QEMU/KVM focused serie= s. > > > > > > > > > > A quickfix could be adding support for spectre_bhi=3Dlong that gu= ests in a > > > > > migration pool can use? > > > > > > > > The simplest solution is to add "| > > > > cpu_feature_enabled(X86_FEATURE_HYPERVISOR)" to the condition above= . > > > > If that is unacceptable for the performance of pre-Alder Lake > > > > > > Yes, that would be unnecessary overhead. > > > > > > > migration pools, you could define a CPUID or MSR bit that says > > > > explicitly, "long BHB flush sequence needed," rather than trying to > > > > intuit that property from the presence of BHI_CTRL. Like > > > > IA32_ARCH_CAPABILITIES.SKIP_L1DFL_VMENTRY, the bit would only be se= t > > > > by a hypervisor. > > > > > > I will think about this more. > > > > > > > I am still skeptical of the need for MSR_VIRTUAL_ENUMERATION and > > > > friends, unless there is a major guest OS out there that relies on > > > > them. > > > > > > If we forget about MSR_VIRTUAL_ENUMERATION for a moment, userspace VM= M is > > > in the best position to decide whether a guest needs > > > virtual.SPEC_CTRL[BHI_DIS_S]. Via a KVM interface userspace VMM can g= et > > > BHI_DIS_S for the guests that are in migration pool? > > > > That is not possible today, since KVM does not implement Intel's > > IA32_SPEC_CTRL virtualization, and cedes the hardware IA32_SPEC_CTRL > > to the guest after the first non-zero write to the guest's MSR. > > Yes, KVM doesn't support it yet. But, adding that support to give more > control to userspace VMM helps this case, and probably many other in > the future. But didn't you tell me that Windows doesn't want the hypervisor to set BHI_DIS_S behind their back? > I will check with Chao if he can prepare the next version of virtual > SPEC_CTRL series (leaving out virtual mitigation MSRs). Excellent.