Re: [PATCH 2/4] x86/hvm: Disable non-FEP cross-vendor handling in #UD handler

[Alejandro Vallejo <alejandro.garciavallejo@xxxxxxx>]

On Thu Jan 22, 2026 at 6:28 PM CET, Teddy Astie wrote:
> Le 22/01/2026 à 17:52, Alejandro Vallejo a écrit :
>> Remove cross-vendor support now that VMs can no longer have a different
>> vendor than the host, leaving FEP as the sole raison-d'être for #UD
>> interception.
>> 
>> Not a functional change.
>> 
>> Signed-off-by: Alejandro Vallejo <alejandro.garciavallejo@xxxxxxx>
>> ---
>>   xen/arch/x86/hvm/hvm.c     | 25 ++++---------------------
>>   xen/arch/x86/hvm/svm/svm.c |  4 ++--
>>   xen/arch/x86/hvm/vmx/vmx.c |  4 ++--
>>   3 files changed, 8 insertions(+), 25 deletions(-)
>> 
>> diff --git a/xen/arch/x86/hvm/hvm.c b/xen/arch/x86/hvm/hvm.c
>> index 4d37a93c57..611ff83a60 100644
>> --- a/xen/arch/x86/hvm/hvm.c
>> +++ b/xen/arch/x86/hvm/hvm.c
>> @@ -3832,28 +3832,13 @@ int hvm_descriptor_access_intercept(uint64_t 
>> exit_info,
>>       return X86EMUL_OKAY;
>>   }
>>   
>> -static bool cf_check is_cross_vendor(
>> -    const struct x86_emulate_state *state, const struct x86_emulate_ctxt 
>> *ctxt)
>> -{
>> -    switch ( ctxt->opcode )
>> -    {
>> -    case X86EMUL_OPC(0x0f, 0x05): /* syscall */
>> -    case X86EMUL_OPC(0x0f, 0x34): /* sysenter */
>> -    case X86EMUL_OPC(0x0f, 0x35): /* sysexit */
>> -        return true;
>> -    }
>> -
>> -    return false;
>> -}
>> -
>> +#ifdef CONFIG_HVM_FEP
>
> I'm not sure it is wise to put it being ifdef given that we have it in 
> support.h.

We already abuse code elision in this manner. See domain_soft_reset(). It's
intentional, to avoid polluting the headers.

You'll get a link error anyway (as opposed to a compile time error).

>
> Given that this function now assume we have FEP enabled (since it's only 
> called in that case), I think we should rename it to reflect that, like 
> "hvm_fep_intercept" and drop the non-FEP logic.

I'm not a big fan of renaming the handler, because it'd force future changes
where #UD is invoked in more cases than HVM_FEP to rename it back.

But yes to the removal of the non-FEP logic.

Cheers,
Alejandro