|
[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;
|
![]() |
Lists.xenproject.org is hosted with RackSpace, monitoring our |