netdev - Re: [PATCH v21 00/23] Type2 device basic support

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: <31dae6910b0863dee44069d01a909f8ed0b19bb2.camel@kernel.org>
Date: Fri, 28 Nov 2025 11:44:42 -0800
From: PJ Waskiewicz <ppwaskie@...nel.org>
To: 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
Cc: Alejandro Lucero <alucerop@....com>
Subject: Re: [PATCH v21 00/23] Type2 device basic support

Hi Alejandro,

On Wed, 2025-11-19 at 19:22 +0000, alejandro.lucero-palau@....com
wrote:
> From: Alejandro Lucero <alucerop@....com>
> 
> The patchset should be applied on the described base commit then
> applying
> Terry's v13 about CXL error handling. The first 4 patches come from
> Dan's
> for-6.18/cxl-probe-order branch with minor modifications.
> 
> v21 changes;
> 
>   patch1-2: v20 patch1 splitted up doing the code move in the second
> 	    patch in v21. (Jonathan)
>  
>   patch1-4: adding my Signed-off tag along with Dan's
> 
>   patch5: fix duplication of CXL_NR_PARTITION definition
> 
>   patch7: dropped the cxl test fixes removing unused function. It was
> 	  sent independently ahead of this version.
> 
>   patch12: optimization for max free space calculation (Jonathan)
> 
>   patch19: optimization for returning on error (Jonathan)
> 

So I'm unable to get these patches working with a Type2 device that
just needs its existing resources auto-discovered by the CXL core. 
These patches are assuming the underlying device will require full
setup and allocations for DPA and HPA.  I'd argue that a true Type2
device will not be doing that today with existing BIOS implementations.

I've tested this behavior on both Intel and AMD platforms (GNR and
Turin), and they're behaving the same way.  Both will train up the
Type2 device, see there's an advertised CXL.mem region marked EFI
Special Purpose memory, and will map it and program the decoders. 
These patches partially see those decoders are already programmed, but
does not bypass that fact, and still attemps to dynamically allocate,
configure, and commit, the whole flow.  This assumption fails the init
path.

I think there needs to be a bit of a re-think here.  I briefly chatted
with Dan offline about this, and we do think a different approach is
likely needed.  The current CXL core for Type3 devices can handle when
the BIOS/platform firmware already discovers and maps resources, so we
should be able to do that for this case.

If you're going to be at Plumbers in a week or so, this would be a
great topic if we could grab a whiteboard somewhere and just hack on
it.  Otherwise we can also chat on the Discord (I just joined finally).

Cheers,
-PJ