[<prev] [next>] [<thread-prev] [day] [month] [year] [list]
Message-ID: <2871231.lGaqSPkdTl@fdefranc-mobl3>
Date: Tue, 21 Jan 2025 21:35:57 +0100
From: "Fabio M. De Francesco" <fabio.m.de.francesco@...ux.intel.com>
To: Gregory Price <gourry@...rry.net>
Cc: Davidlohr Bueso <dave@...olabs.net>,
Jonathan Cameron <jonathan.cameron@...wei.com>,
Dave Jiang <dave.jiang@...el.com>,
Alison Schofield <alison.schofield@...el.com>,
Vishal Verma <vishal.l.verma@...el.com>, Ira Weiny <ira.weiny@...el.com>,
Dan Williams <dan.j.williams@...el.com>, Robert Richter <rrichter@....com>,
ming.li@...omail.com, linux-kernel@...r.kernel.org, linux-cxl@...r.kernel.org
Subject:
Re: [PATCH 2/4 v2] cxl/core: Add helpers to detect Low memory Holes on x86
On Wednesday, January 15, 2025 3:23:36 AM GMT+1 Gregory Price wrote:
> On Tue, Jan 14, 2025 at 09:32:54PM +0100, Fabio M. De Francesco wrote:
> > +/*
> > + * Match CXL Root and Endpoint Decoders by comparing SPA and HPA ranges.
> > + *
> > + * On x86, CFMWS ranges never intersect memory holes while endpoint decoders
> > + * HPA range sizes are always guaranteed aligned to NIW * 256MB; therefore,
> > + * the given endpoint decoder HPA range size is always expected aligned and
> > + * also larger than that of the matching root decoder. If there are LMH's,
> > + * the root decoder range end is always less than SZ_4G.
> > + */
>
> Is there any reason to limit this memory-hole handling to only low
> memory holes?
>
No I don't see any special reasons to limit this to only low memory holes.
It's just that I didn't know about others.
>
> I have observed systems where the following memory
> hole situation occurs:
>
> (example, not exact sizes)
> CFMW1: [ 0xc0000000 - 0xdfffffff ] 512MB range
> Reserved [ 0xe0000000 - 0xffffffff ] 512MB range
> CFMW2: [ 0x100000000 - 0x15fffffff ] 1.5GB range
>
> 2 CXL Memory Devices w/ 1GB capacity each (again, an example).
>
> Note that 1 device has its capacity split across the hole, but
> if the devices are interleaved then both devices have their capacity
> split across the hole.
>
> It seems with some mild modification, this patch set could be
> re-used to handle this memory hole scenario as well
> (w/ addr translation - Robert's patch set)
>
> Is there a reason not to handle more than just LMH's in this set?
>
> (I may try to hack this up on my test system and report back.)
>
I'd appreciate it if you want to report back.
Thank you,
Fabio
>
> ~Gregory
>
Powered by blists - more mailing lists