From: Sean Christopherson <seanjc@google.com>
To: Maxim Levitsky <mlevitsk@redhat.com>
Cc: kvm@vger.kernel.org, Paolo Bonzini <pbonzini@redhat.com>,
Ingo Molnar <mingo@redhat.com>, "H. Peter Anvin" <hpa@zytor.com>,
Dave Hansen <dave.hansen@linux.intel.com>,
linux-kernel@vger.kernel.org,
Peter Zijlstra <peterz@infradead.org>,
Thomas Gleixner <tglx@linutronix.de>,
Sandipan Das <sandipan.das@amd.com>,
Daniel Sneddon <daniel.sneddon@linux.intel.com>,
Jing Liu <jing2.liu@intel.com>,
Josh Poimboeuf <jpoimboe@kernel.org>,
Wyes Karny <wyes.karny@amd.com>, Borislav Petkov <bp@alien8.de>,
Babu Moger <babu.moger@amd.com>,
Pawan Gupta <pawan.kumar.gupta@linux.intel.com>,
Jim Mattson <jmattson@google.com>,
x86@kernel.org, Santosh Shukla <santosh.shukla@amd.com>
Subject: Re: [PATCH 07/13] KVM: SVM: Add VNMI support in get/set_nmi_mask
Date: Tue, 6 Dec 2022 18:27:04 +0000 [thread overview]
Message-ID: <Y4+JeAiT8IpTXux9@google.com> (raw)
In-Reply-To: <5bde88433d6962e38a4c2ddad778395cea98d13b.camel@redhat.com>
On Sun, Dec 04, 2022, Maxim Levitsky wrote:
> For vNMI case it turns out that we don't need to intercept IRET at all after all:
>
> Turns out that when vNMI is pending, you can still EVENTINJ another NMI, and
> the pending vNMI will be kept pending, vNMI will became masked due to
> EVENTINJ, and on IRET the pending vNMI will be serviced as well, so in total
> both NMIs will be serviced.
I believe past me was thinking that the "merging" of pending NMIs happened in the
context of the sender, but it always happens in the context of the target vCPU.
Senders always do KVM_REQ_NMI, i.e. always kick if the vCPU in running, which gives
KVM the hook it needs to update the VMCB.
So yeah, as long as KVM can stuff two NMIs into the VMCB, I think we're good.
I'll give the series a proper review in the next week or so.
next prev parent reply other threads:[~2022-12-06 18:32 UTC|newest]
Thread overview: 33+ messages / expand[flat|nested] mbox.gz Atom feed top
2022-11-17 14:32 [PATCH 00/13] SVM: vNMI (with my fixes) Maxim Levitsky
2022-11-17 14:32 ` [PATCH 01/13] KVM: nSVM: don't sync back tlb_ctl on nested VM exit Maxim Levitsky
2022-11-17 14:32 ` [PATCH 02/13] KVM: nSVM: don't call nested_sync_control_from_vmcb02 on each " Maxim Levitsky
2022-11-17 20:04 ` Sean Christopherson
2022-11-21 11:07 ` Maxim Levitsky
2022-11-21 17:51 ` Sean Christopherson
2022-11-17 14:32 ` [PATCH 03/13] KVM: nSVM: rename nested_sync_control_from_vmcb02 to nested_sync_int_ctl_from_vmcb02 Maxim Levitsky
2022-11-17 14:32 ` [PATCH 04/13] KVM: nSVM: clean up copying of int_ctl fields back to vmcb01/vmcb12 Maxim Levitsky
2022-11-17 20:15 ` Sean Christopherson
2022-11-21 11:10 ` Maxim Levitsky
2022-11-17 14:32 ` [PATCH 05/13] x86/cpu: Add CPUID feature bit for VNMI Maxim Levitsky
2022-11-17 14:32 ` [PATCH 06/13] KVM: SVM: Add VNMI bit definition Maxim Levitsky
2022-11-17 14:37 ` Borislav Petkov
2022-11-17 16:42 ` Sean Christopherson
2022-11-17 17:07 ` Borislav Petkov
2022-11-17 20:33 ` Sean Christopherson
2022-11-17 20:27 ` Sean Christopherson
2022-11-17 14:32 ` [PATCH 07/13] KVM: SVM: Add VNMI support in get/set_nmi_mask Maxim Levitsky
2022-11-17 18:54 ` Sean Christopherson
2022-11-21 12:36 ` Maxim Levitsky
2022-11-21 17:18 ` Sean Christopherson
2022-12-04 18:42 ` Maxim Levitsky
2022-12-06 18:27 ` Sean Christopherson [this message]
2022-11-17 14:32 ` [PATCH 08/13] KVM: SVM: Report NMI not allowed when Guest busy handling VNMI Maxim Levitsky
2022-11-17 14:32 ` [PATCH 09/13] KVM: SVM: allow NMI window with vNMI Maxim Levitsky
2022-11-17 18:21 ` Sean Christopherson
2022-11-21 13:40 ` Maxim Levitsky
2022-11-17 14:32 ` [PATCH 10/13] KVM: SVM: Add VNMI support in inject_nmi Maxim Levitsky
2022-11-21 17:12 ` Sean Christopherson
2022-11-17 14:32 ` [PATCH 11/13] KVM: nSVM: implement nested VNMI Maxim Levitsky
2022-11-17 14:32 ` [PATCH 12/13] KVM: nSVM: emulate VMEXIT_INVALID case for " Maxim Levitsky
2022-11-17 20:18 ` Sean Christopherson
2022-11-17 14:32 ` [PATCH 13/13] KVM: SVM: Enable VNMI feature Maxim Levitsky
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=Y4+JeAiT8IpTXux9@google.com \
--to=seanjc@google.com \
--cc=babu.moger@amd.com \
--cc=bp@alien8.de \
--cc=daniel.sneddon@linux.intel.com \
--cc=dave.hansen@linux.intel.com \
--cc=hpa@zytor.com \
--cc=jing2.liu@intel.com \
--cc=jmattson@google.com \
--cc=jpoimboe@kernel.org \
--cc=kvm@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=mingo@redhat.com \
--cc=mlevitsk@redhat.com \
--cc=pawan.kumar.gupta@linux.intel.com \
--cc=pbonzini@redhat.com \
--cc=peterz@infradead.org \
--cc=sandipan.das@amd.com \
--cc=santosh.shukla@amd.com \
--cc=tglx@linutronix.de \
--cc=wyes.karny@amd.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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox