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

["Nikunj A. Dadhania" <nikunj@amd.com>]

On 3/11/2026 10:58 PM, Dave Hansen wrote:
> On 3/11/26 08:42, Nikunj A. Dadhania wrote:

> BTW, commit c7ad5ad297e tells some of the tales of woe around CR4 and
> boot vs. secondary CPUs:
> 
> 	cpu_init() is weird: it's called rather late (after early
> 	identification and after most MMU state is initialized) on the
> 	boot CPU but is called extremely early (before identification)
> 	on secondary CPUs.
> 
> This weirdness is still biting us today. CR4 pinning just made things
> worse (or at least harder to understand).
> 
> I have the feeling we need to bite the bullet here and actually start
> thinking about this holistically. I _think_ 'mmu_cr4_features' is
> conceptually pretty close to what we need. It's just named wrong.
> 
> /*
>  * Current system-wide configuration information for CR4 register.
>  * All of the bits in these feature masks are supported by the current
>  * running CPU.
>  */
> struct cr4_config {
...
> 
> What do folks think? Can we expand the 'mmu_cr4_features' to more than
> MMU features?

I'll let you and the other x86 maintainers decide on the cr4_config 
approach. However, I have two concerns for the immediate fix:

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.

2) Scope and risk: The cr4_config refactoring touches core x86 boot paths 
   and would need careful analysis of all CR4 feature interactions 
   (PCID, FSGSBASE, SMEP, SMAP, etc.) across different boot scenarios 
   (boot CPU, secondary CPUs, real-mode transitions, kexec, etc.). 

Would it make sense to take a two-phase approach:

Phase 1 (suitable for stable as well):
  1) Universally set X86_CR4_FSGSBASE in cr4_init() and call cr4_init()
     from trap_init() on the boot CPU
  2) Disable CR pinning during secondary CPU bringup
  3) Add #VC handler for FRED and use boot_ghcb during early boot

Phase 2:
  - Build consensus among x86 maintainers on the cr4_config approach
  - Implement the refactoring once the design is agreed upon

I'm happy to work on Phase 2 with guidance from the maintainers, but would 
prefer to decouple it from the urgent boot failure fix.

Thanks,
Nikunj