Re: [PATCH 21/22] x86/traps: Introduce FRED entrypoints

[Andrew Cooper <andrew.cooper3@xxxxxxxxxx>]

On 18/08/2025 11:03 am, Jan Beulich wrote:
> On 08.08.2025 22:23, Andrew Cooper wrote:
>> diff --git a/xen/arch/x86/traps.c b/xen/arch/x86/traps.c
>> index 270b93ed623e..e67a428e4362 100644
>> --- a/xen/arch/x86/traps.c
>> +++ b/xen/arch/x86/traps.c
>> @@ -2181,6 +2240,94 @@ void asmlinkage check_ist_exit(const struct 
>> cpu_user_regs *regs, bool ist_exit)
>>  }
>>  #endif
>>  
>> +void asmlinkage entry_from_pv(struct cpu_user_regs *regs)
>> +{
>> +    /* Copy fred_ss.vector into entry_vector as IDT delivery would have 
>> done. */
>> +    regs->entry_vector = regs->fred_ss.vector;
>> +
>> +    switch ( regs->fred_ss.type )
>> +    {
>> +    case X86_ET_EXT_INTR:
>> +        do_IRQ(regs);
>> +        break;
>> +
>> +    case X86_ET_NMI:
>> +        do_nmi(regs);
>> +        break;
>> +
>> +    case X86_ET_HW_EXC:
>> +    case X86_ET_SW_INT:
>> +    case X86_ET_PRIV_SW_EXC:
>> +    case X86_ET_SW_EXC:
>> +        goto fatal;
>> +
>> +    default:
>> +        goto fatal;
>> +    }
>> +
>> +    return;
>> +
>> + fatal:
>> +    fatal_trap(regs, false);
>> +}
> Noticed only now: Shouldn't this be surrounded with #ifdef CONFIG_PV (with
> knock-on effects elsewhere)?

Randconfig had a fun time with CONFIG_PV.

I've got an early "if ( IS_ENABLED(CONFIG_PV) ) goto fatal;" but there's
a bit of extra complexity in the ASM.  entry_FRED_R3() needs to exist
even outside of CONFIG_PV, despite things like test_all_events being
conditional.

Also, this is changing a bit as part of getting PV support working.

~Andrew