[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20240530105244.46090c04@jacob-builder>
Date: Thu, 30 May 2024 10:52:44 -0700
From: Jacob Pan <jacob.jun.pan@...ux.intel.com>
To: "H. Peter Anvin" <hpa@...or.com>
Cc: X86 Kernel <x86@...nel.org>, LKML <linux-kernel@...r.kernel.org>, Thomas
Gleixner <tglx@...utronix.de>, Dave Hansen <dave.hansen@...el.com>, Ingo
Molnar <mingo@...hat.com>, Borislav Petkov <bp@...en8.de>,
linux-perf-users@...r.kernel.org, Peter Zijlstra <peterz@...radead.org>,
Andi Kleen <andi.kleen@...el.com>, Xin Li <xin3.li@...el.com>,
jacob.jun.pan@...ux.intel.com
Subject: Re: [PATCH 4/6] x86/irq: Process nmi sources in NMI handler
Hi Peter,
On Wed, 29 May 2024 14:12:19 -0700, "H. Peter Anvin" <hpa@...or.com> wrote:
> On 5/29/24 13:33, Jacob Pan wrote:
> > +
> > + rcu_read_lock();
> > + /* Bit 0 is for unknown NMI sources, skip it. */
> > + for_each_set_bit_from(vec, &source_bitmask,
> > NR_NMI_SOURCE_VECTORS) {
> > + a = rcu_dereference(nmiaction_src_table[vec]);
> > + if (!a) {
> > + pr_warn_ratelimited("NMI received %d no
> > handler", vec);
> > + continue;
> > + }
>
> In this case, you should assume some chipset hardware or VMM is giving
> you garbage in the event bitmask, and treat it as if bit 0 were set.
>
right, should return 0 and poll all handlers.
Thanks,
Jacob
Powered by blists - more mailing lists