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

[Alejandro Vallejo <alejandro.garciavallejo@xxxxxxx>]

On Fri Jan 23, 2026 at 7:40 PM CET, Andrew Cooper wrote:
> On 22/01/2026 4:49 pm, Alejandro Vallejo wrote:
>> diff --git a/xen/arch/x86/hvm/vmx/vmx.c b/xen/arch/x86/hvm/vmx/vmx.c
>> index 40e4c71244..34e988ee61 100644
>> --- a/xen/arch/x86/hvm/vmx/vmx.c
>> +++ b/xen/arch/x86/hvm/vmx/vmx.c
>> @@ -797,8 +797,7 @@ static void cf_check vmx_cpuid_policy_changed(struct 
>> vcpu *v)
>>      const struct cpu_policy *cp = v->domain->arch.cpu_policy;
>>      int rc = 0;
>>  
>> -    if ( opt_hvm_fep ||
>> -         (v->domain->arch.cpuid->x86_vendor != boot_cpu_data.x86_vendor) )
>> +    if ( opt_hvm_fep )
>>          v->arch.hvm.vmx.exception_bitmap |= (1U << X86_EXC_UD);
>>      else
>>          v->arch.hvm.vmx.exception_bitmap &= ~(1U << X86_EXC_UD);
>> @@ -4576,6 +4575,7 @@ void asmlinkage vmx_vmexit_handler(struct 
>> cpu_user_regs *regs)
>>              /* Already handled above. */
>>              break;
>>          case X86_EXC_UD:
>> +            BUG_ON(!IS_ENABLED(CONFIG_HVM_FEP));
>>              TRACE(TRC_HVM_TRAP, vector);
>>              hvm_ud_intercept(regs);
>>              break;
>
> Again, nested virt makes this more complicated than to simply believe it
> doesn't happen.

How so? nested vmexits go on a separate function (nvmx_n2_vmexit_handler()),
which is purposefully dispatched earlier. This switch is strictly for non-nested
exits or it would be all sorts of wrong for other reasons.

Either (non-nested) #UD does happen, in which case I want to know how. Or
it doesn't, in which case we have dead code. Both cannot be simultaneously
true. The #UD handler is (after the should_emulate fixup) just doing FEP and
re-injecting otherwise. Whether there is an "otherwise" is relevant for the
refactor and Teddy's rightful request.

>
> Also, more often than I'd like, I enable #UD interception for other
> reasons, and I'd prefer that that doesn't get any harder than it does
> right now.

It's equally simple with hvm_fep=1 in the cmdline for an unmodified Xen (to
get the tracepoint). With a modified Xen it's a BUG_ON() removal, or running
with HVM_FEP, which affects security but not performance (so it's ok for one-off
tests). I could also conditionalise it to #ifndef CONFIG_DEBUG, as the
overwhelming majority of the time you'll run your tests in debug mode.

Do any of those options sound fine? Shipping a dead function to users/customers
because it's occasionally useful during development sounds like bad policy to
me.

>
> In an ideal world I'd have already upstreamed the logic to decompose
> double/triple faults...

Sorry, I'm afraid I don't follow what this ties in with. Is this why you find
#UD interception helpful?

Cheers,
Alejandro