linux-kernel - Re: [PATCH 0/6] cxl: Initialization reworks in support Soft Reserve Recovery and Accelerator Memory

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: <69334c038705b_1b2e100b5@dwillia2-mobl4.notmuch>
Date: Fri, 5 Dec 2025 13:17:55 -0800
From: <dan.j.williams@...el.com>
To: Alejandro Lucero Palau <alucerop@....com>, Dan Williams
	<dan.j.williams@...el.com>, <dave.jiang@...el.com>
CC: <linux-cxl@...r.kernel.org>, <linux-kernel@...r.kernel.org>,
	<Smita.KoralahalliChannabasappa@....com>, <alison.schofield@...el.com>,
	<terry.bowman@....com>, <alejandro.lucero-palau@....com>,
	<linux-pci@...r.kernel.org>, <Jonathan.Cameron@...wei.com>, Shiju Jose
	<shiju.jose@...wei.com>
Subject: Re: [PATCH 0/6] cxl: Initialization reworks in support Soft Reserve
 Recovery and Accelerator Memory

Alejandro Lucero Palau wrote:
[..]
> > For "Accelerator Memory", the driver is not cxl_pci, but any potential
> > PCI driver that wants to use the devm_cxl_add_memdev() ABI to attach to
> > the CXL memory domain. Those drivers want to know if the CXL link is
> > live end-to-end (from endpoint, through switches, to the host bridge)
> > and CXL memory operations are enabled. If not, a CXL accelerator may be
> > able to fall back to PCI-only operation. Similar to the "Soft Reserve
> > Memory" it needs to know that the CXL subsystem had a chance to probe
> > the ancestor topology of the device and let that driver make a
> > synchronous decision about CXL operation.
> 
> 
> IMO, this is not the problem with accelerators, because this can not be 
> dynamically done, or not easily.

Hmm, what do you mean can not be dynamically done? The observation is
that a CXL card and its driver have no idea if the card is going to be
plugged into a PCIe only slot.

At runtime the driver only finds out the CXL is not there from the
result of devm_cxl_add_memdev().

> The HW will support CXL or PCI, and if 
> CXL mem is not enabled by the firmware, likely due to a 
> negotiation/linking problem, the driver can keep going with CXL.io.

Right, I think we are in violent agreement.

> Of course, this is from my experience with sfc driver/hardware. Note
> sfc driver added the check for CXL availability based on Terry's v13.

Note that Terry's check for CXL availabilty is purely a hardware
detection, there are still software reasons why cxl_acpi and cxl_mem
can prevent devm_cxl_add_memdev() success.

> But this is useful for solving the problem of module removal which can 
> leave the type2 driver without the base for doing any unwinding. Once a 
> type2 uses code from those other cxl modules explicitly, the problem is 
> avoided. You seem to have forgotten about this problem, what I think it 
> is worth to describe.

What problem exactly? If it needs to be captured in these changelogs or
code comments, let me know.