Re: [PATCH v2 1/2] x86/cpu: Disable CR pinning during CPU bringup

[Dave Hansen <dave.hansen@intel.com>]

On 3/16/26 13:27, Chang S. Bae wrote:
> On 3/12/2026 7:20 AM, Dave Hansen wrote:
>> On 3/12/26 07:08, Nikunj A. Dadhania wrote:
>>> 1) Back-porting complexity: The current issue affects kernels (6.9+)
>>>     where SEV-SNP guests fail to boot with FRED enabled. A simpler
>>> fix would
>>>     be easier to backport and verify across stable branches.
>>
>> The simplest fix is to disable FRED on those kernels, fwiw.
> 
> In addition to this,
> 
> On SEV systems, early exceptions appear to be expected in practice while
> CR4.FSGSBASE=0. So, at the moment, it also looks safe and simple to
> disable the feature until when those entry paths are adjusted to
> tolerate that case.

Sure. FSGSBASE at entry is _purely_ a performance optimization. It seems
reasonable to say for simplicity that the early exception code should
not use FSGSBASE instructions.

> Currently, those entry paths are patched to use FSGSBASE instructions
> regardless of the CR4 setting. That inflexibility appears to make it
> broken in the first place. I’d take a look and come back with something
> reviewable.

Yup. But, just to be clear, the patching is done by the boot CPU before
the secondaries even come up. So the "late" exception handlers are
incompatible with the secondary CPU from the moment it comes up until
the moment it enables CR4.FSGSBASE.

Either we change how alternatives patching works, we use some other
exception code, or we try and get CR4.FSGSBASE established as early as
possible on the secondaries.