All of lore.kernel.org
 help / color / mirror / Atom feed
From: Jacob Pan <jacob.jun.pan@linux.intel.com>
To: Xin Li <xin@zytor.com>
Cc: X86 Kernel <x86@kernel.org>,
	Sean Christopherson <seanjc@google.com>,
	LKML <linux-kernel@vger.kernel.org>,
	Thomas Gleixner <tglx@linutronix.de>,
	Dave Hansen <dave.hansen@intel.com>,
	"H. Peter Anvin" <hpa@zytor.com>, Ingo Molnar <mingo@redhat.com>,
	Borislav Petkov <bp@alien8.de>, Xin Li <xin3.li@intel.com>,
	linux-perf-users@vger.kernel.org,
	Peter Zijlstra <peterz@infradead.org>,
	Paolo Bonzini <pbonzini@redhat.com>,
	Tony Luck <tony.luck@intel.com>,
	Andy Lutomirski <luto@kernel.org>,
	acme@kernel.org, kan.liang@linux.intel.com,
	Andi Kleen <andi.kleen@intel.com>,
	"Mehta, Sohil" <sohil.mehta@intel.com>,
	Zeng Guang <guang.zeng@intel.com>,
	jacob.jun.pan@linux.intel.com
Subject: Re: [PATCH v3 07/11] KVM: VMX: Handle NMI Source report in VM exit
Date: Mon, 1 Jul 2024 08:45:58 -0700	[thread overview]
Message-ID: <20240701084558.1620584f@jacob-builder> (raw)
In-Reply-To: <6c8160e4-3d67-410d-aad0-3ec731a903f8@zytor.com>


On Fri, 28 Jun 2024 21:07:04 -0700, Xin Li <xin@zytor.com> wrote:

> On 6/28/2024 1:18 PM, Jacob Pan wrote:
> > From: Zeng Guang <guang.zeng@intel.com>
> > 
> > If the "NMI exiting" VM-execution control is 1, the value of the 16-bit
> > NMI source vector is saved in the exit-qualification field in the VMCS
> > when VM exits occur on CPUs that support NMI source.
> > 
> > KVM that is aware of NMI-source reporting will push the bitmask of NMI
> > source vectors as the exceptoin event data field on the stack for then
> > entry of FRED exception. Subsequently, the host NMI exception handler
> > is invoked which will process NMI source information in the event data.
> > This operation is independent of vCPU FRED enabling status.
> > 
> > Signed-off-by: Zeng Guang <guang.zeng@intel.com>
> > Signed-off-by: Jacob Pan <jacob.jun.pan@linux.intel.com>
> > ---
> >   arch/x86/entry/entry_64_fred.S |  2 +-
> >   arch/x86/kvm/vmx/vmx.c         | 11 ++++++++---
> >   2 files changed, 9 insertions(+), 4 deletions(-)
> > 
> > diff --git a/arch/x86/entry/entry_64_fred.S
> > b/arch/x86/entry/entry_64_fred.S index a02bc6f3d2e6..0d934a3fcaf8 100644
> > --- a/arch/x86/entry/entry_64_fred.S
> > +++ b/arch/x86/entry/entry_64_fred.S
> > @@ -92,7 +92,7 @@ SYM_FUNC_START(asm_fred_entry_from_kvm)
> >   	 * +--------+-----------------+
> >   	 */
> >   	push $0				/* Reserved, must be 0
> > */
> > -	push $0				/* Event data, 0 for
> > IRQ/NMI */
> > +	push %rsi			/* Event data for IRQ/NMI */
> >   	push %rdi			/* fred_ss handed in by the
> > caller */ push %rbp
> >   	pushf  
> 
> This belongs to the previous patch, it is part of the host changes.
right, will do.

