All of lore.kernel.org
 help / color / mirror / Atom feed
From: Sean Christopherson <seanjc@google.com>
To: Chenyi Qiang <chenyi.qiang@intel.com>
Cc: Paolo Bonzini <pbonzini@redhat.com>,
	Vitaly Kuznetsov <vkuznets@redhat.com>,
	Wanpeng Li <wanpengli@tencent.com>,
	Jim Mattson <jmattson@google.com>, Joerg Roedel <joro@8bytes.org>,
	Xiaoyao Li <xiaoyao.li@intel.com>,
	kvm@vger.kernel.org, linux-kernel@vger.kernel.org
Subject: Re: [PATCH v5 1/3] KVM: X86: Save&restore the triple fault request
Date: Fri, 8 Apr 2022 02:48:33 +0000	[thread overview]
Message-ID: <Yk+igefI2Mt/UTuh@google.com> (raw)
In-Reply-To: <8347e6e3-5b22-c9c9-5e6b-9ea33c614d5a@intel.com>

On Thu, Apr 07, 2022, Chenyi Qiang wrote:
> 
> 
> On 4/7/2022 5:15 AM, Sean Christopherson wrote:
> > On Tue, Apr 05, 2022, Sean Christopherson wrote:
> > > On Tue, Apr 05, 2022, Sean Christopherson wrote:
> > > > On Fri, Mar 18, 2022, Chenyi Qiang wrote:
> > > > > @@ -4976,6 +4980,9 @@ static int kvm_vcpu_ioctl_x86_set_vcpu_events(struct kvm_vcpu *vcpu,
> > > > >   		}
> > > > >   	}
> > > > > +	if (events->flags & KVM_VCPUEVENT_TRIPLE_FAULT)
> > > > > +		kvm_make_request(KVM_REQ_TRIPLE_FAULT, vcpu);
> > > > > +
> > > > >   	kvm_make_request(KVM_REQ_EVENT, vcpu);
> > > > 
> > > > Looks correct, but this really needs a selftest, at least for the SET path since
> > > > the intent is to use that for the NOTIFY handling.  Doesn't need to be super fancy,
> > > > e.g. do port I/O from L2, inject a triple fault, and verify L1 sees the appropriate
> > > > exit.
> > > > 
> > > > Aha!  And for the GET path, abuse KVM_X86_SET_MCE with CR4.MCE=0 to coerce KVM into
> > > > making a KVM_REQ_TRIPLE_FAULT, that way there's no need to try and hit a timing
> > > > window to intercept the request.
> > > 
> > > Drat, I bet that MCE path means the WARN in nested_vmx_vmexit() can be triggered
> > > by userspace.  If so, this patch makes it really, really easy to hit, e.g. queue the
> > > request while L2 is active, then do KVM_SET_NESTED_STATE to force an "exit" without
> > > bouncing through kvm_check_nested_events().
> > > 
> > >    WARN_ON_ONCE(kvm_check_request(KVM_REQ_TRIPLE_FAULT, vcpu))
> > > 
> > > I don't think SVM has a user-triggerable WARN, but the request should still be
> > > dropped on forced exit from L2, e.g. I believe this is the correct fix:
> > 
> > Confirmed the WARN can be triggered by abusing this patch, I'll get a patch out
> > once I figure out why kvm/queue is broken.
> > 
> > diff --git a/tools/testing/selftests/kvm/x86_64/state_test.c b/tools/testing/selftests/kvm/x86_64/state_test.c
> > index 2e0a92da8ff5..b7faeae3dcc4 100644
> > --- a/tools/testing/selftests/kvm/x86_64/state_test.c
> > +++ b/tools/testing/selftests/kvm/x86_64/state_test.c
> > @@ -210,6 +210,12 @@ int main(int argc, char *argv[])
> >                  memset(&regs1, 0, sizeof(regs1));
> >                  vcpu_regs_get(vm, VCPU_ID, &regs1);
> > 
> > +               if (stage == 6) {
> > +                       state->events.flags |= 0x20;
> > +                       vcpu_events_set(vm, VCPU_ID, &state->events);
> > +                       vcpu_nested_state_set(vm, VCPU_ID, &state->nested, false);
> > +               }
> > +
> >                  kvm_vm_release(vm);
> > 
> >                  /* Restore state in a new VM.  */
> 
> Also verified the WARN with this. Then, is it still necessary to add an
> individual selftest about the working flow of save/restore triple fault
> event?

Yeah, the above hack fails the test even on a good kernel.  It's not an actual test
of the feature, just a hack to confirm the bug.

  reply	other threads:[~2022-04-08  2:48 UTC|newest]

Thread overview: 14+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2022-03-18  7:49 [PATCH v5 0/3] Introduce Notify VM exit Chenyi Qiang
2022-03-18  7:49 ` [PATCH v5 1/3] KVM: X86: Save&restore the triple fault request Chenyi Qiang
2022-04-05 23:31   ` Sean Christopherson
2022-04-05 23:44     ` Sean Christopherson
2022-04-06 21:15       ` Sean Christopherson
2022-04-07  6:12         ` Chenyi Qiang
2022-04-08  2:48           ` Sean Christopherson [this message]
2022-04-06 21:25       ` Sean Christopherson
2022-04-06  6:46     ` Chenyi Qiang
2022-04-06 21:51     ` Sean Christopherson
2022-03-18  7:49 ` [PATCH v5 2/3] KVM: VMX: Enable Notify VM exit Chenyi Qiang
2022-04-06  0:34   ` Sean Christopherson
2022-04-06 18:54     ` Sean Christopherson
2022-03-18  7:49 ` [PATCH v5 3/3] KVM: Add document for KVM_CAP_X86_NOTIFY_VMEXIT and KVM_EXIT_NOTIFY Chenyi Qiang

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=Yk+igefI2Mt/UTuh@google.com \
    --to=seanjc@google.com \
    --cc=chenyi.qiang@intel.com \
    --cc=jmattson@google.com \
    --cc=joro@8bytes.org \
    --cc=kvm@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=pbonzini@redhat.com \
    --cc=vkuznets@redhat.com \
    --cc=wanpengli@tencent.com \
    --cc=xiaoyao.li@intel.com \
    /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.