[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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



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.

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


> > +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 changed it to:

ASSERT_UNREACHABLE();
return X86EMUL_EXCEPTION;

 


Rackspace

Lists.xenproject.org is hosted with RackSpace, monitoring our
servers 24x7x365 and backed by RackSpace's Fanatical Support®.