From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mail-wr1-f41.google.com (mail-wr1-f41.google.com [209.85.221.41]) (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 1EC7015E97 for ; Mon, 15 Dec 2025 21:05:56 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=209.85.221.41 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1765832758; cv=none; b=VSICdbDdVqVKGwzSXr7Tceje7eZiqhkAE+O6kz79dZQdDf1JoXykiiddvmZxtjCv6l3b4+YwcErPvfdZ9yGHd+nriJ5psQo6usVanKGppsviwHz3Lkd7d4YmEPg1V8+xNYZGEOB2hz0JwI7iqc1SUJBlU3DE6pQo9cPrp6OVOug= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1765832758; c=relaxed/simple; bh=3waFsTUEVw9m2bfdOuyKT5etmvKUDZo85avd9L97d0c=; h=Date:From:To:Cc:Subject:Message-ID:In-Reply-To:References: MIME-Version:Content-Type; b=TF583D+g9GiRgsVpY45q/Q1UZYr+cp8uq5ec6FffP9wGr4M4vso5FDmU9Jv7jbdNGgx7O8a1ueEmoz2GCNH1vRRoBcczSM6FnvYEHFBD/OPmra/SVhzl6WIe/efxluKS4f58w54U+6lJeuvW7uej6PEIWAA7GjbM5mstQ9UQdEw= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=gmail.com; spf=pass smtp.mailfrom=gmail.com; dkim=pass (2048-bit key) header.d=gmail.com header.i=@gmail.com header.b=MDpM+k4Y; arc=none smtp.client-ip=209.85.221.41 Authentication-Results: smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=gmail.com Authentication-Results: smtp.subspace.kernel.org; spf=pass smtp.mailfrom=gmail.com Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=gmail.com header.i=@gmail.com header.b="MDpM+k4Y" Received: by mail-wr1-f41.google.com with SMTP id ffacd0b85a97d-42b3b0d76fcso2338571f8f.3 for ; Mon, 15 Dec 2025 13:05:56 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1765832755; x=1766437555; darn=vger.kernel.org; h=content-transfer-encoding:mime-version:references:in-reply-to :message-id:subject:cc:to:from:date:from:to:cc:subject:date :message-id:reply-to; bh=k/VQiJ6U2PoviaJ84b4oZbGSbqseMWdNEopASU4Cces=; b=MDpM+k4YZbmVpilSLoPanesnzv46LDfjw7qjH+R3mFqgACfrniBabJIqO7nxzxDfuL 4OLcIJlwznYGViX6olB0Q+Vi6JXfnIW6NITJwyyQD8ZmUf1rksVe0INgpGHc0KEfHIvs BsQcPzfA8qx+OivzISkRKCuVILazYjKA6Uqw8GB41aw3osRBEsRdEiu+M92rD0nc8VLX 3QyKGtftnAIx6r3+zRApK6fxue8+9gypSCaY1k27kT0YxMGLFgpHj2proent74mwFCI2 SdtPE+fqPZFzjmhIFJZUvlRouwAE7l6Ejzu7GkU6vH4BpaQa90OmDvlpwe3Ld+5NHkQE nIMw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1765832755; x=1766437555; h=content-transfer-encoding:mime-version:references:in-reply-to :message-id:subject:cc:to:from:date:x-gm-gg:x-gm-message-state:from :to:cc:subject:date:message-id:reply-to; bh=k/VQiJ6U2PoviaJ84b4oZbGSbqseMWdNEopASU4Cces=; b=AGPVVaghR6hddRjK0IaHr4ddYKPp/z/ktKzpPm/iPFOYKPZ+2rH82pZwPX0lVbWTws ys1YY2nGdVhuOOgJs1XP2eabfYDZqQ0c+kiFB/zUNQJnfOg5U2ukTyz4VKQKAAGsDUEk XAUwIQGupIa+94oqEZzcobxsuFakcz+cIAUNpkjnsU4TVi0CU/g9voClMNWY5IR8vWo6 8xKVTQxWN0iAeXPE8mIkwZqPJKa7L7cwDJX/4jyYCUahvw0ofgCvzQwjMtsT1++vn4+W z6wDCjn2An1/AlN65YiIERprH71cqMqIKLFrO7o9TnolqcqduXKjsygIZlYE4sWNH4rW kvMA== X-Forwarded-Encrypted: i=1; AJvYcCXqjnrMuXkMoLZ+TJGkuHUusDWGqxp6IzJ4A5iXGoQTfvFOcTorc1phWf8bJys6C5AYun8bcKQkko0MQj8=@vger.kernel.org X-Gm-Message-State: AOJu0Yy6+jGuEVlzJmUvuUUVGXEyCKbBa6Rcut2hn9EDph+LA79DVlrY HHwKZfIGMqPHLf+BfRYO1ob1c/iOb0C0ofqLTK1Ye6xGVPBPhGk8USTL X-Gm-Gg: AY/fxX7cYZRYlGrDTdY4w2plhyBrIHGfgFeCPX1sInTV18F0u2YRpLzZUDs5iQchmV+ Dy0KbCWk7EdPqPzGec3Ll9lYoePxuKw+36L2o43gwor2WpYvkEzJHIcb7d8L/F/+bbo16Ei5xT1 tWvWejunGPpuG22Os+fj31Dh5z7hq5M/eg+SCodXVPVc6SDGvC99xTYaV990RwHPB0D2fF6uFBj FDq572w05mQNDxITzebEzYSygZxRPk+gDBcMk2YmZ3XFzDjjmyEdZRSpciw2fPMlYSRXxXfx6Gj 2sYxS2K+OPj/Kq7/zm60mIjFhdW856zb+rDPNN0G8dem1wxtwpXNOJIxz9fJgb1VSU1F3b0KBw2 KFmN+FB3hgDF6htLKGEyDjwLXzipL9/Dz40wYWBTN91gq3yf7e6nXxnX9FPd1EDFLnKqWsAZtIc Ytbt6jNdeTKPGKo4KZP/VPSJY/Osxj1eg9wdJN+MDT+iN8tOiCmubjKEaDkkUvLdA= X-Google-Smtp-Source: AGHT+IGbQSE2jechcjkJcIULXse77YsZC3S1gn46PwQPhkydxujDlM1wOE72uTLpNldTVJ86313oIw== X-Received: by 2002:adf:ff90:0:b0:42f:a8d6:865b with SMTP id ffacd0b85a97d-42fb44ca939mr10582387f8f.24.1765832755177; Mon, 15 Dec 2025 13:05:55 -0800 (PST) Received: from pumpkin (82-69-66-36.dsl.in-addr.zen.co.uk. [82.69.66.36]) by smtp.gmail.com with ESMTPSA id ffacd0b85a97d-42fa8a09fbesm31508262f8f.0.2025.12.15.13.05.54 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Mon, 15 Dec 2025 13:05:54 -0800 (PST) Date: Mon, 15 Dec 2025 21:05:53 +0000 From: David Laight To: Pawan Gupta Cc: Nikolay Borisov , x86@kernel.org, David Kaplan , "H. Peter Anvin" , Josh Poimboeuf , Sean Christopherson , Paolo Bonzini , Borislav Petkov , Dave Hansen , linux-kernel@vger.kernel.org, kvm@vger.kernel.org, Asit Mallick , Tao Zhang Subject: Re: [PATCH v6 2/9] x86/bhi: Make clear_bhb_loop() effective on newer CPUs Message-ID: <20251215210553.5ab5b674@pumpkin> In-Reply-To: <20251215180136.sjtvt57autnrassg@desk> References: <20251201-vmscape-bhb-v6-0-d610dd515714@linux.intel.com> <20251201-vmscape-bhb-v6-2-d610dd515714@linux.intel.com> <20251210133542.3eff9c4a@pumpkin> <20251214183827.4z6nrrol4vz2tc5w@desk> <20251214190233.4b40fe20@pumpkin> <20251215180136.sjtvt57autnrassg@desk> X-Mailer: Claws Mail 4.1.1 (GTK 3.24.38; arm-unknown-linux-gnueabihf) Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable On Mon, 15 Dec 2025 10:01:36 -0800 Pawan Gupta wrote: > On Sun, Dec 14, 2025 at 07:02:33PM +0000, David Laight wrote: > > On Sun, 14 Dec 2025 10:38:27 -0800 > > Pawan Gupta wrote: > > =20 > > > On Wed, Dec 10, 2025 at 01:35:42PM +0000, David Laight wrote: =20 > > > > On Wed, 10 Dec 2025 14:31:31 +0200 > > > > Nikolay Borisov wrote: > > > > =20 > > > > > On 2.12.25 =D0=B3. 8:19 =D1=87., Pawan Gupta wrote: =20 > > > > > > As a mitigation for BHI, clear_bhb_loop() executes branches tha= t overwrites > > > > > > the Branch History Buffer (BHB). On Alder Lake and newer parts = this > > > > > > sequence is not sufficient because it doesn't clear enough entr= ies. This > > > > > > was not an issue because these CPUs have a hardware control (BH= I_DIS_S) > > > > > > that mitigates BHI in kernel. > > > > > >=20 > > > > > > BHI variant of VMSCAPE requires isolating branch history betwee= n guests and > > > > > > userspace. Note that there is no equivalent hardware control fo= r userspace. > > > > > > To effectively isolate branch history on newer CPUs, clear_bhb_= loop() > > > > > > should execute sufficient number of branches to clear a larger = BHB. > > > > > >=20 > > > > > > Dynamically set the loop count of clear_bhb_loop() such that it= is > > > > > > effective on newer CPUs too. Use the hardware control enumerati= on > > > > > > X86_FEATURE_BHI_CTRL to select the appropriate loop count. > > > > > >=20 > > > > > > Suggested-by: Dave Hansen > > > > > > Reviewed-by: Nikolay Borisov > > > > > > Signed-off-by: Pawan Gupta = =20 > > > > >=20 > > > > > nit: My RB tag is incorrect, while I did agree with Dave's sugges= tion to=20 > > > > > have global variables for the loop counts I haven't' really seen = the=20 > > > > > code so I couldn't have given my RB on something which I haven't = seen=20 > > > > > but did agree with in principle. =20 > > > >=20 > > > > I thought the plan was to use global variables rather than ALTERNAT= IVE. > > > > The performance of this code is dominated by the loop. =20 > > >=20 > > > Using globals was much more involved, requiring changes in atleast 3 = files. > > > The current ALTERNATIVE approach is much simpler and avoids additional > > > handling to make sure that globals are set correctly for all mitigati= on > > > modes of BHI and VMSCAPE. > > >=20 > > > [ BTW, I am travelling on a vacation and will be intermittently check= ing my > > > emails. ] > > > =20 > > > > I also found this code in arch/x86/net/bpf_jit_comp.c: > > > > if (cpu_feature_enabled(X86_FEATURE_CLEAR_BHB_LOOP)) { > > > > /* The clearing sequence clobbers eax and ecx. */ > > > > EMIT1(0x50); /* push rax */ > > > > EMIT1(0x51); /* push rcx */ > > > > ip +=3D 2; > > > >=20 > > > > func =3D (u8 *)clear_bhb_loop; > > > > ip +=3D x86_call_depth_emit_accounting(&prog, func, ip); > > > >=20 > > > > if (emit_call(&prog, func, ip)) > > > > return -EINVAL; > > > > EMIT1(0x59); /* pop rcx */ > > > > EMIT1(0x58); /* pop rax */ > > > > } > > > > which appears to assume that only rax and rcx are changed. > > > > Since all the counts are small, there is nothing stopping the code > > > > using the 8-bit registers %al, %ah, %cl and %ch. =20 > > >=20 > > > Thanks for catching this. =20 > >=20 > > I was trying to find where it was called from. > > Failed to find the one on system call entry... =20 >=20 > The macro CLEAR_BRANCH_HISTORY calls clear_bhb_loop() at system call entr= y. I didn't look very hard :-) >=20 > > > > There are probably some schemes that only need one register. > > > > eg two separate ALTERNATIVE blocks. =20 > > >=20 > > > Also, I think it is better to use a callee-saved register like rbx to= avoid > > > callers having to save/restore registers. Something like below: =20 > >=20 > > I'm not sure. > > %ax is the return value so can be 'trashed' by a normal function call. > > But if the bpf code is saving %ax then it isn't expecting a normal call= . =20 >=20 > BHB clear sequence is executed at the end of the BPF JITted code, and %rax > is likely the return value of the BPF program. So, saving/restoring %rax > around the sequence makes sense to me. >=20 > > OTOH if you are going to save the register in clear_bhb_loop you might > > as well use %ax to get the slightly shorter instructions for %al. > > (I think 'movb' comes out shorter - as if it really matters.) =20 >=20 > %rbx is a callee-saved register so it felt more intuitive to save/restore > it in clear_bhb_loop(). But, I can use %ax if you feel strongly. If you are going to save a register it might as well be %ax. Otherwise someone will wonder why you picked a different one. >=20 > > Definitely worth a comment that it must save all resisters. =20 >=20 > Yes, will add a comment. >=20 > > I also wonder if it needs to setup a stack frame? =20 >=20 > I don't know if thats necessary, objtool doesn't complain because > clear_bhb_loop() is marked STACK_FRAME_NON_STANDARD. In some senses it is a leaf functions - and the compiler doesn't create stack frames for those (by default). Provided objtool isn't confused by all the call instructions it probably doesn't matter. David >=20 > > Again, the code is so slow it won't matter. > >=20 > > David =20