All of lore.kernel.org
 help / color / mirror / Atom feed
From: Ira Weiny <ira.weiny@intel.com>
To: Gregory Price <gourry@gourry.net>,
	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: Wed, 2 Apr 2025 09:20:02 -0500	[thread overview]
Message-ID: <67ed4792b475_7190f294ce@iweiny-mobl.notmuch> (raw)
In-Reply-To: <Z-zFrBqZHc4UWvMb@gourry-fedora-PF4VCD3F>

Gregory Price wrote:
> On Tue, Apr 01, 2025 at 04:34:44PM -0700, Dan Williams wrote:
> > The platforms with this condition want to support CXL mapped starting at
> > zero *and* the typical/historical PCI MMIO space in low memory (for
> > those PCI devices that do not support 64-bit addressing). If the CFMWS
> > blindly followed the 256MB*NIW constraint the CXL window would overlap
> > the MMIO space. So the choices are:
> > 
> 
> If I'm understanding everything correctly, then I think this is intended
> to work only when EFI_MEMORY_SP is *not* set for these particular CXL
> devices - so it comes up as memory in early boot and we're just trying
> to wire up all the bits to let the driver manage it accordingly?

That is how I understand things.  But I'm just jumping in just to review
the patches so I could be wrong...

Ira

> 
> If that's the case, then ignore me, i'm just bikeshedding at this point.
> 
> I can't imagine a system where the memory at 0x0-4GB is intended to come
> up as EFI_MEMORY_SP, so I hope no one ever tries this :D
> 
> > > (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)
> > 
> > The goal is to get platform vendors to define the rules so that an OS
> > has a reasonable expectation to know what is a valid vs invalid
> > configuration. A hole above 4GB has no reason to exist, there is no
> > resource conflict like PCI MMIO that explains why typical spec
> > expectation can not be met.
> > 
> > So I want the subsystem to have an explicit set of platform quirks
> > ideally backed up by updated spec language. That allows us to validate
> > that the Linux implementation is correct by some objective source of
> > truth, encourage platform vendors to update that source of truth when
> > they create new corner cases, or even better, be more mindful to not
> > create new corner cases.
> 
> I follow, seems reasonable.  
> 
> ~Gregory



  reply	other threads:[~2025-04-02 14:19 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
2025-04-01 23:34         ` Dan Williams
2025-04-02  5:05           ` Gregory Price
2025-04-02 14:20             ` Ira Weiny [this message]
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=67ed4792b475_7190f294ce@iweiny-mobl.notmuch \
    --to=ira.weiny@intel.com \
    --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=gourry@gourry.net \
    --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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.