Re: [PATCH] ACPI: NUMA: Only parse CFMWS at boot when CXL_ACPI is on

["Huang, Kai" <kai.huang@intel.com>]

On Wed, 2026-03-04 at 18:56 -0500, Gregory Price wrote:
> On Wed, Mar 04, 2026 at 03:20:11PM -0800, Alison Schofield wrote:
> > On Wed, Mar 04, 2026 at 05:33:26PM -0500, Gregory Price wrote:
> > > On Thu, Mar 05, 2026 at 10:33:42AM +1300, Kai Huang wrote:
> > > > Increasing the 'nr_node_ids' has side effects.  For instance, it is
> > > > widely used by the kernel for "highest possible NUMA node" based memory
> > > > allocations.  It also impacts userspace ABIs, e.g., some NUMA memory
> > > > related system calls such as 'get_mempolicy' which requires 'maxnode'
> > > > not being smaller than the 'nr_node_ids'.
> > > > 
> > 
> > > 
> > > Is this a Linux issue or a Firmware issue?
> > 
> > IIUC BIOS creates the CEDT based on the hardware it 'sees' as present.
> > 
> > This patch is describing the case (weird as it seems to me) where we
> > then boot a system with ACPI and NUMA enabled but CXL_ACPI disabled.
> > 
> > So, I don't think we can blame BIOS.
> > 
> > > 
> > > Is GNR exporting more CFMWS than it should?
> > Not sure of any limits on flavors of CFMWS's a BIOS can offer.
> > If BIOS can carve out a window, it can create a CFMWS.
> > Not clear how that matters to the issue.
> > 
> > > 
> > > Is your SRAT missing entries for CFMWS that are otherwise present?
> > > 
> > > Are the CFMWS empty? (is that even valid)
> > 
> > Why this line of questioning ;)  I see the problem as a bit simpler.
> > We have other code that tells us if the CFMWS's are valid, etc, but
> > the point here is, we are not going to use these CFMWS's so stop
> > the parse as early as possible, like right here as Kai has done.
> > 
> 
> Mostly i'm wondering if this issue should be dealt with in the acpi code
> or if the issue is that we just don't want to figure out how to
> lazy-create these things instead of always creating them at __init.
> 
> it does seem rational to build out support for CEDT entries if CXL_ACPI
> is built out, but this also means you can't otherwise load modules that
> would have made use of this information.

Besides CXL_ACPI, is there any other module(s) that uses this information
for these CXL memory regions?

> 
> This basically says if specifically CXL_ACPI is built out, the NUMA
> structure is forever lost - even though it's accurately described by
> BIOS.  
> 

The normal NUMA info described in SRAT is still there.  It only avoids
detecting CFMWS, which doesn't provide any NUMA info actually -- that's why
kernel assigns a 'faked' NUMA node for each of them.

So we are not losing anything AFAICT.