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 10/13] KVM: SVM: Add VNMI support in inject_nmi
Date: Mon, 21 Nov 2022 17:12:11 +0000 [thread overview]
Message-ID: <Y3uxayZrhvahkzJt@google.com> (raw)
In-Reply-To: <20221117143242.102721-11-mlevitsk@redhat.com>
On Thu, Nov 17, 2022, Maxim Levitsky wrote:
> From: Santosh Shukla <santosh.shukla@amd.com>
>
> Inject the NMI by setting V_NMI in the VMCB interrupt control. processor
> will clear V_NMI to acknowledge processing has started and will keep the
> V_NMI_MASK set until the processor is done with processing the NMI event.
>
> Also, handle the nmi_l1_to_l2 case such that when it is true then
> NMI to be injected originally comes from L1's VMCB12 EVENTINJ field.
> So adding a check for that case.
>
> Signed-off-by: Santosh Shukla <santosh.shukla@amd.com>
> Reviewed-by: Maxim Levitsky <mlevitsk@redhat.com>
> ---
> arch/x86/kvm/svm/svm.c | 7 +++++++
> 1 file changed, 7 insertions(+)
>
> diff --git a/arch/x86/kvm/svm/svm.c b/arch/x86/kvm/svm/svm.c
> index eaa30f8ace518d..9ebfbd0d4b467e 100644
> --- a/arch/x86/kvm/svm/svm.c
> +++ b/arch/x86/kvm/svm/svm.c
> @@ -3479,7 +3479,14 @@ static void pre_svm_run(struct kvm_vcpu *vcpu)
> static void svm_inject_nmi(struct kvm_vcpu *vcpu)
> {
> struct vcpu_svm *svm = to_svm(vcpu);
> + struct vmcb *vmcb = NULL;
As written, no need to initialize vmcb. Might be a moot point depending on the
final form of the code.
> + if (is_vnmi_enabled(svm) && !svm->nmi_l1_to_l2) {
Checking nmi_l1_to_l2 is wrong. KVM should directly re-inject any NMI that was
already recognized by hardware, not just those that were originally injected by
L1.
If another event comes along, e.g. SMI, because an event (NMI) is already injected,
KVM will send a hardware IRQ to interrupt the guest and forcea a VM-Exit so that
the SMI can be injected. If hardware does the (IMO) sane thing and prioritizes
"real" IRQs over virtual NMIs, the IRQ VM-Exit will occur before the virtual NMI
is processed and KVM will incorrectly service the SMI before the NMI.
I believe the correct way to handle this is to add a @reinjected param to
->inject_nmi(), a la ->inject_irq(). That would also allow adding a sanity check
that KVM never attempts to inject an NMI into L2 if NMIs are supposed to trigger
VM-Exit.
This is the least ugly code I could come up with. Note, if vNMI is enabled,
hardare sets V_NMI_MASKED if an NMI is injected through event_inj.
static void svm_inject_nmi(struct kvm_vcpu *vcpu, bool reinjected)
{
struct vcpu_svm *svm = to_svm(vcpu);
/*
* Except for re-injection, KVM should never inject an NMI into L2 if
* NMIs are supposed to exit from L2 to L1.
*/
WARN_ON_ONCE(!reinjected && is_guest_mode(vcpu) && nested_exit_on_nmi(svm));
if (is_vnmi_enabled(svm)) {
if (!reinjected)
svm->vmcb->control.int_ctl |= V_NMI_PENDING;
else
svm->vmcb->control.event_inj = SVM_EVTINJ_VALID |
SVM_EVTINJ_TYPE_NMI;
++vcpu->stat.nmi_injections;
return;
}
svm->vmcb->control.event_inj = SVM_EVTINJ_VALID | SVM_EVTINJ_TYPE_NMI;
if (svm->nmi_l1_to_l2)
return;
vcpu->arch.hflags |= HF_NMI_MASK;
if (!sev_es_guest(vcpu->kvm))
svm_set_intercept(svm, INTERCEPT_IRET);
++vcpu->stat.nmi_injections;
}
next prev parent reply other threads:[~2022-11-21 17:13 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
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 [this message]
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=Y3uxayZrhvahkzJt@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