> 
> > diff --git a/arch/x86/kvm/vmx/vmx.c b/arch/x86/kvm/vmx/vmx.c
> > index 4e7b36081b76..6719c598fa5f 100644
> > --- a/arch/x86/kvm/vmx/vmx.c
> > +++ b/arch/x86/kvm/vmx/vmx.c
> > @@ -7331,10 +7331,15 @@ static noinstr void vmx_vcpu_enter_exit(struct
> > kvm_vcpu *vcpu, if ((u16)vmx->exit_reason.basic ==
> > EXIT_REASON_EXCEPTION_NMI && is_nmi(vmx_get_intr_info(vcpu))) {
> >   		kvm_before_interrupt(vcpu, KVM_HANDLING_NMI);
> > -		if (cpu_feature_enabled(X86_FEATURE_FRED))
> > -			fred_entry_from_kvm(EVENT_TYPE_NMI,
> > NMI_VECTOR, 0);
> > -		else
> > +		if (cpu_feature_enabled(X86_FEATURE_FRED)) {
> > +			unsigned long edata = 0;
> > +
> > +			if
> > (cpu_feature_enabled(X86_FEATURE_NMI_SOURCE))
> > +				edata = vmx_get_exit_qual(vcpu);
> > +			fred_entry_from_kvm(EVENT_TYPE_NMI,
> > NMI_VECTOR, edata);  
> 
> Simply do fred_entry_from_kvm(EVENT_TYPE_NMI, NMI_VECTOR, 
> vmx_get_exit_qual(vcpu))?
I don't have strong preference but having a local variable improves
readability IMHO.

> > +		} else {
> >   			vmx_do_nmi_irqoff();
> > +		}
> >   		kvm_after_interrupt(vcpu);
> >   	}
> >     
> 


Thanks,

Jacob

  reply	other threads:[~2024-07-01 15:40 UTC|newest]

Thread overview: 33+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2024-06-28 20:18 [PATCH v3 00/11] Add support for NMI source reporting Jacob Pan
2024-06-28 20:18 ` [PATCH v3 01/11] x86/irq: Add enumeration of NMI source reporting CPU feature Jacob Pan
2024-06-28 20:18 ` [PATCH v3 02/11] x86/irq: Define NMI source vectors Jacob Pan
2024-06-29 18:32   ` Xin Li
2024-07-01 17:16     ` Jacob Pan
2024-06-28 20:18 ` [PATCH v3 03/11] x86/irq: Extend NMI handler registration interface to include source Jacob Pan
2024-06-28 20:18 ` [PATCH v3 04/11] x86/irq: Factor out common NMI handling code Jacob Pan
2024-06-29  0:31   ` Xin Li
2024-07-03 23:10     ` Jacob Pan
2024-06-28 20:18 ` [PATCH v3 05/11] x86/irq: Process nmi sources in NMI handler Jacob Pan
2024-06-29  3:39   ` Xin Li
2024-07-07  3:48     ` Jacob Pan
2024-07-01 14:31   ` Nikolay Borisov
2024-07-01 15:36     ` Jacob Pan
2024-06-28 20:18 ` [PATCH v3 06/11] KVM: VMX: Expand FRED kvm entry with event data Jacob Pan
2024-06-29  4:01   ` Xin Li
2024-07-01 15:39     ` Jacob Pan
2024-06-28 20:18 ` [PATCH v3 07/11] KVM: VMX: Handle NMI Source report in VM exit Jacob Pan
2024-06-29  4:07   ` Xin Li
2024-07-01 15:45     ` Jacob Pan [this message]
2024-07-01 17:03       ` Xin Li
2024-07-01 18:00         ` Jacob Pan
2024-06-30 13:04   ` Zeng Guang
2024-07-01 15:46     ` Jacob Pan
2024-06-28 20:18 ` [PATCH v3 08/11] perf/x86: Enable NMI source reporting for perfmon Jacob Pan
2024-07-04 14:44   ` Liang, Kan
2024-07-06 22:49     ` Jacob Pan
2024-06-28 20:18 ` [PATCH v3 09/11] x86/irq: Enable NMI source on IPIs delivered as NMI Jacob Pan
2024-06-28 20:18 ` [PATCH v3 10/11] x86/irq: Move __prepare_ICR to x86 common header Jacob Pan
2024-06-28 20:18 ` [PATCH v3 11/11] KVM: X86: Use common code for PV IPIs in linux guest Jacob Pan
2024-06-29 18:38   ` Xin Li
2024-07-01 16:38     ` Jacob Pan
2024-07-01 17:13       ` Xin Li

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=20240701084558.1620584f@jacob-builder \
    --to=jacob.jun.pan@linux.intel.com \
    --cc=acme@kernel.org \
    --cc=andi.kleen@intel.com \
    --cc=bp@alien8.de \
    --cc=dave.hansen@intel.com \
    --cc=guang.zeng@intel.com \
    --cc=hpa@zytor.com \
    --cc=kan.liang@linux.intel.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-perf-users@vger.kernel.org \
    --cc=luto@kernel.org \
    --cc=mingo@redhat.com \
    --cc=pbonzini@redhat.com \
    --cc=peterz@infradead.org \
    --cc=seanjc@google.com \
    --cc=sohil.mehta@intel.com \
    --cc=tglx@linutronix.de \
    --cc=tony.luck@intel.com \
    --cc=x86@kernel.org \
    --cc=xin3.li@intel.com \
    --cc=xin@zytor.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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.