[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <667b55a2865ab_5639294ef@dwillia2-xfh.jf.intel.com.notmuch>
Date: Tue, 25 Jun 2024 16:41:22 -0700
From: Dan Williams <dan.j.williams@...el.com>
To: Alison Schofield <alison.schofield@...el.com>, "Fabio M. De Francesco"
<fabio.m.de.francesco@...ux.intel.com>
CC: Davidlohr Bueso <dave@...olabs.net>, Jonathan Cameron
<jonathan.cameron@...wei.com>, Dave Jiang <dave.jiang@...el.com>, "Vishal
Verma" <vishal.l.verma@...el.com>, Ira Weiny <ira.weiny@...el.com>, "Dan
Williams" <dan.j.williams@...el.com>, <linux-cxl@...r.kernel.org>,
<linux-kernel@...r.kernel.org>
Subject: Re: [PATCH] cxl/acpi: Warn on unsupported platform config detection
Alison Schofield wrote:
> On Wed, Jun 19, 2024 at 02:59:41PM +0200, Fabio M. De Francesco wrote:
>
> Hi Fabio,
> You've written such a detailed commit msg, that it pulls me in,
> and now I want to understand more....
>
>
> > Each Host Bridge instance has a corresponding CXL Host Bridge Structure
> > (CHBS) ACPI table that identifies its capabilities. CHBS tables can be
> > two types: RCRB and CHBCR.
>
> Is there a spec reference for this?
> While you're spelling things out, please expand RCRB and CHBCR
>
> >
> > If a Host Bridge is attached to a device that is operating in Restricted
> > CXL Device Mode (RCD), BIOS publishes an RCRB with the base address of
> > registers that describe its capabilities.
> >
> > However, the new (CXL 2.0+) Component registers (e.g., Extended Security
> > Capability), can only be accessed by means of a base address published
> > with a CHBCR.
> >
> > An algorithm to locate a CHBCR associated with an RCRB would be too
> > invasive to land without some concrete motivation.
> >
> > Therefore, just print a message to inform of unsupported config.
> >
>
>
> Were users seeing this and confused by this silent failure?
> What did it look like before?
This is a "by inspection" realization that the CXL specification
currently does not define a mechanism for finding CXL-2.0-only root-port
component regsiters like HDM decoders and Extended Security capability.
Rather than go through a fire drill of clarifying how that is supposed
to work, just the known conflict for now.
When / if someone actually shows up with an eRCD (a device that forces
the host-bridge into CXL 1.1 Restricted CXL Host mode) then we can
consider if Linux needs to do the work to support that. To my knowledge
all of the commercial devices on the market are so-called "CXL 1.1+"
which support training in VH (CXL Virtual Host) mode when attached to a
CXL 2.0 host. So, Linux can likely live with disclaiming "eRCD attached
to a VH host support" for the foreseeable future.
Powered by blists - more mailing lists