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;
Date:   Thu, 18 May 2023 17:26:03 -0700
From:   Alison Schofield <alison.schofield@intel.com>
To:     Dave Hansen <dave.hansen@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
Subject: Re: [PATCH 1/2] x86/numa: Introduce numa_fill_memblks()
Message-ID: <ZGbCG4gRGow0VCmQ@aschofie-mobl2>
References: <cover.1684448934.git.alison.schofield@intel.com>
 <e365f4dfa7fa974118eb4e59aebc7cc423cf19a1.1684448934.git.alison.schofield@intel.com>
 <8dc725c8-613a-b51b-6cc1-80d2275ca130@intel.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <8dc725c8-613a-b51b-6cc1-80d2275ca130@intel.com>
Precedence: bulk

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.

So, no we're not fixing up a BIOS bug, nor doing a BIOS sanity check.