linux-kernel - Re: [PATCH v2] Documentation/driver-api/cxl: device hotplug section

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: <aUV1bz3ddsSaj6qZ@gourry-fedora-PF4VCD3F>
Date: Fri, 19 Dec 2025 10:55:27 -0500
From: Gregory Price <gourry@...rry.net>
To: Alejandro Lucero Palau <alucerop@....com>
Cc: linux-cxl@...r.kernel.org, linux-doc@...r.kernel.org,
	linux-kernel@...r.kernel.org, kernel-team@...a.com,
	dave@...olabs.net, jonathan.cameron@...wei.com,
	dave.jiang@...el.com, alison.schofield@...el.com,
	vishal.l.verma@...el.com, ira.weiny@...el.com,
	dan.j.williams@...el.com, corbet@....net
Subject: Re: [PATCH v2] Documentation/driver-api/cxl: device hotplug section

On Fri, Dec 19, 2025 at 03:06:21PM +0000, Alejandro Lucero Palau wrote:
> > +To support memory hotplug directly on the host bridge, or on a switch
> > +downstream of the host bridge (but not contained within a CXL memory device),
> > +a platform must construct a CEDT CFMWS at boot with sufficient resources to
> > +support the max possible (or expected) hotplug memory capacity. ::
> > +
> > +         HB0                 HB1
> > +      RP0    RP1             RP2
> > +       |      |               |
> > +     Empty  Empty            USP
> > +                      ________|________
> > +                      |    |    |     |
> > +                     DSP  DSP  DSP   DSP
> > +                      |    |    |    |
> > +                         All  Empty
> > +
> > +For example, a BIOS/EFI may expose an option to configure a CEDT CFMWS with
> > +a pre-configured amount of memory capacity (per host bridge, or host bridge
> > +interleave set), even if no device is attached to Root Ports or Downstream
> > +Ports at boot (as depicted in the figure above).
> 
> All this is fine, but my concern is what the BIOS will do when a device ends
> up being hotplugged. 

It should do nothing more than what is required to bring the device up
and make it visible on the PCIe/CXL link.  BIOS should not be
programmign the device at runtime.

I realize this is likely infeasible for certain setups, like the current
setup of Zen5 and it's address translation setup, but then I think most
platforms right now don't really handle any of this.

> Assuming that programmability from the Host/user space
> for creating regions on demand based on requirements like bandwidth, and
> therefore relying on interleaving and granularity (I know this is not
> trivial but I think this is possible in the near future, or at least
> possible to be demanded) then the BIOS should not do any HDM programming at
> all ...
> 

Correct.

That said, I can only speak from a BIOS -> Linux transition perspective.
I know enough about the ACPI spec, CXL spec, Linux MM, and the Linux
driver to say "what linux expects" - but I have absolutely no idea what
BIOS *actually does* at boot or hotplug time.

If you have some of that perspective, please propose changes to the
documentation based on what is feasible/possible.  All I can do is write
from the base of what I know.

> I think it is worth to document this somehow and maybe to discuss this with
> BIOSes vendors if we consider this convenient.
>

The entire point of this document is really to spell out that the BIOS
is only responsible for setting up the environment *at boot*, and then
at hotplug time the BIOS should do nothing wrt to programming stuff :]

I can add this explicitly at the top of this document in v3 (and
probably should be spelled out in the BIOS/EFI config doc)
https://docs.kernel.org/driver-api/cxl/platform/bios-and-efi.html

Would something like this suffice?

"""
Linux expects BIOS/EFI software to construct sufficient ACPI tables
(such as CEDT, SRAT, HMAT, etc) and platform-specific configurations
(such as HPA spaces and host-bridge interleave configurations) to allow
the Linux driver to subsequently configure the devices in the CXL fabric
at runtime.

Programming of HDM decoders and switch ports is not required, and may be
deferred to the CXL driver based on admin policy (e.g. udev rules).

Some platforms may require pre-programming HDM decoders and locking them
due to quirks (see: Zen5 address translation), but this is not the normal,
"expected" configuration path.  This should be avoided if possible.

For hotplugged devices, BIOS/EFI software is expected to configure
sufficient resources **at boot time** to allow hotplugged devices
to be configured by software (such as proximity domains, HPA regions,
and host-bridge configurations).

BIOS/EFI is not expected (**nor suggested**) to configure hotplugged
devices at hotplug time (i.e. HDM decoders should be leftunprogrammed).
"""

~Gregory