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

[Andrew Cooper <andrew.cooper3@xxxxxxxxxx>]

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 <andrew.cooper3@xxxxxxxxxx>
> Reviewed-by: Jan Beulich <jbeulich@xxxxxxxx>

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