Re: [PATCH v2] x86/hvm: Add Kconfig option to disable nested virtualization

[Roger Pau Monné <roger.pau@xxxxxxxxxx>]

On Fri, Feb 13, 2026 at 01:56:34PM -0800, Stefano Stabellini wrote:
> I address all other comments
> 
> 
> On Mon, 9 Feb 2026, Roger Pau Monné wrote:
> > > +static inline int nvmx_msr_read_intercept(unsigned int msr, u64
> > > *msr_content)
> > > +{
> > > +    ASSERT_UNREACHABLE();
> > > +    return 0;
> > > +}
> > >
> > I think this function is reachable even when nested virt is not
> > enabled:
> > 
> > vmx_msr_read_intercept() -> case MSR_IA32_VMX_BASIC...MSR_IA32_VMX_VMFUNC 
> > -> nvmx_msr_read_intercept()
> > 
> > I'm also confused about why the function returns 0 instead of an error
> > when !nestedhvm_enabled().  We should probably make it return -ENODEV
> > when nested virt is not available or enabled.

Oh, I see.  The return type of that function is weird.  It should be
adjusted to bool (not that you need to do it here).

> I agree on the way of thinking but if we return zero it will goto gp_fault.
> So I'll just remove ASSERT_UNREACHABLE.

Ack.

> 
> > > +static inline int nvmx_handle_vmx_insn(struct cpu_user_regs *regs,
> > > +                                       unsigned int exit_reason)
> > > +{
> > > +    ASSERT_UNREACHABLE();
> > > +    return 0;
> > > +}
> > 
> > Same here, I think this is likely reachable from vmx_vmexit_handler(),
> > and shouldn't assert?
> > 
> > It should also do something like:
> > 
> >     hvm_inject_hw_exception(X86_EXC_UD, X86_EVENT_NO_EC);
> >     return X86EMUL_EXCEPTION;
> > 
> > So it mimics what the function itself does when !nestedhvm_enabled().
> 
> hvm_inject_hw_exception cannot be easily called here because it is not
> available at this point in the header. But actually this function should
> be unreachable because when !CONFIG_NESTED_VIRT, CR4.VMXE is not
> a valid guest CR4 bit, so nested VMX instructions should cause #UD?

I'm not sure about nvmx_handle_vmx_insn() being unreachable when
CR4.VMXE is not set, the Intel SDM states:

"26.1.2 Instructions That Cause VM Exits Unconditionally

The following instructions cause VM exits when they are executed in
VMX non-root operation: CPUID, GETSEC,1 INVD, and XSETBV. This is also
true of instructions introduced with VMX, which include: INVEPT,
INVVPID, VMCALL,2 VMCLEAR, VMLAUNCH, VMPTRLD, VMPTRST, VMRESUME,
VMXOFF, and VMXON."

My reading is that regardless of the value of CR4.VMXE the execution
of VMX instructions will cause a VMEXIT, and it's the hypervisor task
to figure out what to do.

> 
> I changed it to:
> 
> ASSERT_UNREACHABLE();
> return X86EMUL_EXCEPTION;

If the above is correct, the ASSERT_UNREACHABLE() is reachable.

Returning X86EMUL_EXCEPTION without actually having injected the
exception will result in a loop I think, as vmx_vmexit_handler() will
resume guest execution without having advanced the instruction
pointer, and without having injected an exception, and hence another
VMEXIT will trigger.

IMO the best way to solve this is to make vmx_vmexit_handler() inject
#UD when nvmx_handle_vmx_insn() returns X86EMUL_EXCEPTION. You will
need to then also adjust the non-stub version of
nvmx_handle_vmx_insn(), so it doesn't inject #UD itself.

Thanks, Roger.