public inbox for linux-kernel@vger.kernel.org
 help / color / mirror / Atom feed
From: Gregory Price <gourry@gourry.net>
To: Dan Williams <dan.j.williams@intel.com>
Cc: "Fabio M. De Francesco" <fabio.m.de.francesco@linux.intel.com>,
	Davidlohr Bueso <dave@stgolabs.net>,
	Jonathan Cameron <jonathan.cameron@huawei.com>,
	Dave Jiang <dave.jiang@intel.com>,
	Alison Schofield <alison.schofield@intel.com>,
	Vishal Verma <vishal.l.verma@intel.com>,
	Ira Weiny <ira.weiny@intel.com>,
	Robert Richter <rrichter@amd.com>,
	ming.li@zohomail.com, linux-kernel@vger.kernel.org,
	linux-cxl@vger.kernel.org
Subject: Re: [PATCH 2/4 v2] cxl/core: Add helpers to detect Low memory Holes on x86
Date: Tue, 1 Apr 2025 17:40:50 -0400	[thread overview]
Message-ID: <Z-xdYvxD6yz3fMiE@gourry-fedora-PF4VCD3F> (raw)
In-Reply-To: <67ec4d61c3fd6_288d2947b@dwillia2-xfh.jf.intel.com.notmuch>

On Tue, Apr 01, 2025 at 01:32:33PM -0700, Dan Williams wrote:
> Gregory Price wrote:
> > Is there a reason not to handle more than just LMH's in this set?
> 
> This discussion was referenced recently on an IM and I wanted to share
> my response to it:
> 
> The rules for when to apply this memory hole quirk are explicit and
> suitable to add to the CXL specification. I want the same standard for
> any other quirk and ideally some proof-of-work to get that quirk
> recognized by the specification. Otherwise, I worry that generalizing
> for all the possible ways that platform BIOS tries to be clever means we
> end up with something that has no rules.
>
> The spec is there to allow software to delineate valid configurations vs
> mistakes, and this slow drip of "Linux does not understand this platform
> configuration" is a spec gap.

Note: I've since come around to understand the whole ecosystem a bit
      better since i wrote this response. I don't know that it's needed.


Some of the explanation of this patch series is a bit confusing. It
justifies itself by saying CFMWS don't intersect memory holes and that
endpoint decoders have to be 256MB aligned.

/*
 * 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.
 */

But per the spec, CFMWS is also aligned to be aligned to 256MB.

Shouldn't the platform work around memory holes to generate multiple
CFMWS for the entire capacity, and then use multiple endpoint decoders
(1 per CFMWS) to map the capacity accordingly?

(Also, I still don't understand the oracle value of <4GB address range.
 It seems like if this is some quirk of SPA vs HPA alignment, then it
 can hold for *all* ocurrances, not just stuff below 4GB)

~Gregory

  reply	other threads:[~2025-04-01 21:40 UTC|newest]

Thread overview: 12+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2025-01-14 20:32 [PATCH 0/4 v2] cxl/core: Enable Region creation on x86 with Low Mem Hole Fabio M. De Francesco
2025-01-14 20:32 ` [PATCH 1/4 v2] cxl/core: Change match_*_by_range() calling convention Fabio M. De Francesco
2025-01-14 20:32 ` [PATCH 2/4 v2] cxl/core: Add helpers to detect Low memory Holes on x86 Fabio M. De Francesco
2025-01-15  2:23   ` Gregory Price
2025-01-21 20:35     ` Fabio M. De Francesco
2025-04-01 20:32     ` Dan Williams
2025-04-01 21:40       ` Gregory Price [this message]
2025-04-01 23:34         ` Dan Williams
2025-04-02  5:05           ` Gregory Price
2025-04-02 14:20             ` Ira Weiny
2025-01-14 20:32 ` [PATCH 3/4 v2] cxl/core: Enable Region creation on x86 with Low Memory Hole Fabio M. De Francesco
2025-01-14 20:32 ` [PATCH 4/4 v2] cxl/test: Simulate an x86 Low Memory Hole for tests Fabio M. De Francesco

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=Z-xdYvxD6yz3fMiE@gourry-fedora-PF4VCD3F \
    --to=gourry@gourry.net \
    --cc=alison.schofield@intel.com \
    --cc=dan.j.williams@intel.com \
    --cc=dave.jiang@intel.com \
    --cc=dave@stgolabs.net \
    --cc=fabio.m.de.francesco@linux.intel.com \
    --cc=ira.weiny@intel.com \
    --cc=jonathan.cameron@huawei.com \
    --cc=linux-cxl@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=ming.li@zohomail.com \
    --cc=rrichter@amd.com \
    --cc=vishal.l.verma@intel.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox