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: <ed390a72-2470-4e09-8fbe-56915d619dfa@intel.com>
Date: Tue, 7 Oct 2025 13:25:11 -0700
From: Dave Jiang <dave.jiang@...el.com>
To: Gregory Price <gourry@...rry.net>,
 "Fabio M. De Francesco" <fabio.m.de.francesco@...ux.intel.com>
Cc: linux-cxl@...r.kernel.org, Davidlohr Bueso <dave@...olabs.net>,
 Jonathan Cameron <jonathan.cameron@...wei.com>,
 Alison Schofield <alison.schofield@...el.com>,
 Vishal Verma <vishal.l.verma@...el.com>, Ira Weiny <ira.weiny@...el.com>,
 Dan Williams <dan.j.williams@...el.com>, Jonathan Corbet <corbet@....net>,
 linux-doc@...r.kernel.org, linux-kernel@...r.kernel.org,
 Robert Richter <rrichter@....com>,
 Cheatham Benjamin <benjamin.cheatham@....com>
Subject: Re: [PATCH 3/4 v5] cxl/core: Enable Region creation on x86 with LMH



On 10/6/25 10:46 AM, Gregory Price wrote:
> On Mon, Oct 06, 2025 at 05:58:06PM +0200, Fabio M. De Francesco wrote:
>> The CXL Fixed Memory Window Structure (CFMWS) describes zero or more
>> Host Physical Address (HPA) windows that are associated with each CXL
>> Host Bridge. Each window represents a contiguous HPA that may be
>> interleaved with one or more targets (CXL v3.2 - 9.18.1.3).
>>
> ...
>>
>> Cc: Alison Schofield <alison.schofield@...el.com>
>> Cc: Dan Williams <dan.j.williams@...el.com>
>> Cc: Dave Jiang <dave.jiang@...el.com>
>> Cc: Ira Weiny <ira.weiny@...el.com>
>> Signed-off-by: Fabio M. De Francesco <fabio.m.de.francesco@...ux.intel.com>
> 
> Couple inlines but just nits
> 
> Reviewed-by: Gregory Price <gourry@...rry.net>
> 
>> @@ -1770,6 +1778,7 @@ static int match_cxlsd_to_cxled_by_range(struct device *dev, const void *data)
>>  {
>>  	const struct cxl_endpoint_decoder *cxled = data;
>>  	struct cxl_switch_decoder *cxlsd;
>> +	struct cxl_root_decoder *cxlrd;
>>  	const struct range *r1, *r2;
>>  
>>  	if (!is_switch_decoder(dev))
>> @@ -1779,8 +1788,13 @@ static int match_cxlsd_to_cxled_by_range(struct device *dev, const void *data)
>>  	r1 = &cxlsd->cxld.hpa_range;
>>  	r2 = &cxled->cxld.hpa_range;
>>  
>> -	if (is_root_decoder(dev))
>> -		return range_contains(r1, r2);
>> +	if (is_root_decoder(dev)) {
>> +		if (range_contains(r1, r2))
>> +			return 1;
>> +		cxlrd = to_cxl_root_decoder(dev);
>> +		if (platform_cxlrd_matches_cxled(cxlrd, cxled))
>> +			return 1;
>> +	}
> 
> Is there any concern for longer term maintainability if addition
> match_*() functions are added?  Or is this upkeep just the unfortunate
> maintenance cost of supportering the quirk?

Suggestions welcome. Would be nice if we have cleaner ways of dealing with this.

> 
>>  
>>  static struct cxl_decoder *
>> @@ -3406,8 +3421,12 @@ static int match_region_to_cxled_by_range(struct device *dev, const void *data)
>>  	p = &cxlr->params;
>>  
>>  	guard(rwsem_read)(&cxl_rwsem.region);
>> -	if (p->res && p->res->start == r->start && p->res->end == r->end)
>> -		return 1;
>> +	if (p->res) {
>> +		if (p->res->start == r->start && p->res->end == r->end)
>> +			return 1;
>> +		if (platform_region_matches_cxld(p, &cxled->cxld))
>> +			return 1;
>> +	}
> 
> 
> if (!p->res)
> 	return 0;
> if (p->res->start == r->start && p->res->end == r->end)
> 	return 1;
> if (platform_region_matches_cxld(p, &cxled->cxld))
> 	return 1;
> return 0;
> 
> ?
> 
> I like flat, but I also dislike not-logic.  Style choice here, unless
> others have a strong feeling this is fine.

More flat is definitely the preferred way. With the changes, the last one we can actually do:

return platform_region_matches_cxld(p, &cxled->cxld));


> 
> ~Gregory


Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