[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <7e0097d6-a542-4778-913b-3c374d36f5c3@intel.com>
Date: Thu, 27 Jun 2024 16:20:45 -0700
From: Sohil Mehta <sohil.mehta@...el.com>
To: Jacob Pan <jacob.jun.pan@...ux.intel.com>
CC: X86 Kernel <x86@...nel.org>, LKML <linux-kernel@...r.kernel.org>, "Thomas
Gleixner" <tglx@...utronix.de>, Dave Hansen <dave.hansen@...el.com>, "H.
Peter Anvin" <hpa@...or.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>
Subject: Re: [PATCH v2 1/6] x86/irq: Add enumeration of NMI source reporting
CPU feature
On 6/27/2024 3:23 PM, Jacob Pan wrote:
> I don't think this is true. For a simplified example:
> cpuid_deps has the following feature-depends pairs.
> [1, 3]
> [2, 3]
> now, do_clear_cpu_cap(c, 2)
>
> Before the loop below __set_bit(feature, disable), bit 2 is set.
>
> Since there is no other features depend on 2, the loop below will not clear
> any other features. no?
>
You are right. The table-scan only processes the dependencies of the
feature that is being disabled but not of any other features that might
have a missing dependency.
Maybe it might be useful to have a common function that scans through
all the dependencies at boot. It would mainly help detect hardware (or
VMM) inconsistencies sooner than later.
Powered by blists - more mailing lists