Documentation/driver-api/cxl/platform/device-hotplug.rst
Source file repositories/reference/linux-study-clean/Documentation/driver-api/cxl/platform/device-hotplug.rst
File Facts
- System
- Linux kernel
- Corpus path
Documentation/driver-api/cxl/platform/device-hotplug.rst- Extension
.rst- Size
- 5374 bytes
- Lines
- 131
- Domain
- Support Tooling And Documentation
- Bucket
- Documentation
- Inferred role
- Support Tooling And Documentation: documentation
- Status
- atlas-only
Why This File Exists
Repository support layer: documentation, build tooling, samples, user-space helper tools, generated initramfs support, licenses, and validation utilities.
- Repository support layer: documentation, build tooling, samples, user-space helper tools, generated initramfs support, licenses, and validation utilities.
- Defines or uses C structs; map object ownership, embedded links, reference counts, and lock ownership.
Dependency Surface
- No C-style include directives detected by the generator.
Detected Declarations
- No top-level syscall, struct, function, initcall, or export declaration detected by the generator.
Annotated Snippet
.. 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]
Annotation
- Atlas domain: Support Tooling And Documentation / Documentation.
- Implementation status: atlas-only.
Implementation Notes
- This generated page is the file-by-file coverage layer; curated subsystem chapters should link here when they synthesize a multi-file control flow.
- Core OS pages should be promoted from atlas-only to deep-reviewed when they explain data structures, invariants, locking, lifecycle, and C implementation snippets.
- Driver-family pages are intentionally pattern-oriented unless they are part of the selected PCIe/NVMe representative device path.