linux-kernel - Re: [PATCH v6 4/9] x86/nmi: Assign and register NMI-source vectors

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <9950dc5a-05ab-4a7c-a4e8-34012ef98549@zytor.com>
Date: Tue, 3 Jun 2025 09:34:27 -0700
From: Xin Li <xin@...or.com>
To: Sohil Mehta <sohil.mehta@...el.com>, x86@...nel.org,
        linux-kernel@...r.kernel.org
Cc: "H . Peter Anvin" <hpa@...or.com>, Andy Lutomirski <luto@...nel.org>,
        Thomas Gleixner <tglx@...utronix.de>, Ingo Molnar <mingo@...hat.com>,
        Borislav Petkov <bp@...en8.de>,
        Dave Hansen <dave.hansen@...ux.intel.com>,
        Peter Zijlstra <peterz@...radead.org>,
        Sean Christopherson <seanjc@...gle.com>,
        Adrian Hunter <adrian.hunter@...el.com>,
        Kan Liang <kan.liang@...ux.intel.com>, Tony Luck <tony.luck@...el.com>,
        Zhang Rui <rui.zhang@...el.com>, Steven Rostedt <rostedt@...dmis.org>,
        Andrew Cooper <andrew.cooper3@...rix.com>,
        "Kirill A . Shutemov" <kirill.shutemov@...ux.intel.com>,
        Jacob Pan <jacob.pan@...ux.microsoft.com>,
        Andi Kleen <ak@...ux.intel.com>, Kai Huang <kai.huang@...el.com>,
        Sandipan Das <sandipan.das@....com>, linux-perf-users@...r.kernel.org,
        linux-edac@...r.kernel.org, kvm@...r.kernel.org,
        linux-pm@...r.kernel.org, linux-trace-kernel@...r.kernel.org
Subject: Re: [PATCH v6 4/9] x86/nmi: Assign and register NMI-source vectors

On 5/13/2025 1:37 PM, Sohil Mehta wrote:
> Prior to NMI-source support, the vector information was ignored by the
> hardware while delivering NMIs. With NMI-source, the architecture
> currently supports a 16-bit source bitmap to identify the source of the
> NMI. Upon receiving an NMI, this bitmap is delivered as part of the FRED
> event delivery mechanism to the kernel.
> 
> Assign a vector space of 0-15 that is specific to NMI-source and
> independent of the IDT vector space of 0-255. Being a bitmap, the
> NMI-source vectors do not have any inherent priority associated with
> them. The order of executing the NMI handlers is up to the kernel.

I'm thinking should we mention that the bitmap could be extended more
than 16 bits in future?  Or we just don't emphasize 16-bit or 0~15?


> 
> Existing NMI handling already has a priority mechanism for the NMI
> handlers, with CPU-specific (NMI_LOCAL) handlers executed first,
> followed by platform NMI handlers and unknown NMI (NMI_UNKNOWN) handlers
> being last. Within each of these NMI types, the handlers registered with
> NMI_FLAG_FIRST are given priority.
> 
> NMI-source follows the same priority scheme to avoid unnecessary
> complexity. Therefore, the NMI-source vectors are assigned arbitrarily,
> except for vectors 0 and 2.
> 
> Vector 0 is set by the hardware whenever a source vector was not used
> while generating an NMI or the originator could not be reliably
> identified. Do not assign it to any handler.
> 
> Vector 2 is reserved for external NMIs corresponding to Local APIC -
> LINT1. Some third-party chipsets may send NMI messages with a hardcoded
> vector of 2, which would result in vector 2 being set in the NMI-source
> bitmap. To avoid confusion, do not assign vector 2 to any handler.
> 
> NMI-source vectors are only assigned for NMI_LOCAL type handlers.
> Platform NMI handlers have a single handler registered per type. They
> don't need additional source information to differentiate among them.
> 
> Use the assigned vectors to register the respective NMI handlers. Warn
> if the vector values are unexpected.
> 
> A couple of NMI handlers, such as the microcode rendezvous and the crash
> reboot, do not use the typical NMI registration interface. Leave them
> as-is for now.
> 
> Originally-by: Jacob Pan <jacob.jun.pan@...ux.intel.com>
> Signed-off-by: Sohil Mehta <sohil.mehta@...el.com>

Reviewed-by: Xin Li (Intel) <xin@...or.com>