linux-kernel - Re: CXL Boot to Bash - Section 2a (Drivers): CXL Decoder Programming

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: <fb2e8912-9a64-4053-bb8c-dcaceb669731@fujitsu.com>
Date: Tue, 8 Apr 2025 03:10:24 +0000
From: "Zhijian Li (Fujitsu)" <lizhijian@...itsu.com>
To: Gregory Price <gourry@...rry.net>
CC: "lsf-pc@...ts.linux-foundation.org" <lsf-pc@...ts.linux-foundation.org>,
	"linux-mm@...ck.org" <linux-mm@...ck.org>, "linux-cxl@...r.kernel.org"
	<linux-cxl@...r.kernel.org>, "linux-kernel@...r.kernel.org"
	<linux-kernel@...r.kernel.org>
Subject: Re: CXL Boot to Bash - Section 2a (Drivers): CXL Decoder Programming

Hi Gregory and CXL

One more (silly) question as below

On 02/04/2025 22:18, Gregory Price wrote:
> On Wed, Apr 02, 2025 at 06:45:33AM +0000, Zhijian Li (Fujitsu) wrote:
>> Hi Gregory,
>>
>>
>> On 07/03/2025 07:56, Gregory Price wrote:
>>> What if instead, we had two 256MB endpoints on the same host bridge?
>>>
>>> ```
>>> CEDT
>>>              Subtable Type : 01 [CXL Fixed Memory Window Structure]
>>>                   Reserved : 00
>>>                     Length : 002C
>>>                   Reserved : 00000000
>>>        Window base address : 0000000100000000   <- Memory Region
>>>                Window size : 0000000020000000   <- 512MB
>>> Interleave Members (2^n) : 00                 <- Not interleaved
>>>
>>> Memory Map:
>>>     [mem 0x0000000100000000-0x0000000120000000] usable  <- SPA
>>>
>>> Decoders
>>>                               decoder0.0
>>>                     range=[0x100000000, 0x120000000]
>>>                                   |
>>>                               decoder1.0
>>>                     range=[0x100000000, 0x120000000]
>>>                     /                              \
>>>               decoded2.0                        decoder3.0
>>>     range=[0x100000000, 0x110000000]   range=[0x110000000, 0x120000000]
>>> ```
>>
>> It reminds me that during construct_region(), it requires decoder range in the
>> switch/host-bridge is exact same with the endpoint decoder. see
>> match_switch_decoder_by_range()


 From the code, we can infer this point. However, is this just a solution implemented in software,
or is it explicitly mandated by the CXL SPEC or elsewhere? If you are aware, please let me know.

I have been trying for days to find documentary evidence to persuade our firmware team that,
during device provisioning, the programming of the HDM decoder should adhere to this principle:
The range in the HDM decoder should be exactly the same between the device and its upstream switch.

Thanks
Zhijian

>>
>> If so, does following decoders make sense?
>>
>>
>>    Decoders
>>                                 decoder0.0
>>                       range=[0x100000000, 0x120000000]
>>                                     |
>>                        +------------+-----------+
>>                       /                          \
>>                      |      Host-bridge contains  |
>>                decoder1.0     2 decoders       decoder1.1
>>        range=[0x100000000, 0x110000000]     range=[0x110000000, 0x120000000]
>>                       /                              \
>>                 decoded2.0                        decoder3.0
>>       range=[0x100000000, 0x110000000]   range=[0x110000000, 0x120000000]
>>
> 
> You are correct, i'll update this.