Re: [PATCH v5 2/8] x86/bugs: Allow spectre_v2=ibrs on x86 vendors other than Intel

[Borislav Petkov]

On Wed, Sep 30, 2026 at 02:50:23PM -0500, Kim Phillips wrote:
> How is optimizing the VM exit-to-re-entry path not "*actually* useful to
> users"?

Let me try one last time: 

Back then we did this:

commit acaa4b5c4c854b5009f4d4a5395b2609ad0f4937
Author: Kim Phillips <kim.phillips@xxxxxxx>
Date:   Thu Jan 25 22:11:02 2024 -0600

    x86/speculation: Do not enable Automatic IBRS if SEV-SNP is enabled
    
    Without SEV-SNP, Automatic IBRS protects only the kernel. But when
    SEV-SNP is enabled, the Automatic IBRS protection umbrella widens to all
    host-side code, including userspace. This protection comes at a cost:
    reduced userspace indirect branch performance.
    
    To avoid this performance loss, don't use Automatic IBRS on SEV-SNP
    hosts and all back to retpolines instead.

Now, in order to be able to prevent indirect branches from influencing other
indirect branches in another mode (HV in this case), one needs to be able to
switch to plain IBRS, which brings us back to the toggling of the IBRS MSR
bit.

I.e.:

"After setting IBRS to 1, if software subsequently

* clears IBRS to 0: The processor may allow older indirect branches that
 a occurred when IBRS was previously 0 to influence future indirect branch
 predictions.

* writes another 1 to IBRS: The processor starts a new window where older
 indirect branches do not influence future indirect branch predictions."

So in order to allow that, you need all that code complication from your
patch.

And, for the Nth time, I would understand if there's any real justification
for adding all that additional complexity to bugs.c which already is
a nightmare to maintain.

But so far I haven't seen a real justification for it. As in: spectre_v2=ibrs
on AMD is good for cases A, B or C and this is going to be used in this and
that scenario so having that capability upstream is worth the added
maintentance effort. Not it "might be useful" to users. "might"'s not good
enough for this.

And there's at least a *suspected* perf impact here which has not been
measured yet. And no, not with some script but with real workloads.

And it is perfectly fine if those workloads prove that some of them benefit
from this setting.

But because there is a potential perf impact - impact which we have not
quantified yet - then this is not ready. We need to know what that performance
impact is and that needs to be documented so that people can make an informed
decision here.

And so that they don't come to us and complain that this setting is causing
performance issues and everyone needs to stop the presses and the world is
ending.

These are basically the same two things I asked you for, this time I tried to
explain them in more detail.

-- 
Regards/Gruss,
    Boris.

https://people.kernel.org/tglx/notes-about-netiquette