Messages in this thread | | | Subject | Re: [PATCH] KVM: nVMX: set rflags to specify success in handle_invvpid() default case | From | Paolo Bonzini <> | Date | Thu, 23 Jan 2020 10:23:42 +0100 |
| |
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,
| |