Documentation/driver-api/cxl/platform/bios-and-efi.rst

Source file repositories/reference/linux-study-clean/Documentation/driver-api/cxl/platform/bios-and-efi.rst

File Facts

System
Linux kernel
Corpus path
Documentation/driver-api/cxl/platform/bios-and-efi.rst
Extension
.rst
Size
11283 bytes
Lines
286
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.

Dependency Surface

Detected Declarations

Annotated Snippet

* BIOS/EFI calls :code:`start_kernel` and begins the Linux Early Boot process.

Much of what this section is concerned with is ACPI Table production and
static memory map configuration. More detail on these tables can be found
at :doc:`ACPI Tables <acpi>`.

.. note::
   Platform Vendors should read carefully, as this sections has recommendations
   on physical memory region size and alignment, memory holes, HDM interleave,
   and what linux expects of HDM decoders trying to work with these features.


Linux Expectations of BIOS/EFI Software
=======================================
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.

Some platforms may wish to pre-configure these resources to bring memory
up without requiring CXL driver support.  These platform vendors should
test their configurations with the existing CXL driver and provide driver
support for their auto-configurations if features like RAS are required.

Platforms requiring boot-time programming and/or locking of CXL fabric
components may prevent features, such as device hot-plug, from working.

UEFI Settings
=============
If your platform supports it, the :code:`uefisettings` command can be used to
read/write EFI settings. Changes will be reflected on the next reboot. Kexec
is not a sufficient reboot.

One notable configuration here is the EFI_MEMORY_SP (Specific Purpose) bit.
When this is enabled, this bit tells linux to defer management of a memory
region to a driver (in this case, the CXL driver). Otherwise, the memory is
treated as "normal memory", and is exposed to the page allocator during
:code:`__init`.

uefisettings examples
---------------------

:code:`uefisettings identify` ::

        uefisettings identify

        bios_vendor: xxx
        bios_version: xxx
        bios_release: xxx
        bios_date: xxx
        product_name: xxx
        product_family: xxx
        product_version: xxx

On some AMD platforms, the :code:`EFI_MEMORY_SP` bit is set via the :code:`CXL
Memory Attribute` field.  This may be called something else on your platform.

:code:`uefisettings get "CXL Memory Attribute"` ::

        selector: xxx
        ...
        question: Question {
            name: "CXL Memory Attribute",

Annotation

Implementation Notes