netdev - Re: [PATCH v13 11/22] 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] [day] [month] [year] [list]

Message-ID: <20250422165157.00006953@huawei.com>
Date: Tue, 22 Apr 2025 16:51:57 +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>, <edward.cree@....com>,
	<davem@...emloft.net>, <kuba@...nel.org>, <pabeni@...hat.com>,
	<edumazet@...gle.com>, <dave.jiang@...el.com>
Subject: Re: [PATCH v13 11/22] cxl: define a driver interface for HPA free
 space enumeration

On Thu, 17 Apr 2025 22:22:19 +0100
Alejandro Lucero Palau <alucerop@....com> wrote:

> On 4/17/25 17:36, Jonathan Cameron wrote:
> > On Thu, 17 Apr 2025 13:11:00 +0100
> > Alejandro Lucero Palau <alucerop@....com> wrote:
> >  
> >> On 4/15/25 14:50, Jonathan Cameron wrote:  
> >>> On Mon, 14 Apr 2025 16:13:25 +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 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.
> >>>>
> >>>> Add a complementary function for releasing the reference to such root
> >>>> decoder.
> >>>>
> >>>> Based on https://lore.kernel.org/linux-cxl/168592159290.1948938.13522227102445462976.stgit@dwillia2-xfh.jf.intel.com/
> >>>>
> >>>> Signed-off-by: Alejandro Lucero <alucerop@....com>  
> >>> One trivial comment inline.
> >>>
> >>> Reviewed-by: Jonathan Cameron <Jonathan.Cameron@...wei.com>
> >>>     
> >>>> diff --git a/drivers/cxl/core/region.c b/drivers/cxl/core/region.c
> >>>> index 80caaf14d08a..0a9eab4f8e2e 100644
> >>>> --- a/drivers/cxl/core/region.c
> >>>> +++ b/drivers/cxl/core/region.c
> >>>> +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 = 0;
> >>>> +
> >>>> +	if (!is_root_decoder(dev))
> >>>> +		return 0;
> >>>> +
> >>>> +	cxlrd = to_cxl_root_decoder(dev);
> >>>> +	cxlsd = &cxlrd->cxlsd;
> >>>> +	cxld = &cxlsd->cxld;
> >>>> +
> >>>> +	/*
> >>>> +	 * None flags are declared as bitmaps but for the sake of better code  
> >>> None?  
> >>
> >> Not sure you refer to syntax or semantics here. Assuming is the former:  
> > Just the wording of the comment. I'm not sure what it means.  
> 
> 
> Ok. I just want to make clear those flags fields used in the 
> bitmap_subset are not declared as bitmaps, just in case someone points 
> this out.
> 
> I do not think this is problematic, and a good idea you gave me, but 
> better to comment on it before someone complains about it.
> 
Ah.. Ok. So something like:

Fields are not declared as bitmaps, but bitmap_subset may still be used.

> 
> >  
> >>
> >> No flags fields?  
> > Not following that either.  
> >>  
> >>>     
> >>>> +	 * used here as such, restricting the bitmap size to those bits used by
> >>>> +	 * any Type2 device driver requester.
> >>>> +	 */  
> >>>