On 23/01/20 09:55, Vitaly Kuznetsov wrote: >> diff --git a/arch/x86/kvm/vmx/nested.c b/arch/x86/kvm/vmx/nested.c >> index 7608924ee8c1..985d3307ec56 100644 >> --- a/arch/x86/kvm/vmx/nested.c >> +++ b/arch/x86/kvm/vmx/nested.c >> @@ -5165,7 +5165,7 @@ static int handle_invvpid(struct kvm_vcpu *vcpu) >> break; >> default: >> WARN_ON_ONCE(1); >> - return kvm_skip_emulated_instruction(vcpu); >> + break; >> } >> >> return nested_vmx_succeed(vcpu); > Your patch seems to do the right thing, however, I started wondering if > WARN_ON_ONCE() is the right thing to do. SDM says that "If an > unsupported INVVPID type is specified, the instruction fails." and this > is similar to INVEPT and I decided to check what handle_invept() > does. Well, it does BUG_ON(). > > Are we doing the right thing in any of these cases? Yes, both INVEPT and INVVPID catch this earlier. For INVEPT: types = (vmx->nested.msrs.ept_caps >> VMX_EPT_EXTENT_SHIFT) & 6; if (type >= 32 || !(types & (1 << type))) return nested_vmx_failValid(vcpu, VMXERR_INVALID_OPERAND_TO_INVEPT_INVVPID); For INVVPID: types = (vmx->nested.msrs.vpid_caps & VMX_VPID_EXTENT_SUPPORTED_MASK) >> 8; if (type >= 32 || !(types & (1 << type))) return nested_vmx_failValid(vcpu, VMXERR_INVALID_OPERAND_TO_INVEPT_INVVPID); So I'm leaning towards not applying Miaohe's patch. Happy Mouse Year to everyone, here is an ASCII art (except for one Unicode character) mouse: __()() / o) ~~~~\_,__,_>° Thanks,