Received-SPF: pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) client-ip=209.132.180.67;
From:   linmiaohe <linmiaohe@huawei.com>
To:     Vitaly Kuznetsov <vkuznets@redhat.com>,
        Paolo Bonzini <pbonzini@redhat.com>,
        Sean Christopherson <sean.j.christopherson@intel.com>,
        Jim Mattson <jmattson@google.com>
CC:     kvm list <kvm@vger.kernel.org>,
        LKML <linux-kernel@vger.kernel.org>,
        "the arch/x86 maintainers" <x86@kernel.org>,
        =?iso-8859-2?Q?Radim_Kr=E8m=E1=F8?= <rkrcmar@redhat.com>,
        Wanpeng Li <wanpengli@tencent.com>,
        Joerg Roedel <joro@8bytes.org>,
        Thomas Gleixner <tglx@linutronix.de>,
        Ingo Molnar <mingo@redhat.com>, Borislav Petkov <bp@alien8.de>,
        "H . Peter Anvin" <hpa@zytor.com>
Subject: Re: [PATCH] KVM: nVMX: set rflags to specify success in
 handle_invvpid() default case
Thread-Topic: [PATCH] KVM: nVMX: set rflags to specify success in
 handle_invvpid() default case
Thread-Index: AdXaOs5msQGrd2JlS/qT+AceqW9QkQ==
Date:   Mon, 3 Feb 2020 03:29:19 +0000
Message-ID: <668e0827d62c489cbf52b7bc5d27ba9b@huawei.com>
Accept-Language: en-US
Content-Language: zh-CN
Content-Type: text/plain; charset="iso-8859-2"
Content-Transfer-Encoding: 8BIT
MIME-Version: 1.0
Sender: linux-kernel-owner@vger.kernel.org
Precedence: bulk

Vitaly Kuznetsov <vkuznets@redhat.com> writes:
> Sean Christopherson <sean.j.christopherson@intel.com> writes:
>> On Thu, Jan 23, 2020 at 10:22:24AM -0800, Jim Mattson wrote:
>>> On Thu, Jan 23, 2020 at 1:54 AM Paolo Bonzini <pbonzini@redhat.com> wrote:
>>> >
>>> > 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
>>> 
>>> In both cases, something is seriously wrong. The only plausible 
>>> explanations are compiler error or hardware failure. It would be nice 
>>> to handle *all* such failures with a KVM_INTERNAL_ERROR exit to 
>>> userspace. (I'm also thinking of situations like getting a VM-exit 
>> for
>>>> INIT.)
>>
>> Ya.  Vitaly and I had a similar discussion[*].  The idea we tossed 
>> around was to also mark the VM as having encountered a KVM/hardware 
>> bug so that the VM is effectively dead.  That would also allow 
>> gracefully handling bugs that are detected deep in the stack, i.e. 
>> can't simply return 0 to get out to userspace.
>
>Yea, I was thinking about introducing a big hammer which would stop the whole VM as soon as possible to make it easier to debug such situations. Something like (not really tested):
>
Yea, please just ignore my origin patch and do what you want. :)
I'm sorry for reply in such a big day. I'am just backing from a really hard festival. :(