| .. SPDX-License-Identifier: GPL-2.0 | |
| ================== | |
| CXL Device Hotplug | |
| ================== | |
| Device hotplug refers to *physical* hotplug of a device (addition or removal | |
| of a physical device from the machine). | |
| 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 left unprogrammed). | |
| This document covers some examples of those resources, but should not | |
| be considered exhaustive. | |
| Hot-Remove | |
| ========== | |
| Hot removal of a device typically requires careful removal of software | |
| constructs (memory regions, associated drivers) which manage these devices. | |
| Hard-removing a CXL.mem device without carefully tearing down driver stacks | |
| is likely to cause the system to machine-check (or at least SIGBUS if memory | |
| access is limited to user space). | |
| Memory Device Hot-Add | |
| ===================== | |
| A device present at boot may be associated with a CXL Fixed Memory Window | |
| reported in :doc:`CEDT<acpi/cedt>`. That CFMWS may match the size of the | |
| device, but the construction of the CEDT CFMWS is platform-defined. | |
| Hot-adding a memory device requires this pre-defined, **static** CFMWS to | |
| have sufficient HPA space to describe that device. | |
| There are a few common scenarios to consider. | |
| Single-Endpoint Memory Device Present at Boot | |
| --------------------------------------------- | |
| A device present at boot likely had its capacity reported in the | |
| :doc:`CEDT<acpi/cedt>`. If a device is removed and a new device hotplugged, | |
| the capacity of the new device will be limited to the original CFMWS capacity. | |
| Adding capacity larger than the original device will cause memory region | |
| creation to fail if the region size is greater than the CFMWS size. | |
| The CFMWS is **static** and cannot be adjusted. Platforms which may expect | |
| different sized devices to be hotplugged must allocate sufficient CFMWS space | |
| **at boot time** to cover all future expected devices. | |
| Multi-Endpoint Memory Device Present at Boot | |
| -------------------------------------------- | |
| Non-switch-based Multi-Endpoint devices are outside the scope of what the | |
| CXL specification describes, but they are technically possible. We describe | |
| them here for instructive reasons only - this does not imply Linux support. | |
| A hot-plug capable CXL memory device, such as one which presents multiple | |
| expanders as a single large-capacity device, should report the **maximum | |
| possible capacity** for the device at boot. :: | |
| HB0 | |
| RP0 | |
| | | |
| [Multi-Endpoint Memory Device] | |
| _____|_____ | |
| | | | |
| [Endpoint0] [Empty] | |
| Limiting the size to the capacity preset at boot will limit hot-add support | |
| to replacing capacity that was present at boot. | |
| No CXL Device Present at Boot | |
| ----------------------------- | |
| When no CXL memory device is present on boot, some platforms omit the CFMWS | |
| in the :doc:`CEDT<acpi/cedt>`. When this occurs, hot-add is not possible. | |
| This describes the base case for any given device not being present at boot. | |
| If a future possible device is not described in the CEDT at boot, hot-add | |
| of that device is either limited or not possible. | |
| For a platform to support hot-add of a full memory device, it must allocate | |
| a CEDT CFMWS region with sufficient memory capacity to cover all future | |
| potentially added capacity (along with any relevant CEDT CHBS entry). | |
| To support memory hotplug directly on the host bridge/root port, or on a switch | |
| downstream of the host bridge, 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). | |
| Interleave Sets | |
| =============== | |
| Host Bridge Interleave | |
| ---------------------- | |
| Host-bridge interleaved memory regions are defined **statically** in the | |
| :doc:`CEDT<acpi/cedt>`. To apply cross-host-bridge interleave, a CFMWS entry | |
| describing that interleave must have been provided **at boot**. Hotplugged | |
| devices cannot add host-bridge interleave capabilities at hotplug time. | |
| See the :doc:`Flexible CEDT Configuration<example-configurations/flexible>` | |
| example to see how a platform can provide this kind of flexibility regarding | |
| hotplugged memory devices. BIOS/EFI software should consider options to | |
| present flexible CEDT configurations with hotplug support. | |
| HDM Interleave | |
| -------------- | |
| Decoder-applied interleave can flexibly handle hotplugged devices, as decoders | |
| can be re-programmed after hotplug. | |
| To add or remove a device to/from an existing HDM-applied interleaved region, | |
| that region must be torn down an re-created. |