From: Sean Christopherson <seanjc@google.com>
To: Like Xu <like.xu.linux@gmail.com>
Cc: kvm@vger.kernel.org, linux-kernel@vger.kernel.org,
Peter Zijlstra <peterz@infradead.org>,
Andy Lutomirski <luto@kernel.org>,
Thomas Gleixner <tglx@linutronix.de>,
Paolo Bonzini <pbonzini@redhat.com>
Subject: Re: [PATCH 7/7] KVM: VMX: Handle NMI VM-Exits in noinstr region
Date: Thu, 24 Aug 2023 07:26:20 -0700 [thread overview]
Message-ID: <ZOdojKCxPMV8KNo3@google.com> (raw)
In-Reply-To: <ZOdmPqq6uXMSWOnV@google.com>
On Thu, Aug 24, 2023, Sean Christopherson wrote:
> On Thu, Aug 24, 2023, Like Xu wrote:
> > @@ -7389,6 +7382,13 @@ static fastpath_t vmx_vcpu_run(struct kvm_vcpu *vcpu)
> >
> > trace_kvm_exit(vcpu, KVM_ISA_VMX);
> >
> > + if ((u16)vmx->exit_reason.basic == EXIT_REASON_EXCEPTION_NMI &&
> > + is_nmi(vmx_get_intr_info(vcpu))) {
> > + kvm_before_interrupt(vcpu, KVM_HANDLING_NMI);
> > + vmx_do_nmi_irqoff();
> > + kvm_after_interrupt(vcpu);
> > + }
>
> No, the whole point of doing NMI handling in vmx_vcpu_enter_exit() is so that NMIs
> are serviced before instrumentation is enabled.
>
> I think the below is sufficient (untested at this point). Not quite minimal, e.g.
> I'm pretty sure there's (currently) no need to snapshot IDT_VECTORING_INFO_FIELD
> so early, but I can't think of any reason to wait.
>
> --
> From: Sean Christopherson <seanjc@google.com>
> Date: Thu, 24 Aug 2023 06:49:36 -0700
> Subject: [PATCH] KVM: VMX: Refresh available regs and IDT vectoring info
> before NMI handling
>
> Reset the mask of available "registers" and refresh the IDT vectoring
> info snapshot in vmx_vcpu_enter_exit(), before KVM potentially handles a
> an NMI VM-Exit. One of the "registers" that KVM VMX lazily loads is the
> vmcs.VM_EXIT_INTR_INFO field, which is holds the vector+type on "exception
> or NMI" VM-Exits, i.e. is needed to identify NMIs. Clearing the available
> registers bitmask after handling NMIs results in KVM querying info from
> the last VM-Exit that read vmcs.VM_EXIT_INTR_INFO, and leads to both
> missed NMIs and spurious NMIs from the guest's perspective.
Oof, it's not just from the guest's perspective, NMIs that are destined for host
consumption will suffer the same fate.
next prev parent reply other threads:[~2023-08-24 14:27 UTC|newest]
Thread overview: 25+ messages / expand[flat|nested] mbox.gz Atom feed top
2022-12-13 6:09 [PATCH 0/7] KVM: VMX: Handle NMI VM-Exits in noinstr section Sean Christopherson
2022-12-13 6:09 ` [PATCH 1/7] KVM: x86: Make vmx_get_exit_qual() and vmx_get_intr_info() noinstr-friendly Sean Christopherson
2022-12-13 6:09 ` [PATCH 2/7] KVM: VMX: Allow VM-Fail path of VMREAD helper to be instrumented Sean Christopherson
2022-12-13 6:09 ` [PATCH 3/7] KVM: VMX: Always inline eVMCS read/write helpers Sean Christopherson
2022-12-13 6:09 ` [PATCH 4/7] KVM: VMX: Always inline to_vmx() and to_kvm_vmx() Sean Christopherson
2022-12-13 6:09 ` [PATCH 5/7] x86/entry: KVM: Use dedicated VMX NMI entry for 32-bit kernels too Sean Christopherson
2022-12-14 8:05 ` Lai Jiangshan
2022-12-13 6:09 ` [PATCH 6/7] KVM: VMX: Provide separate subroutines for invoking NMI vs. IRQ handlers Sean Christopherson
2022-12-14 21:23 ` Li, Xin3
2022-12-15 0:26 ` Sean Christopherson
2022-12-15 3:06 ` Li, Xin3
2022-12-15 5:18 ` Li, Xin3
2022-12-13 6:09 ` [PATCH 7/7] KVM: VMX: Handle NMI VM-Exits in noinstr region Sean Christopherson
2023-01-19 9:49 ` Peter Zijlstra
2023-01-19 15:39 ` Sean Christopherson
2023-01-19 15:52 ` Peter Zijlstra
2023-08-24 6:57 ` Like Xu
2023-08-24 14:16 ` Sean Christopherson
2023-08-24 14:26 ` Sean Christopherson [this message]
2022-12-14 17:09 ` [PATCH 0/7] KVM: VMX: Handle NMI VM-Exits in noinstr section Li, Xin3
2023-01-18 19:14 ` Li, Xin3
2023-01-18 20:38 ` Sean Christopherson
2023-01-19 1:54 ` Li, Xin3
2023-01-19 9:50 ` Peter Zijlstra
2023-01-28 0:07 ` Sean Christopherson
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=ZOdojKCxPMV8KNo3@google.com \
--to=seanjc@google.com \
--cc=kvm@vger.kernel.org \
--cc=like.xu.linux@gmail.com \
--cc=linux-kernel@vger.kernel.org \
--cc=luto@kernel.org \
--cc=pbonzini@redhat.com \
--cc=peterz@infradead.org \
--cc=tglx@linutronix.de \
/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