From: Sean Christopherson <seanjc@google.com>
To: Santosh Shukla <santosh.shukla@amd.com>
Cc: kvm@vger.kernel.org, pbonzini@redhat.com, jmattson@google.com,
joro@8bytes.org, linux-kernel@vger.kernel.org,
mail@maciej.szmigiero.name, mlevitsk@redhat.com,
thomas.lendacky@amd.com, vkuznets@redhat.com
Subject: Re: [PATCHv4 09/11] KVM: SVM: Add VNMI bit definition
Date: Wed, 22 Mar 2023 17:54:40 -0700 [thread overview]
Message-ID: <ZBujUGXG0JlOLEBh@google.com> (raw)
In-Reply-To: <20230227084016.3368-10-santosh.shukla@amd.com>
On Mon, Feb 27, 2023, Santosh Shukla wrote:
> 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_PENDING_MASK(11) - Indicates whether a virtual NMI is pending in the
> guest.
> V_NMI_BLOCKING_MASK(12) - Indicates whether virtual NMI is masked in the
> guest.
> V_NMI_ENABLE_MASK(26) - Enables the NMI virtualization feature for the
> guest.
This is way harder to read than it needs to be. The intent of the various rules
for line length and whatnot is to make code/changelogs easier to read. That intent
is lost if code/changelogs are written without actually considering the rules.
In other words, don't write changeloges, comments, etc. without thinking about how
the result will look when the line length rules apply.
Add defines for three new bits in VMVC::int_ctrl that are part of SVM's
Virtual NMI (vNMI) support:
V_NMI_PENDING_MASK(11) - Virtual NMI is pending
V_NMI_BLOCKING_MASK(12) - Virtual NMI is masked
V_NMI_ENABLE_MASK(26) - Enable NMI virtualization
To "inject" an NMI, the hypervisor (KVM) sets V_NMI_PENDING. When the
CPU services the pending vNMI, hardware clears V_NMI_PENDING and sets
V_NMI_BLOCKING, e.g. to indicate that the vCPU is handling an NMI.
Hardware clears V_NMI_BLOCKING upon successful execution of IRET, or if a
VM-Exit occurs while delivering the virtual NMI.
next prev parent reply other threads:[~2023-03-23 0:54 UTC|newest]
Thread overview: 22+ messages / expand[flat|nested] mbox.gz Atom feed top
2023-02-27 8:40 [PATCHv4 00/11] SVM: virtual NMI Santosh Shukla
2023-02-27 8:40 ` [PATCHv4 01/11] KVM: nSVM: Don't sync vmcb02 V_IRQ back to vmcb12 if KVM (L0) is intercepting VINTR Santosh Shukla
2023-02-27 8:40 ` [PATCHv4 02/11] KVM: nSVM: Disable intercept of VINTR if saved RFLAG.IF is 0 Santosh Shukla
2023-02-27 8:40 ` [PATCHv4 03/11] KVM: nSVM: Raise event on nested VM exit if L1 doesn't intercept IRQs Santosh Shukla
2023-02-27 8:40 ` [PATCHv4 04/11] KVM: SVM: add wrappers to enable/disable IRET interception Santosh Shukla
2023-02-27 8:40 ` [PATCHv4 05/11] KVM: x86: Raise an event request when processing NMIs if an NMI is pending Santosh Shukla
2023-02-27 8:40 ` [PATCHv4 06/11] KVM: x86: Tweak the code and comment related to handling concurrent NMIs Santosh Shukla
2023-02-27 8:40 ` [PATCHv4 07/11] KVM: x86: Save/restore all NMIs when multiple NMIs are pending Santosh Shukla
2023-02-27 8:40 ` [PATCHv4 08/11] x86/cpu: Add CPUID feature bit for VNMI Santosh Shukla
2023-03-22 19:07 ` Sean Christopherson
2023-02-27 8:40 ` [PATCHv4 09/11] KVM: SVM: Add VNMI bit definition Santosh Shukla
2023-03-23 0:54 ` Sean Christopherson [this message]
2023-02-27 8:40 ` [PATCHv4 10/11] KVM: x86: add support for delayed virtual NMI injection interface Santosh Shukla
2023-03-23 0:49 ` Sean Christopherson
2023-02-27 8:40 ` [PATCHv4 11/11] KVM: nSVM: implement support for nested VNMI Santosh Shukla
2023-03-23 0:50 ` Sean Christopherson
2023-03-10 9:19 ` [PATCHv4 00/11] SVM: virtual NMI Santosh Shukla
2023-03-10 17:02 ` Sean Christopherson
2023-03-23 0:57 ` Sean Christopherson
2023-03-23 1:14 ` Sean Christopherson
2023-03-23 22:53 ` Sean Christopherson
2023-03-24 8:25 ` Santosh Shukla
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=ZBujUGXG0JlOLEBh@google.com \
--to=seanjc@google.com \
--cc=jmattson@google.com \
--cc=joro@8bytes.org \
--cc=kvm@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=mail@maciej.szmigiero.name \
--cc=mlevitsk@redhat.com \
--cc=pbonzini@redhat.com \
--cc=santosh.shukla@amd.com \
--cc=thomas.lendacky@amd.com \
--cc=vkuznets@redhat.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;
as well as URLs for NNTP newsgroup(s).