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

[Huang, Kai]

On Wed, 2026-03-04 at 19:29 -0500, Gregory Price wrote:
> On Thu, Mar 05, 2026 at 12:14:52AM +0000, Huang, Kai wrote:
> > On Wed, 2026-03-04 at 18:56 -0500, Gregory Price wrote:
> > > 
> > > 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.
> 
> Well, I'm mostly confused why there are CEDT entries for hardware that
> presumably isn't even there - unless this platform is reserving space
> for future hotplug.  
> 

I think this should be the case.

> Just want to make sure we're not adjusting for
> strange firmware behavior.

How to check whether it is "strange"?

I dumped the ACPI table on that platform, and what I can see is there's CEDT
table which contains couple of "[CXL Host Bridge Structure]" and "[CXL Fixed
Memory Window Structure]".

I pasted one for each of them here FYI:

[024h 0036 001h]               Subtable Type : 00 [CXL Host Bridge
Structure]
[025h 0037 001h]                    Reserved : 00
[026h 0038 002h]                      Length : 0020
[028h 0040 004h]      Associated host bridge : 00000003
[02Ch 0044 004h]       Specification version : 00000001
[030h 0048 004h]                    Reserved : 00000000
[034h 0052 008h]               Register base : 00000000997F0000
[03Ch 0060 008h]             Register length : 0000000000010000

[124h 0292 001h]               Subtable Type : 01 [CXL Fixed Memory Window
Structure]
[125h 0293 001h]                    Reserved : 00
[126h 0294 002h]                      Length : 0034
[128h 0296 004h]                    Reserved : 00000000
[12Ch 0300 008h]         Window base address : 0000002080000000
[134h 0308 008h]                 Window size : 0000017B00000000
[13Ch 0316 001h]    Interleave Members (2^n) : 02
[13Dh 0317 001h]       Interleave Arithmetic : 01
[13Eh 0318 002h]                    Reserved : 0000
[140h 0320 004h]                 Granularity : 00000000
[144h 0324 002h]                Restrictions : 0006
[146h 0326 002h]                       QtgId : 0000
[148h 0328 004h]                First Target : 00000003
[14Ch 0332 004h]                 Next Target : 00000023
[150h 0336 004h]                 Next Target : 00000043
[154h 0340 004h]                 Next Target : 00000053


> 
> The only platform we've seen this behavior on previously was QEMU, but
> that was because it never emitted SRAT, 
> 

My machine has a legitimate SRAT.  The kernel detects it has 4 nodes with
256 CPUs + 256G memory.

> so i was wondering if there's
> odd firmware behavior going on (emitting CEDTs when it shouldn't) before
> we jump to dropping nodes that would have otherwise have been present
> on existing systems who might have compiled CXL_ACPI out.

I don't know how to check whether the BIOS "should" or "should not" generate
CEDT.  I can check my machine if you let me know what to check specifically?

> 
> You are taking something away by nature of compiling something out by
> default that was previously not compiled out by default.

Yeah, and it is due to "there's a cost" if we don't compile out by default.

Hope that justifies?