public inbox for linux-kernel@vger.kernel.org
 help / color / mirror / Atom feed
From: Sean Christopherson <seanjc@google.com>
To: Jacob Pan <jacob.jun.pan@linux.intel.com>
Cc: X86 Kernel <x86@kernel.org>, 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>,
	 Nikolay Borisov <nik.borisov@suse.com>,
	Sohil Mehta <sohil.mehta@intel.com>
Subject: Re: [PATCH v4 09/11] x86/irq: Enable NMI source on IPIs delivered as NMI
Date: Fri, 16 Aug 2024 06:45:31 -0700	[thread overview]
Message-ID: <Zr9X-08zsOKFlvkB@google.com> (raw)
In-Reply-To: <20240709143906.1040477-10-jacob.jun.pan@linux.intel.com>

On Tue, Jul 09, 2024, Jacob Pan wrote:
> Program designated NMI source vectors for all NMI delivered IPIs
> such that their handlers can be selectively invoked.
> 
> Signed-off-by: Jacob Pan <jacob.jun.pan@linux.intel.com>
> ---
> v4: Enhance comments, no functional changes (Li Xin)
> ---
>  arch/x86/include/asm/irq_vectors.h | 10 ++++++++++
>  arch/x86/kernel/apic/hw_nmi.c      |  3 ++-
>  arch/x86/kernel/apic/ipi.c         |  4 ++--
>  arch/x86/kernel/apic/local.h       | 18 ++++++++++++------
>  arch/x86/kernel/cpu/mce/inject.c   |  2 +-
>  arch/x86/kernel/kgdb.c             |  2 +-
>  arch/x86/kernel/nmi_selftest.c     |  2 +-
>  arch/x86/kernel/reboot.c           |  2 +-
>  arch/x86/kernel/smp.c              |  2 +-
>  9 files changed, 31 insertions(+), 14 deletions(-)
> 
> diff --git a/arch/x86/include/asm/irq_vectors.h b/arch/x86/include/asm/irq_vectors.h
> index 4f767c3940d6..9b7241e7faa3 100644
> --- a/arch/x86/include/asm/irq_vectors.h
> +++ b/arch/x86/include/asm/irq_vectors.h
> @@ -135,6 +135,16 @@
>  #define NMI_SOURCE_VEC_IPI_TEST		8	/* For remote and local IPIs */
>  #define NR_NMI_SOURCE_VECTORS		9
>  
> +/*
> + * When programming the local APIC, IDT NMI vector and NMI-source vector
> + * are encoded in a single 32 bit variable. The top 16 bits contain
> + * the NMI-source vector and the bottom 16 bits contain NMI_VECTOR (2)
> + * The top 16 bits are always zero when NMI-source reporting feature
> + * is not enabled or the caller does not use NMI-source reporting.

This is *extremely* misleading, bordering on being an outright lie.  The vectors
are not encoded in a single 32-bit variable when programming the _local APIC_,
that is 100% an arbitrary software construct.  The actually write to APIC.ICR
morphs bits 15:0 into the TYPE, and the bits 31:16 into the VECTOR.

> + */
> +#define NMI_VECTOR_WITH_SOURCE(src)	(NMI_VECTOR | (src << 16))

Why require callers to use NMI_VECTOR_WITH_SOURCE instead of having macros to
directly encode each source NMI, a la APIC_PERF_NMI?

To me, this:

				__apic_send_IPI(cpu, NMI_VECTOR_WITH_SOURCE(NMI_SOURCE_VEC_IPI_SMP_STOP));

is *way* harder to read/parse than:

				__apic_send_IPI(cpu, NMI_VECTOR_SMP_STOP);

