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 for Android: free password hash cracker in your pocket
[<prev] [next>] [<thread-prev] [day] [month] [year] [list]
Message-ID: <eb1e5fca-7a8b-4ff1-8222-ce2eb16777dd@amd.com>
Date: Thu, 17 Apr 2025 22:22:19 +0100
From: Alejandro Lucero Palau <alucerop@....com>
To: Jonathan Cameron <Jonathan.Cameron@...wei.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 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.


>
>>
>> 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.
>>>> +	 */
>>>   

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