[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <ee7d815f-750f-3d0e-2def-1631be66a483@redhat.com>
Date: Thu, 23 Jan 2020 10:54:22 +0100
From: Paolo Bonzini <pbonzini@...hat.com>
To: Vitaly Kuznetsov <vkuznets@...hat.com>,
linmiaohe <linmiaohe@...wei.com>
Cc: kvm@...r.kernel.org, linux-kernel@...r.kernel.org, x86@...nel.org,
rkrcmar@...hat.com, sean.j.christopherson@...el.com,
wanpengli@...cent.com, jmattson@...gle.com, joro@...tes.org,
tglx@...utronix.de, mingo@...hat.com, bp@...en8.de, hpa@...or.com
Subject: Re: [PATCH] KVM: nVMX: set rflags to specify success in
handle_invvpid() default case
On 23/01/20 10:45, Vitaly Kuznetsov wrote:
>>> 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.
>>
>> So I'm leaning towards not applying Miaohe's patch.
>
> Well, we may at least want to converge on BUG_ON() for both
> handle_invvpid()/handle_invept(), there's no need for them to differ.
WARN_ON_ONCE + nested_vmx_failValid would probably be better, if we
really want to change this.
Paolo
Powered by blists - more mailing lists