especially since that first one blasts way past 80 chars (yeah, I know 80 is now
a soft limit, but it's still nice to keep line lengths short when possible).

> +#define NMI_SOURCE_VEC_MASK		GENMASK(15, 0)

IMO, this is an absolutely awful encoding scheme.  Vectors are 8-bit values, so
why on earth use 16 bits?  And @vector is passed along as a _signed_ integer,
which means 32-bit kernels could end up observing negative values, which probably
isn't problematic in practice, but it's unnecessarily confusing.

All this FRED stuff is hard enough to follow given the specs have been rolled out
piecemeal (someone at Intel must get paid based on how many specs they publish),
using a software-defined scheme when FRED is already overloading a decades old
hardware-defined encoding is just mean.

Why not encode APIC_DM_NMI straightaway?  You're already making it a hard
requirement that the backend (__prepare_ICR()) be able to handle a @vector that
has bits 31:8!=0.  I don't see how the above scheme provides any value.

Side topic, APIC_DM_FIXED_MASK should really be APIC_DM_MASK, that "FIXED" part
is completely wrong.

E.g.

static inline unsigned int __prepare_ICR(unsigned int shortcut, int vector,
					 unsigned int dest)
{
	unsigned int icr = shortcut | dest;

	/*
	 * Callers are allowed to encode the NMI delivery mode directly, which
	 * allows using the vector field to provide the NMI source (FRED only).
	 */
	if ((vector & APIC_DM_MASK) == APIC_DM_NMI) {
		icr |= vector;

		/*
		 * Pre-FRED, the actual vector is ignored for NMIs, but zero it
		 * if NMI source reporting is unsupported so as not to risk
		 * breakage on misbehaving hardware/hypervisors.
		 */
		if (!cpu_feature_enabled(X86_FEATURE_NMI_SOURCE))
			icr &= ~APIC_VECTOR_MASK;
	} else if (vector == NMI_VECTOR) {
		icr |= APIC_DM_NMI;
	} else {
		icr |= APIC_DM_FIXED | vector;
	}

	return icr;
}

and then NMI_VECTOR_SMP_STOP would be (APIC_DM_NMI | NMI_SOURCE_VEC_IPI_SMP_STOP).

  reply	other threads:[~2024-08-16 13:45 UTC|newest]

Thread overview: 17+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2024-07-09 14:38 [PATCH v4 00/11] Add support for NMI-source reporting Jacob Pan
2024-07-09 14:38 ` [PATCH v4 01/11] x86/irq: Add enumeration of NMI source reporting CPU feature Jacob Pan
2024-07-09 14:38 ` [PATCH v4 02/11] x86/irq: Define NMI source vectors Jacob Pan
2024-07-09 14:38 ` [PATCH v4 03/11] x86/irq: Extend NMI handler registration interface to include source Jacob Pan
2024-07-09 14:38 ` [PATCH v4 04/11] x86/irq: Factor out common NMI handling code Jacob Pan
2024-07-09 14:39 ` [PATCH v4 05/11] x86/irq: Process nmi sources in NMI handler Jacob Pan
2024-07-09 14:39 ` [PATCH v4 06/11] KVM: VMX: Expand FRED kvm entry with event data Jacob Pan
2024-08-16 14:12   ` Sean Christopherson
2024-07-09 14:39 ` [PATCH v4 07/11] KVM: VMX: Handle NMI Source report in VM exit Jacob Pan
2024-08-16 14:05   ` Sean Christopherson
2024-07-09 14:39 ` [PATCH v4 08/11] perf/x86: Enable NMI source reporting for perfmon Jacob Pan
2024-07-09 15:04   ` Liang, Kan
2024-07-09 14:39 ` [PATCH v4 09/11] x86/irq: Enable NMI source on IPIs delivered as NMI Jacob Pan
2024-08-16 13:45   ` Sean Christopherson [this message]
2024-07-09 14:39 ` [PATCH v4 10/11] x86/irq: Move __prepare_ICR to x86 common header Jacob Pan
2024-07-09 14:39 ` [PATCH v4 11/11] KVM: X86: Use common code for PV IPIs in linux guest Jacob Pan
2024-08-16 13:52   ` 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=Zr9X-08zsOKFlvkB@google.com \
    --to=seanjc@google.com \
    --cc=acme@kernel.org \
    --cc=andi.kleen@intel.com \
    --cc=bp@alien8.de \
    --cc=dave.hansen@intel.com \
    --cc=hpa@zytor.com \
    --cc=jacob.jun.pan@linux.intel.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=nik.borisov@suse.com \
    --cc=pbonzini@redhat.com \
    --cc=peterz@infradead.org \
    --cc=sohil.mehta@intel.com \
    --cc=tglx@linutronix.de \
    --cc=tony.luck@intel.com \
    --cc=x86@kernel.org \
    --cc=xin3.li@intel.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