Re: [PATCH v4 12/14] x86/pv: System call handling in FRED mode

[Jan Beulich <jbeulich@suse.com>]

On 09.03.2026 23:25, Andrew Cooper wrote:
> On 27/02/2026 11:16 pm, Andrew Cooper wrote:
>> diff --git a/xen/arch/x86/traps.c b/xen/arch/x86/traps.c
>> index 2f40f628cbff..e2c35a046e6b 100644
>> --- a/xen/arch/x86/traps.c
>> +++ b/xen/arch/x86/traps.c
>> ...
>> +        case 2: /* SYSENTER */
>> +        {
>> +            /*
>> +             * FRED delivery preserves the interrupted state, but previously
>> +             * SYSENTER discarded almost everything.
>> +             *
>> +             * The guest isn't aware of FRED, so recreate the legacy
>> +             * behaviour.
>> +             *
>> +             * When setting the selectors, clear all upper metadata.  In
>> +             * particular fred_ss.swint becomes pend_DB on ERETx.
>> +             *
>> +             * When converting to a fault, hardware finally gives us enough
>> +             * information to account for prefixes, so provide the more
>> +             * correct behaviour rather than assuming the instruction was two
>> +             * bytes long.
>> +             */
>> +            unsigned int len = regs->fred_ss.insnlen;
>> +
>> +            regs->ssx = FLAT_USER_SS;
>> +            regs->rsp = 0;
>> +            regs->eflags &= ~(X86_EFLAGS_VM | X86_EFLAGS_IF);
>> +            regs->csx = 3;
>> +            regs->rip = 0;
>> +
>> +            if ( !curr->arch.pv.sysenter_callback_eip )
>> +            {
>> +                regs->rip -= len;
>> +                pv_inject_hw_exception(X86_EXC_GP, 0);
>> +            }
>> +            else
>> +                pv_inject_callback(CALLBACKTYPE_sysenter);
>> +            break;
> 
> This isn't actually a correct transformation of the IDT code.  When the
> SYENTER entrypoint isn't registered, this delivers a #GP at
> 0003:fffffffffffffffe
> 
> The simple fix to get back to IDT behaviour is to simply drop the
> subtraction of len.
> 
> In FRED mode, we can finally point the #GP at the SYSENTER instruction,
> rather than delivering at 0.  We could even provide the success case
> pointing sensibly too.
> 
> The question is should we?  Until now, the differences between FRED and
> IDT mode are minimal.  This would be major difference, and it's for
> SYSENTER which all but unused.  I'm erring on the side of "match IDT".

I agree. Down the road we could introduce an opt-in "better behavior" mode
when running under FRED (also covering other aspects previously discussed).

Jan