[RFC PATCH 0/4] PCI/TSM: Resolve TDISP coherent (CXL) ranges from precommitted HDM decoders

[Ankit Agrawal <ankita@nvidia.com>]

=== Background ===

TDISP (TEE Device Interface Security Protocol) lets a Confidential
Compute Architecture (CCA) guest establish a trusted, encrypted MMIO
mapping to an assigned PCI device. The device's TSM (TEE Security
Manager) reports the device interface's MMIO layout back to the guest
via a GET_DEVICE_INTERFACE_REPORT response. The guest kernel should
parse this report and get the IPA for the regions present in the report.
This is required to validate the device regions.

CXL (Compute Express Link) runs over the PCIe physical/electrical
layer but adds protocols beyond plain PCIe config/MMIO access. The
one relevant here is CXL.mem on Type-2 CXL devices, which lets a
device expose device-attached memory (e.g. HBM on a GPU) to the
host as regular cacheable, coherent system memory (called CXL region
in this series).

A CXL type 2 device exposes this CXL region through one or more HDM
(Host-managed Device Memory) decoders - hardware on the device that
maps a System Physical Address (SPA) range, as seen by the host/guest,
to the corresponding Device Physical Address (DPA) range on the device's
own memory. The host (or VMM/firmware) programs an HDM decoder's SPA
(IPA) base and size, then "commits" it - after which reads/writes into
that range are transparently steered by the decoder to the device's
memory. This is conceptually similar to a BAR, as both are ways of
mapping device resources into a physical address range that software
can access. However, while a BAR is discovered and sized generically
via PCI config space, an HDM decoder's mapping is CXL-specific and is
not visible in config space or backed by any BAR.

On the systems this series targets, the HDM decoder for the coherent
window is "precommitted": platform firmware programs and locks it
before any software - including the guest OS - ever runs, and the
mapping is fixed and stable across boots (i.e. the guest never needs
to program or resize it itself - it only needs to know where the
firmware already put it). Because this window has no BAR, the TDISP
interface report describes it with a special sentinel range ID
instead of a BAR number.

=== What this series does ===

This series does two things: it first introduces the interface-report
parsing infrastructure itself, adapted from out-of-tree work [1]
originally developed by Dan Williams and Aneesh Kumar and built around
the common BAR-based case, and then extends that same infrastructure
to also understand firmware-precommitted CXL coherent ranges which
cannot be expressed as a BAR. Concretely, in four steps:

 1. "PCI/TSM: Create MMIO descriptors via TDISP Report"
    Introduces the report-parsing infrastructure itself. Only BAR-relative
    ranges are handled at this point. Cherry-picked and adapted from
    Dan Williams' posted series [1] (based on Aneesh Kumar K.V [2],
    co-developed with Xu Yilun), with the evidence-store dependency
    removed.

 2. "PCI/CXL: Populate and insert/remove pdev->coh_resource[]"
    Snapshots the precommitted HDM decoder's SPA base/size into a new
    pdev->coh_resource[] array early during CXL enumeration and
    inserts/removes each entry into/from iomem_resource so the range
    is reserved like any other device resource, giving later patches
    a known-good source of truth for the coherent window.

 3. "PCI/TSM: Derive the coherent-range IPA from CXL"
    Extends the patch 1 parser to recognize the coherent-range
    sentinel range ID (0xffff) and resolve its address from
    pdev->coh_resource[] instead of a BAR offset.

 4. "PCI/TSM: Support multiple coherent ranges via coh_idx"
    Generalizes the spec defined single 0xffff sentinel to a small
    index space so devices with multiple HDM decoders can report
    several coherent windows, indexing into pdev->coh_resource[].

=== Dependencies ===

This series is rebased on top of next-20261002, and requires Srirangan
Madhavan's v14 "CXL HDM decoder state caching across PCI reset" series [4]
that is also undergoing review.

=== Open design questions ===

 - Patch 2 adds pdev->coh_resource[PCI_CXL_MAX_COHERENT_RANGES] (10
   struct resource entries, ~640 bytes) unconditionally to struct
   pci_dev under CONFIG_CXL_RESET regardless of whether a given
   device is actually CXL-capable. Feedback is welcome on whether
   this should instead be allocated dynamically.

=== Testing ===

This series has been verified using an adapted version of Dan
Williams' devsec tool [3], modified to exercise the coherent-range
reporting path added here.

Link: https://lore.kernel.org/all/20260705220819.2472765-15-djbw@kernel.org/ [1]
Link: https://lore.kernel.org/linux-coco/20251117140007.122062-8-aneesh.kumar@kernel.org/ [2]
Link: https://github.com/ankita-nv/linux/tree/next-20261002-tsm-cxl-devsec-0410-2026 [3]
Link: https://lore.kernel.org/all/20261001092227.3004747-1-smadhavan@nvidia.com/ [4]

Ankit Agrawal (4):
  PCI/TSM: Create MMIO descriptors via TDISP Report
  PCI/CXL: Populate and insert/remove pdev->coh_resource[]
  PCI/TSM: Derive the coherent-range IPA from CXL
  PCI/TSM: Support multiple coherent ranges via coh_idx

 drivers/cxl/core/resource.c |  52 ++++-
 drivers/pci/tsm.c           | 370 ++++++++++++++++++++++++++++++++++++
 include/linux/ioport.h      |   2 +
 include/linux/pci-tsm.h     |  37 ++++
 include/linux/pci.h         |  14 ++
 kernel/resource.c           |   8 +
 6 files changed, 482 insertions(+), 1 deletion(-)

-- 
2.43.0