Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) client-ip=2620:137:e000::1:20;
Message-ID: <f2467d69-882b-3439-b082-bcaf591a9892@intel.com>
Date:   Thu, 18 May 2023 17:43:14 -0700
MIME-Version: 1.0
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:102.0) Gecko/20100101
 Thunderbird/102.10.0
Subject: Re: [PATCH 1/2] x86/numa: Introduce numa_fill_memblks()
Content-Language: en-US
To:     Alison Schofield <alison.schofield@intel.com>
Cc:     "Rafael J. Wysocki" <rafael@kernel.org>,
        Len Brown <lenb@kernel.org>,
        Dan Williams <dan.j.williams@intel.com>,
        Thomas Gleixner <tglx@linutronix.de>,
        Ingo Molnar <mingo@redhat.com>, Borislav Petkov <bp@alien8.de>,
        Dave Hansen <dave.hansen@linux.intel.com>,
        "H. Peter Anvin" <hpa@zytor.com>,
        Andy Lutomirski <luto@kernel.org>,
        Peter Zijlstra <peterz@infradead.org>,
        Andrew Morton <akpm@linux-foundation.org>,
        Jonathan Cameron <Jonathan.Cameron@huawei.com>,
        Dave Jiang <dave.jiang@intel.com>, x86@kernel.org,
        linux-cxl@vger.kernel.org, linux-acpi@vger.kernel.org,
        linux-kernel@vger.kernel.org
References: <cover.1684448934.git.alison.schofield@intel.com>
 <e365f4dfa7fa974118eb4e59aebc7cc423cf19a1.1684448934.git.alison.schofield@intel.com>
 <8dc725c8-613a-b51b-6cc1-80d2275ca130@intel.com>
 <ZGbCG4gRGow0VCmQ@aschofie-mobl2>
From:   Dave Hansen <dave.hansen@intel.com>
In-Reply-To: <ZGbCG4gRGow0VCmQ@aschofie-mobl2>
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 7bit
Precedence: bulk

On 5/18/23 17:26, Alison Schofield wrote:
> On Thu, May 18, 2023 at 05:08:16PM -0700, Dave Hansen wrote:
>> On 5/18/23 17:04, alison.schofield@intel.com wrote:
>>> The initial use case is the ACPI driver that needs to extend
>>> SRAT defined proximity domains to an entire CXL CFMWS Window[1].
>>
>> Dumb question time: Why didn't the SRAT just cover this sucker in the
>> first place?  Are we fixing up a BIOS bug or is there a legitimate
>> reason that the SRAT didn't cover it up front?
>>
> There is no requirement that the BIOS describe (in the SRAT) all the
> HPA assigned to a CFMWS Window. The HPA range may not actually map to
> any memory at boot time. It can be persistent capacity or may be there
> to enable hot-plug. IIUC BIOS can pick and choose and define volatile
> regions wherever it pleases.

I understand that it _can_ do this.  I'm trying to get to the reasoning
of why.

Is this essentially so that the physical address space doesn't have to
be *committed* to a single use up front?  For RAM, I guess this wasn't a
problem because there was only a finite amount of RAM that could get
hotplugged into a single node.

But with these fancy schmancy new devices, it's really hard to figure
out how much space will show up and what performance it will have until
you actually start poking at it.  The firmware wasn't _quite_ sure how
it wanted to burn the physical address space at the time the SRAT was
created.  But, now it knows, and this is handling the case where the
firmware only expands an adjacent chunk of physical address space.

Close?