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: Wed, 6 Apr 2022 21:25:26 +0000 [thread overview]
Message-ID: <Yk4FRlBbt29Z6/e7@google.com> (raw)
In-Reply-To: <YkzUceG4rhw15U3i@google.com>
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:
>
> diff --git a/arch/x86/kvm/svm/nested.c b/arch/x86/kvm/svm/nested.c
> index 9a6dc2b38fcf..18c5e96b12a5 100644
> --- a/arch/x86/kvm/svm/nested.c
> +++ b/arch/x86/kvm/svm/nested.c
> @@ -1128,6 +1128,7 @@ void svm_leave_nested(struct kvm_vcpu *vcpu)
> if (is_guest_mode(vcpu)) {
> svm->nested.nested_run_pending = 0;
> svm->nested.vmcb12_gpa = INVALID_GPA;
> + kvm_clear_request(KVM_REQ_TRIPLE_FAULT, vcpu);
>
> leave_guest_mode(vcpu);
>
> diff --git a/arch/x86/kvm/vmx/nested.c b/arch/x86/kvm/vmx/nested.c
> index f18744f7ff82..0587ef647553 100644
> --- a/arch/x86/kvm/vmx/nested.c
> +++ b/arch/x86/kvm/vmx/nested.c
> @@ -6276,6 +6276,7 @@ void vmx_leave_nested(struct kvm_vcpu *vcpu)
> {
> if (is_guest_mode(vcpu)) {
> to_vmx(vcpu)->nested.nested_run_pending = 0;
> + kvm_clear_request(KVM_REQ_TRIPLE_FAULT, vcpu);
> nested_vmx_vmexit(vcpu, -1, 0, 0);
> }
> free_nested(vcpu);
>
Wrong again. Once your patch to save/restore via KVM_VCPUEVENT_TRIPLE_FAULT
lands, clearing KVM_REQ_TRIPLE_FAULT is wrong because that will result in KVM
dropping the request when forcing an exit from L2 in order to reload L2 state,
e.g. if userspace restores events before nested state. So I think the only thing
that can be done is to delete the WARN :-(
next prev parent reply other threads:[~2022-04-06 21:45 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
2022-04-06 21:25 ` Sean Christopherson [this message]
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=Yk4FRlBbt29Z6/e7@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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox