Re: [RFC PATCH v2 0/3] cxl: Provide explicit RAM region creation for Type-2 providers

From: Lucero Palau, Alejandro

Date: Wed Oct 14 2026 - 13:35:06 EST



On 14/10/2026 18:16, Dave Jiang wrote:

On 10/14/26 9:35 AM, Lucero Palau, Alejandro wrote:
On 14/10/2026 17:23, Dave Jiang wrote:
On 10/14/26 8:34 AM, Lucero Palau, Alejandro wrote:
On 07/10/2026 10:05, Richard Cheng wrote:
A Type-2 provider uses devm_cxl_probe_mem() to register its memdev
and obtain an HPA range. This requires an existing committed region,
so registration fails when firmware has not configured one.

Firmware may provide a suitable CFMWS window without programming a
region.
Hi Richard,


FWIW, I unsuccessfully  tried to explain this possibility to "BIOS people". The fact is, nowadays for AMD and I think for Intel as well, if there is no CXL device detected with CXL.mem enabled, the BIOS will neither set HDMs  nor there will be a CFMWS.
Hmmmm....don't they have to reserve CFMWS for hotplug?

I have to admit I'm a bit lost with hotplugging and CXL needs, and not real experience with hot plug devices at all, but in my mind hotplugging allows a great flexibility which is counterintuitive if you need to know before hand which devices are going to be hot plugged ..., regarding CXL, how a CFMWS can be created without having that information? Maybe there is something in the specs about this and I did not pay attention.

I believe BIOS needs to set aside a range of HPA via CFMWS to allow for hot plugged devices.

What do you think about my other concern below?


DJ


Hot-added devices can have the same requirement. A provider
needs its endpoint topology established before deciding when to
create a region and how much memory to map.
Another unsuccessfully discussion was to avoid BIOS setting HDMs at hotplug time as this could race with host dynamic regions creation.

The BIOS does not touch device when hot plugged I believe. It's all OS native handled.


If this is the kernel expectation and I'm the only one concerned with BIOSes respecting it, nothing more to be discussed.


Thanks,

Alejandro.


I'm commenting these two things here for maybe having a community/kernel discussion with the goal of defining what BIOSes should do and mostly what they should not do if they want to be compatible with kernel expectations.