netdev - Re: [PATCH v9 15/27] cxl: define a driver interface for HPA free space enumeration

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

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <67902f4858ba1_20fa29464@dwillia2-xfh.jf.intel.com.notmuch>
Date: Tue, 21 Jan 2025 15:35:36 -0800
From: Dan Williams <dan.j.williams@...el.com>
To: Alejandro Lucero Palau <alucerop@....com>, Dan Williams
	<dan.j.williams@...el.com>, <alejandro.lucero-palau@....com>,
	<linux-cxl@...r.kernel.org>, <netdev@...r.kernel.org>, <edward.cree@....com>,
	<davem@...emloft.net>, <kuba@...nel.org>, <pabeni@...hat.com>,
	<edumazet@...gle.com>, <dave.jiang@...el.com>
Subject: Re: [PATCH v9 15/27] cxl: define a driver interface for HPA free
 space enumeration

Alejandro Lucero Palau wrote:
> 
> On 1/18/25 03:02, Dan Williams wrote:
> > alejandro.lucero-palau@ 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 created 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/168592159290.1948938.13522227102445462976.stgit@dwillia2-xfh.jf.intel.com/
[..]
> >> +/**
> >> + * cxl_get_hpa_freespace - find a root decoder with free capacity per constraints
> >> + * @cxlmd: the CXL memory device with an endpoint that is mapped by the returned
> >> + *	    decoder
> >> + * @flags: CXL_DECODER_F flags for selecting RAM vs PMEM, and HDM-H vs HDM-D[B]
> >> + * @max_avail_contig: output parameter of max contiguous bytes available in the
> >> + *		      returned decoder
> >> + *
> >> + * The return tuple of a 'struct cxl_root_decoder' and 'bytes available given
> >> + * in (@max_avail_contig))' is a point in time snapshot. If by the time the
> >> + * caller goes to use this root decoder's capacity the capacity is reduced then
> >> + * caller needs to loop and retry.
> >> + *
> >> + * The returned root decoder has an elevated reference count that needs to be
> >> + * put with put_device(cxlrd_dev(cxlrd)). Locking context is with
> >> + * cxl_{acquire,release}_endpoint(), that ensures removal of the root decoder
> >> + * does not race.
> >> + */
> >> +struct cxl_root_decoder *cxl_get_hpa_freespace(struct cxl_memdev *cxlmd,
> >> +					       unsigned long flags,
> >> +					       resource_size_t *max_avail_contig)
> > I don't understand the rationale throwing away the ability to search
> > root decoders by additional constraints.
> 
> Not sure I follow you here. I think the constraints, set by the caller, 
> is something to check for sure.

This is the original proposal:

struct cxl_root_decoder *cxl_hpa_freespace(struct cxl_port *endpoint,
					   struct device *const *host_bridges,
					   int interleave_ways,
					   unsigned long flags,
					   resource_size_t *max)

...it includes support for selecting a CXL window that might be
interleaved. The support for checking interleaved vs non-interleaved
windows is trivial. The support for PMEM region assembly requires
interleaved capacity search even if accelerators do not, so it is worth
including that small incremental support from day one.