On 01.09.2025 15:27, Andrew Cooper wrote:
> On 01/09/2025 1:57 pm, Jan Beulich wrote:
>> On 28.08.2025 17:04, Andrew Cooper wrote:
>>> --- a/xen/arch/x86/traps.c
>>> +++ b/xen/arch/x86/traps.c
>>> @@ -2265,9 +2265,83 @@ void asmlinkage check_ist_exit(const struct
>>> cpu_user_regs *regs, bool ist_exit)
>>>
>>> void asmlinkage entry_from_pv(struct cpu_user_regs *regs)
>>> {
>>> + struct fred_info *fi = cpu_regs_fred_info(regs);
>>> + uint8_t type = regs->fred_ss.type;
>>> + uint8_t vec = regs->fred_ss.vector;
>>> +
>>> /* Copy fred_ss.vector into entry_vector as IDT delivery would have
>>> done. */
>>> - regs->entry_vector = regs->fred_ss.vector;
>>> + regs->entry_vector = vec;
>>> +
>>> + if ( !IS_ENABLED(CONFIG_PV) )
>>> + goto fatal;
>>> +
>>> + /*
>>> + * First, handle the asynchronous or fatal events. These are either
>>> + * unrelated to the interrupted context, or may not have valid context
>>> + * recorded, and all have special rules on how/whether to re-enable
>>> IRQs.
>>> + */
>>> + switch ( type )
>>> + {
>>> + case X86_ET_EXT_INTR:
>>> + return do_IRQ(regs);
>>>
>>> + case X86_ET_NMI:
>>> + return do_nmi(regs);
>>> +
>>> + case X86_ET_HW_EXC:
>>> + switch ( vec )
>>> + {
>>> + case X86_EXC_DF: return do_double_fault(regs);
>>> + case X86_EXC_MC: return do_machine_check(regs);
>> Looking at patch 21, I came to wonder where it is that we're moving back to
>> SL0 in the #MC case (which may not be fatal), for ERETU to not fault.
>
> (Almost) any event taken in Ring3 enters Ring0 at SL0, even those with
> custom STK_LVLS configuration.
>
> See 5.1.2 Determining the New Values for Stack Level, RSP, and SSP
Oh, right - that's something I still need to properly settle in a corner of
my brain.
Jan
