From: Sean Christopherson <seanjc@google.com>
To: Maxim Levitsky <mlevitsk@redhat.com>
Cc: kvm@vger.kernel.org, Sandipan Das <sandipan.das@amd.com>,
Paolo Bonzini <pbonzini@redhat.com>,
Jim Mattson <jmattson@google.com>,
Peter Zijlstra <peterz@infradead.org>,
Dave Hansen <dave.hansen@linux.intel.com>,
Borislav Petkov <bp@alien8.de>,
Pawan Gupta <pawan.kumar.gupta@linux.intel.com>,
Thomas Gleixner <tglx@linutronix.de>,
Ingo Molnar <mingo@redhat.com>,
Josh Poimboeuf <jpoimboe@kernel.org>,
Daniel Sneddon <daniel.sneddon@linux.intel.com>,
Jiaxi Chen <jiaxi.chen@linux.intel.com>,
Babu Moger <babu.moger@amd.com>,
linux-kernel@vger.kernel.org, Jing Liu <jing2.liu@intel.com>,
Wyes Karny <wyes.karny@amd.com>,
x86@kernel.org, "H. Peter Anvin" <hpa@zytor.com>,
Santosh Shukla <santosh.shukla@amd.com>
Subject: Re: [PATCH v2 09/11] KVM: SVM: Add VNMI bit definition
Date: Tue, 31 Jan 2023 22:42:13 +0000 [thread overview]
Message-ID: <Y9mZRU3nbz6ru2lS@google.com> (raw)
In-Reply-To: <20221129193717.513824-10-mlevitsk@redhat.com>
On Tue, Nov 29, 2022, Maxim Levitsky wrote:
> From: Santosh Shukla <santosh.shukla@amd.com>
>
> VNMI exposes 3 capability bits (V_NMI, V_NMI_MASK, and V_NMI_ENABLE) to
> virtualize NMI and NMI_MASK, Those capability bits are part of
> VMCB::intr_ctrl -
> V_NMI(11) - Indicates whether a virtual NMI is pending in the guest.
> V_NMI_MASK(12) - Indicates whether virtual NMI is masked in the guest.
> V_NMI_ENABLE(26) - Enables the NMI virtualization feature for the guest.
>
> When Hypervisor wants to inject NMI, it will set V_NMI bit, Processor
> will clear the V_NMI bit and Set the V_NMI_MASK which means the Guest is
> handling NMI, After the guest handled the NMI, The processor will clear
> the V_NMI_MASK on the successful completion of IRET instruction Or if
> VMEXIT occurs while delivering the virtual NMI.
>
> To enable the VNMI capability, Hypervisor need to program
> V_NMI_ENABLE bit 1.
>
> Reviewed-by: Maxim Levitsky <mlevitsk@redhat.com>
> Signed-off-by: Santosh Shukla <santosh.shukla@amd.com>
> ---
> arch/x86/include/asm/svm.h | 7 +++++++
> 1 file changed, 7 insertions(+)
>
> diff --git a/arch/x86/include/asm/svm.h b/arch/x86/include/asm/svm.h
> index cb1ee53ad3b189..26d6f549ce2b46 100644
> --- a/arch/x86/include/asm/svm.h
> +++ b/arch/x86/include/asm/svm.h
> @@ -203,6 +203,13 @@ struct __attribute__ ((__packed__)) vmcb_control_area {
> #define X2APIC_MODE_SHIFT 30
> #define X2APIC_MODE_MASK (1 << X2APIC_MODE_SHIFT)
>
> +#define V_NMI_PENDING_SHIFT 11
> +#define V_NMI_PENDING (1 << V_NMI_PENDING_SHIFT)
> +#define V_NMI_MASK_SHIFT 12
> +#define V_NMI_MASK (1 << V_NMI_MASK_SHIFT)
Argh, more KVM warts. The existing INT_CTL defines all use "mask" in the name,
so looking at V_NMI_MASK in the context of other code reads "vNMI is pending",
not "vNMIs are blocked".
IMO, the existing _MASK terminology is the one that's wrong, but there's an absurd
amount of prior art in svm.h :-(
And the really annoying one is V_INTR_MASKING_MASK, which IIRC says "virtual INTR
masking is enabled", not "virtual INTRs are blocked".
So maybe call this V_NMI_BLOCKING_MASK? And tack on _MASK too the others (even
though I agree it's ugly).
> +#define V_NMI_ENABLE_SHIFT 26
> +#define V_NMI_ENABLE (1 << V_NMI_ENABLE_SHIFT)
Hrm. I think I would prefer to keep the defines ordered by bit position. Knowing
that there's an enable bit isn't all that critical for understanding vNMI pending
and blocked.
next prev parent reply other threads:[~2023-01-31 22:42 UTC|newest]
Thread overview: 66+ messages / expand[flat|nested] mbox.gz Atom feed top
2022-11-29 19:37 [PATCH v2 00/11] SVM: vNMI (with my fixes) Maxim Levitsky
2022-11-29 19:37 ` [PATCH v2 01/11] KVM: nSVM: don't sync back tlb_ctl on nested VM exit Maxim Levitsky
2022-12-05 14:05 ` Santosh Shukla
2022-12-06 12:13 ` Maxim Levitsky
2022-11-29 19:37 ` [PATCH v2 02/11] KVM: nSVM: clean up the copying of V_INTR bits from vmcb02 to vmcb12 Maxim Levitsky
2023-01-28 0:37 ` Sean Christopherson
2023-01-31 1:44 ` Sean Christopherson
2023-02-24 14:38 ` Maxim Levitsky
2023-02-24 16:48 ` Sean Christopherson
2022-11-29 19:37 ` [PATCH v2 03/11] KVM: nSVM: explicitly raise KVM_REQ_EVENT on nested VM exit if L1 doesn't intercept interrupts Maxim Levitsky
2023-01-28 0:56 ` Sean Christopherson
2023-01-30 18:41 ` Sean Christopherson
2022-11-29 19:37 ` [PATCH v2 04/11] KVM: SVM: drop the SVM specific H_FLAGS Maxim Levitsky
2022-12-05 15:31 ` Santosh Shukla
2023-01-28 0:56 ` Sean Christopherson
2022-11-29 19:37 ` [PATCH v2 05/11] KVM: x86: emulator: stop using raw host flags Maxim Levitsky
2023-01-28 0:58 ` Sean Christopherson
2023-02-24 14:38 ` Maxim Levitsky
2022-11-29 19:37 ` [PATCH v2 06/11] KVM: SVM: add wrappers to enable/disable IRET interception Maxim Levitsky
2022-12-05 15:41 ` Santosh Shukla
2022-12-06 12:14 ` Maxim Levitsky
2022-12-08 12:09 ` Santosh Shukla
2022-12-08 13:44 ` Maxim Levitsky
2023-01-31 21:07 ` Sean Christopherson
2023-02-13 14:50 ` Santosh Shukla
2022-11-29 19:37 ` [PATCH v2 07/11] KVM: x86: add a delayed hardware NMI injection interface Maxim Levitsky
2023-01-28 1:09 ` Sean Christopherson
2023-01-31 21:12 ` Sean Christopherson
2023-02-08 9:35 ` Santosh Shukla
2023-02-08 9:32 ` Santosh Shukla
2023-02-24 14:39 ` Maxim Levitsky
2023-01-31 22:28 ` Sean Christopherson
2023-02-01 0:06 ` Sean Christopherson
2023-02-08 9:51 ` Santosh Shukla
2023-02-08 16:09 ` Sean Christopherson
2023-02-08 9:43 ` Santosh Shukla
2023-02-08 16:06 ` Sean Christopherson
2023-02-14 10:22 ` Santosh Shukla
2023-02-15 22:43 ` Sean Christopherson
2023-02-16 0:22 ` Sean Christopherson
2023-02-17 7:56 ` Santosh Shukla
2022-11-29 19:37 ` [PATCH v2 08/11] x86/cpu: Add CPUID feature bit for VNMI Maxim Levitsky
2022-11-29 19:37 ` [PATCH v2 09/11] KVM: SVM: Add VNMI bit definition Maxim Levitsky
2023-01-31 22:42 ` Sean Christopherson [this message]
2023-02-02 9:42 ` Santosh Shukla
2022-11-29 19:37 ` [PATCH v2 10/11] KVM: SVM: implement support for vNMI Maxim Levitsky
2022-12-04 17:18 ` Maxim Levitsky
2022-12-05 17:07 ` Santosh Shukla
2023-01-28 1:10 ` Sean Christopherson
2023-02-10 12:02 ` Santosh Shukla
2023-02-01 0:22 ` Sean Christopherson
2023-02-01 0:39 ` Sean Christopherson
2023-02-10 12:24 ` Santosh Shukla
2023-02-10 16:44 ` Sean Christopherson
2022-11-29 19:37 ` [PATCH v2 11/11] KVM: nSVM: implement support for nested VNMI Maxim Levitsky
2022-12-05 17:14 ` Santosh Shukla
2022-12-06 12:19 ` Maxim Levitsky
2022-12-08 12:11 ` Santosh Shukla
2023-02-01 0:44 ` Sean Christopherson
2022-12-06 9:58 ` [PATCH v2 00/11] SVM: vNMI (with my fixes) Santosh Shukla
2023-02-01 0:24 ` Sean Christopherson
2022-12-20 10:27 ` Maxim Levitsky
2022-12-21 18:44 ` Sean Christopherson
2023-01-15 9:05 ` Maxim Levitsky
2023-01-28 1:13 ` Sean Christopherson
2023-02-01 19:13 ` 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=Y9mZRU3nbz6ru2lS@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=jiaxi.chen@linux.intel.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;
as well as URLs for NNTP newsgroup(s).