All of lore.kernel.org
 help / color / mirror / Atom feed
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>,
	"Radim Krčmář" <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
Date: Mon, 3 Feb 2020 03:29:19 +0000	[thread overview]
Message-ID: <668e0827d62c489cbf52b7bc5d27ba9b@huawei.com> (raw)

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. :(

             reply	other threads:[~2020-02-03  3:29 UTC|newest]

Thread overview: 12+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2020-02-03  3:29 linmiaohe [this message]
2020-02-03  9:48 ` [PATCH] KVM: nVMX: set rflags to specify success in handle_invvpid() default case Vitaly Kuznetsov
  -- strict thread matches above, loose matches on Subject: below --
2020-02-04  1:06 linmiaohe
2020-01-23  9:36 linmiaohe
2020-01-23  3:14 linmiaohe
2020-01-23  8:55 ` Vitaly Kuznetsov
2020-01-23  9:23   ` Paolo Bonzini
2020-01-23  9:45     ` Vitaly Kuznetsov
2020-01-23  9:54       ` Paolo Bonzini
2020-01-23 18:22         ` Jim Mattson
2020-01-23 23:01           ` Sean Christopherson
2020-01-24 10:53             ` Vitaly Kuznetsov

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=668e0827d62c489cbf52b7bc5d27ba9b@huawei.com \
    --to=linmiaohe@huawei.com \
    --cc=bp@alien8.de \
    --cc=hpa@zytor.com \
    --cc=jmattson@google.com \
    --cc=joro@8bytes.org \
    --cc=kvm@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=mingo@redhat.com \
    --cc=pbonzini@redhat.com \
    --cc=rkrcmar@redhat.com \
    --cc=sean.j.christopherson@intel.com \
    --cc=tglx@linutronix.de \
    --cc=vkuznets@redhat.com \
    --cc=wanpengli@tencent.com \
    --cc=x86@kernel.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.