| lists.openwall.net | lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC | |
|
Open Source and information security mailing list archives
| ||
|
Message-ID: <20240828121948.00001105@Huawei.com>
Date: Wed, 28 Aug 2024 12:19:48 +0100
From: Jonathan Cameron <Jonathan.Cameron@...wei.com>
To: Alejandro Lucero Palau <alucerop@....com>
CC: <alejandro.lucero-palau@....com>, <linux-cxl@...r.kernel.org>,
<netdev@...r.kernel.org>, <dan.j.williams@...el.com>,
<martin.habets@...inx.com>, <edward.cree@....com>, <davem@...emloft.net>,
<kuba@...nel.org>, <pabeni@...hat.com>, <edumazet@...gle.com>,
<richard.hughes@....com>
Subject: Re: [PATCH v2 09/15] cxl: define a driver interface for HPA free
space enumaration
On Wed, 28 Aug 2024 11:18:12 +0100
Alejandro Lucero Palau <alucerop@....com> wrote:
> On 8/4/24 18:57, Jonathan Cameron wrote:
> > On Mon, 15 Jul 2024 18:28:29 +0100
> > alejandro.lucero-palau@....com wrote:
> >
> >> From: Alejandro Lucero <alucerop@....com>
> >>
> >> CXL region creation involves allocating capacity from device DPA
> >> (device-physical-address space) and assigning it to decode a given HPA
> >> (host-physical-address space). Before determining how much DPA to
> >> allocate the amount of available HPA must be determined. Also, not all
> >> HPA is create equal, some specifically targets RAM, some target PMEM,
> >> some is prepared for device-memory flows like HDM-D and HDM-DB, and some
> >> is host-only (HDM-H).
> >>
> >> Wrap all of those concerns into an API that retrieves a root decoder
> >> (platform CXL window) that fits the specified constraints and the
> >> capacity available for a new region.
> >>
> >> Based on https://lore.kernel.org/linux-cxl/168592149709.1948938.8663425987110396027.stgit@dwillia2-xfh.jf.intel.com/T/#m6fbe775541da3cd477d65fa95c8acdc347345b4f
> >>
> >> Signed-off-by: Alejandro Lucero <alucerop@....com>
> >> Co-developed-by: Dan Williams <dan.j.williams@...el.com>
> > Hi.
> >
> > This seems a lot more complex than an accelerator would need.
> > If plan is to use this in the type3 driver as well, I'd like to
> > see that done as a precursor to the main series.
> > If it only matters to accelerator drivers (as in type 3 I think
> > we make this a userspace problem), then limit the code to handle
> > interleave ways == 1 only. Maybe we will care about higher interleave
> > in the long run, but do you have a multihead accelerator today?
> >
> > Jonathan
> >
> >> ---
> >> drivers/cxl/core/region.c | 161 +++++++++++++++++++++++++++++
> >> drivers/cxl/cxl.h | 3 +
> >> drivers/cxl/cxlmem.h | 5 +
> >> drivers/net/ethernet/sfc/efx_cxl.c | 14 +++
> >> include/linux/cxl_accel_mem.h | 9 ++
> >> 5 files changed, 192 insertions(+)
> >>
> >> diff --git a/drivers/cxl/core/region.c b/drivers/cxl/core/region.c
> >> index 538ebd5a64fd..ca464bfef77b 100644
> >> --- a/drivers/cxl/core/region.c
> >> +++ b/drivers/cxl/core/region.c
> >> @@ -702,6 +702,167 @@ static int free_hpa(struct cxl_region *cxlr)
> >> return 0;
> >> }
> >>
> >> +
> >> +struct cxlrd_max_context {
> >> + struct device * const *host_bridges;
> >> + int interleave_ways;
> >> + unsigned long flags;
> >> + resource_size_t max_hpa;
> >> + struct cxl_root_decoder *cxlrd;
> >> +};
> >> +
> >> +static int find_max_hpa(struct device *dev, void *data)
> >> +{
> >> + struct cxlrd_max_context *ctx = data;
> >> + struct cxl_switch_decoder *cxlsd;
> >> + struct cxl_root_decoder *cxlrd;
> >> + struct resource *res, *prev;
> >> + struct cxl_decoder *cxld;
> >> + resource_size_t max;
> >> + int found;
> >> +
> >> + if (!is_root_decoder(dev))
> >> + return 0;
> >> +
> >> + cxlrd = to_cxl_root_decoder(dev);
> >> + cxld = &cxlrd->cxlsd.cxld;
> >> + if ((cxld->flags & ctx->flags) != ctx->flags) {
> >> + dev_dbg(dev, "find_max_hpa, flags not matching: %08lx vs %08lx\n",
> >> + cxld->flags, ctx->flags);
> >> + return 0;
> >> + }
> >> +
> >> + /* A Host bridge could have more interleave ways than an
> >> + * endpoint, couldn´t it?
> > EP interleave ways is about working out how the full HPA address (it's
> > all sent over the wire) is modified to get to the DPA. So it needs
> > to know what the overall interleave is. Host bridge can't interleave
> > and then have the EP not know about it. If there are switch HDM decoders
> > in the path, the host bridge interleave may be less than that the EP needs
> > to deal with.
> >
> > Does an accelerator actually cope with interleave? Is aim here to ensure
> > that IW is never anything other than 1? Or is this meant to have
> > more general use? I guess it is meant to. In which case, I'd like to
> > see this used in the type3 driver as well.
>
>
> I guess an accelerator could cope with interleave ways > 1, but not ours.
>
> And it does not make sense to me an accelerator being an EP for an
> interleaved HPA because the memory does not make sense out of the
> accelerator.
>
> So if the CFMW and the Host Bridge have an interleave way of 2, implying
> accesses to the HPA through different wires, I assume an accelerator
> should not be allowed.
That's certainly fine for now. 'maybe' something will come along that can
make use of interleaving (I'm thinking of Processing near memory type setup
where it's offloading minor stuff more local to the memory but is basically
type 3 memory)
>
>
> >> + *
> >> + * What does interleave ways mean here in terms of the requestor?
> >> + * Why the FFMWS has 0 interleave ways but root port has 1?
> > FFMWS?
>
>
> I meant CFMW, and I think this comment is because I found out the CFMW
> is parsed with interleave ways = 0 then the root port having 1, what is
> confusing.
>
I'm a bit lost. Maybe this is just encoded and 'real' values?
1 way interleave is just not interleaving.
Jonathan
Powered by blists - more mailing lists