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
