On 02/03/2026 4:12 pm, Jan Beulich wrote: > 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]>
Thanks. > >> [*] PVH Dom0 on an Intel PantherLake CPU. > What other part is this remark connected to? Ah - the commit message. Specifically, that I've only tested VT-x, not SVM PVH dom0. ~Andrew
