Re: [PATCH v4 08/14] x86/traps: Enable FRED when requested

[Jan Beulich <jbeulich@xxxxxxxx>]

On 28.02.2026 00:16, Andrew Cooper wrote:
> With the shadow stack and exception handling adjustements in place, we can now
> activate FRED when appropriate.  Note that opt_fred is still disabled by
> default until more infrastructure is in place.
> 
> Introduce init_fred() to set up all the MSRs relevant for FRED.  FRED uses
> MSR_STAR (entries from Ring3 only), and MSR_FRED_SSP_SL0 aliases MSR_PL0_SSP
> when CET-SS is active.  Otherwise, they're all new MSRs.
> 
> Also introduce init_fred_tss().  At this juncture we need a TSS set up, even
> if it is mostly unused.  Reinsert the BUILD_BUG_ON() checking the size of the
> TSS against 0x67, this time with a more precise comment.
> 
> With init_fred() existing, load_system_tables() and legacy_syscall_init()
> should only be used when setting up IDT delivery.  Insert ASSERT()s to this
> effect, and adjust the various init functions to make this property true.
> 
> The FRED initialisation path still needs to write to all system table
> registers at least once, even if only to invalidate them.  Per the
> documentation, percpu_early_traps_init() is responsible for switching off the
> boot GDT, which also needs doing even in FRED mode.
> 
> Finally, set CR4.FRED in traps_init()/percpu_early_traps_init().
> 
> Xen can now boot in FRED mode and run a PVH dom0.  PV guests still need more
> work before they can be run under FRED.
> 
> Signed-off-by: Andrew Cooper <andrew.cooper3@xxxxxxxxxx>

Reviewed-by: Jan Beulich <jbeulich@xxxxxxxx>

> [*] PVH Dom0 on an Intel PantherLake CPU.

What other part is this remark connected to?

> @@ -353,7 +440,11 @@ void __init traps_init(void)
>   */
>  void __init bsp_traps_reinit(void)
>  {
> -    load_system_tables();
> +    if ( opt_fred )
> +        init_fred();
> +    else
> +        load_system_tables();
> +
>      percpu_traps_init();
>  }

I see now what you meant in reply to comments on an earlier patch.

Jan