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 <[email protected]>
Reviewed-by: Jan Beulich <[email protected]> > [*] 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
