[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <a90b81cb-b6b5-4071-b5d6-713ce8eff0cf@suse.com>
Date: Wed, 10 Dec 2025 17:42:05 +0200
From: Nikolay Borisov <nik.borisov@...e.com>
To: David Laight <david.laight.linux@...il.com>
Cc: Pawan Gupta <pawan.kumar.gupta@...ux.intel.com>, x86@...nel.org,
David Kaplan <david.kaplan@....com>, "H. Peter Anvin" <hpa@...or.com>,
Josh Poimboeuf <jpoimboe@...nel.org>, Sean Christopherson
<seanjc@...gle.com>, Paolo Bonzini <pbonzini@...hat.com>,
Borislav Petkov <bp@...en8.de>, Dave Hansen <dave.hansen@...ux.intel.com>,
linux-kernel@...r.kernel.org, kvm@...r.kernel.org,
Asit Mallick <asit.k.mallick@...el.com>, Tao Zhang <tao1.zhang@...el.com>
Subject: Re: [PATCH v6 2/9] x86/bhi: Make clear_bhb_loop() effective on newer
CPUs
On 10.12.25 г. 15:35 ч., David Laight wrote:
> On Wed, 10 Dec 2025 14:31:31 +0200
> Nikolay Borisov <nik.borisov@...e.com> wrote:
>
>> On 2.12.25 г. 8:19 ч., Pawan Gupta wrote:
>>> As a mitigation for BHI, clear_bhb_loop() executes branches that overwrites
>>> the Branch History Buffer (BHB). On Alder Lake and newer parts this
>>> sequence is not sufficient because it doesn't clear enough entries. This
>>> was not an issue because these CPUs have a hardware control (BHI_DIS_S)
>>> that mitigates BHI in kernel.
>>>
>>> BHI variant of VMSCAPE requires isolating branch history between guests and
>>> userspace. Note that there is no equivalent hardware control for userspace.
>>> To effectively isolate branch history on newer CPUs, clear_bhb_loop()
>>> should execute sufficient number of branches to clear a larger BHB.
>>>
>>> Dynamically set the loop count of clear_bhb_loop() such that it is
>>> effective on newer CPUs too. Use the hardware control enumeration
>>> X86_FEATURE_BHI_CTRL to select the appropriate loop count.
>>>
>>> Suggested-by: Dave Hansen <dave.hansen@...ux.intel.com>
>>> Reviewed-by: Nikolay Borisov <nik.borisov@...e.com>
>>> Signed-off-by: Pawan Gupta <pawan.kumar.gupta@...ux.intel.com>
>>
>> nit: My RB tag is incorrect, while I did agree with Dave's suggestion to
>> have global variables for the loop counts I haven't' really seen the
>> code so I couldn't have given my RB on something which I haven't seen
>> but did agree with in principle.
>
> I thought the plan was to use global variables rather than ALTERNATIVE.
> The performance of this code is dominated by the loop.
Generally yes and I was on the verge of calling this out, however what
stopped me is the fact that the global variables are going to be set
"somewhere else" whilst with the current approach everything is
contained within the clear_bhb_loop function. Both ways have their merit
but I don't want to endlessly bikeshed.
<snip>
Powered by blists - more mailing lists