cxl/port: Add a driver for 'struct cxl_port' objects
The need for a CXL port driver and a dedicated cxl_bus_type is driven by
a need to simultaneously support 2 independent physical memory decode
domains (cache coherent CXL.mem and uncached PCI.mmio) that also
intersect at a single PCIe device node. A CXL Port is a device that
advertises a CXL Component Register block with an "HDM Decoder
Capability Structure".
>From Documentation/driver-api/cxl/memory-devices.rst:
Similar to how a RAID driver takes disk objects and assembles them into
a new logical device, the CXL subsystem is tasked to take PCIe and ACPI
objects and assemble them into a CXL.mem decode topology. The need for
runtime configuration of the CXL.mem topology is also similar to RAID in
that different environments with the same hardware configuration may
decide to assemble the topology in contrasting ways. One may choose
performance (RAID0) striping memory across multiple Host Bridges and
endpoints while another may opt for fault tolerance and disable any
striping in the CXL.mem topology.
The port driver identifies whether an endpoint Memory Expander is
connected to a CXL topology. If an active (bound to the 'cxl_port'
driver) CXL Port is not found at every PCIe Switch Upstream port and an
active "root" CXL Port then the device is just a plain PCIe endpoint
only capable of participating in PCI.mmio and DMA cycles, not CXL.mem
coherent interleave sets.
The 'cxl_port' driver lets the CXL subsystem leverage driver-core
infrastructure for setup and teardown of register resources and
communicating device activation status to userspace. The cxl_bus_type
can rendezvous the async arrival of platform level CXL resources (via
the 'cxl_acpi' driver) with the asynchronous enumeration of Memory
Expander endpoints, while also implementing a hierarchical locking model
independent of the associated 'struct pci_dev' locking model. The
locking for dport and decoder enumeration is now handled in the core
rather than callers.
For now the port driver only enumerates and registers CXL resources
(downstream port metadata and decoder resources) later it will be used
to take action on its decoders in response to CXL.mem region
provisioning requests.
Note1: cxlpci.h has long depended on pci.h, but port.c was the first to
not include pci.h. Carry that dependency in cxlpci.h.
Note2: cxl port enumeration and probing complicates CXL subsystem init
to the point that it helps to have centralized debug logging of probe
events in cxl_bus_probe().
Reported-by: kernel test robot <lkp@intel.com>
Signed-off-by: Ben Widawsky <ben.widawsky@intel.com>
Reviewed-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
Co-developed-by: Dan Williams <dan.j.williams@intel.com>
Link: https://lore.kernel.org/r/164374948116.464348.1772618057599155408.stgit@dwillia2-desk3.amr.corp.intel.com
Signed-off-by: Dan Williams <dan.j.williams@intel.com>
This commit is contained in:
Ben Widawsky
committed by
Dan Williams
Dan Williams
parent
83fbdbe4c1
commit
54cdbf845c
@@ -14,6 +14,303 @@ that optionally define a device's contribution to an interleaved address
|
||||
range across multiple devices underneath a host-bridge or interleaved
|
||||
across host-bridges.
|
||||
|
||||
CXL Bus: Theory of Operation
|
||||
============================
|
||||
Similar to how a RAID driver takes disk objects and assembles them into a new
|
||||
logical device, the CXL subsystem is tasked to take PCIe and ACPI objects and
|
||||
assemble them into a CXL.mem decode topology. The need for runtime configuration
|
||||
of the CXL.mem topology is also similar to RAID in that different environments
|
||||
with the same hardware configuration may decide to assemble the topology in
|
||||
contrasting ways. One may choose performance (RAID0) striping memory across
|
||||
multiple Host Bridges and endpoints while another may opt for fault tolerance
|
||||
and disable any striping in the CXL.mem topology.
|
||||
|
||||
Platform firmware enumerates a menu of interleave options at the "CXL root port"
|
||||
(Linux term for the top of the CXL decode topology). From there, PCIe topology
|
||||
dictates which endpoints can participate in which Host Bridge decode regimes.
|
||||
Each PCIe Switch in the path between the root and an endpoint introduces a point
|
||||
at which the interleave can be split. For example platform firmware may say at a
|
||||
given range only decodes to 1 one Host Bridge, but that Host Bridge may in turn
|
||||
interleave cycles across multiple Root Ports. An intervening Switch between a
|
||||
port and an endpoint may interleave cycles across multiple Downstream Switch
|
||||
Ports, etc.
|
||||
|
||||
Here is a sample listing of a CXL topology defined by 'cxl_test'. The 'cxl_test'
|
||||
module generates an emulated CXL topology of 2 Host Bridges each with 2 Root
|
||||
Ports. Each of those Root Ports are connected to 2-way switches with endpoints
|
||||
connected to those downstream ports for a total of 8 endpoints::
|
||||
|
||||
# cxl list -BEMPu -b cxl_test
|
||||
{
|
||||
"bus":"root3",
|
||||
"provider":"cxl_test",
|
||||
"ports:root3":[
|
||||
{
|
||||
"port":"port5",
|
||||
"host":"cxl_host_bridge.1",
|
||||
"ports:port5":[
|
||||
{
|
||||
"port":"port8",
|
||||
"host":"cxl_switch_uport.1",
|
||||
"endpoints:port8":[
|
||||
{
|
||||
"endpoint":"endpoint9",
|
||||
"host":"mem2",
|
||||
"memdev":{
|
||||
"memdev":"mem2",
|
||||
"pmem_size":"256.00 MiB (268.44 MB)",
|
||||
"ram_size":"256.00 MiB (268.44 MB)",
|
||||
"serial":"0x1",
|
||||
"numa_node":1,
|
||||
"host":"cxl_mem.1"
|
||||
}
|
||||
},
|
||||
{
|
||||
"endpoint":"endpoint15",
|
||||
"host":"mem6",
|
||||
"memdev":{
|
||||
"memdev":"mem6",
|
||||
"pmem_size":"256.00 MiB (268.44 MB)",
|
||||
"ram_size":"256.00 MiB (268.44 MB)",
|
||||
"serial":"0x5",
|
||||
"numa_node":1,
|
||||
"host":"cxl_mem.5"
|
||||
}
|
||||
}
|
||||
]
|
||||
},
|
||||
{
|
||||
"port":"port12",
|
||||
"host":"cxl_switch_uport.3",
|
||||
"endpoints:port12":[
|
||||
{
|
||||
"endpoint":"endpoint17",
|
||||
"host":"mem8",
|
||||
"memdev":{
|
||||
"memdev":"mem8",
|
||||
"pmem_size":"256.00 MiB (268.44 MB)",
|
||||
"ram_size":"256.00 MiB (268.44 MB)",
|
||||
"serial":"0x7",
|
||||
"numa_node":1,
|
||||
"host":"cxl_mem.7"
|
||||
}
|
||||
},
|
||||
{
|
||||
"endpoint":"endpoint13",
|
||||
"host":"mem4",
|
||||
"memdev":{
|
||||
"memdev":"mem4",
|
||||
"pmem_size":"256.00 MiB (268.44 MB)",
|
||||
"ram_size":"256.00 MiB (268.44 MB)",
|
||||
"serial":"0x3",
|
||||
"numa_node":1,
|
||||
"host":"cxl_mem.3"
|
||||
}
|
||||
}
|
||||
]
|
||||
}
|
||||
]
|
||||
},
|
||||
{
|
||||
"port":"port4",
|
||||
"host":"cxl_host_bridge.0",
|
||||
"ports:port4":[
|
||||
{
|
||||
"port":"port6",
|
||||
"host":"cxl_switch_uport.0",
|
||||
"endpoints:port6":[
|
||||
{
|
||||
"endpoint":"endpoint7",
|
||||
"host":"mem1",
|
||||
"memdev":{
|
||||
"memdev":"mem1",
|
||||
"pmem_size":"256.00 MiB (268.44 MB)",
|
||||
"ram_size":"256.00 MiB (268.44 MB)",
|
||||
"serial":"0",
|
||||
"numa_node":0,
|
||||
"host":"cxl_mem.0"
|
||||
}
|
||||
},
|
||||
{
|
||||
"endpoint":"endpoint14",
|
||||
"host":"mem5",
|
||||
"memdev":{
|
||||
"memdev":"mem5",
|
||||
"pmem_size":"256.00 MiB (268.44 MB)",
|
||||
"ram_size":"256.00 MiB (268.44 MB)",
|
||||
"serial":"0x4",
|
||||
"numa_node":0,
|
||||
"host":"cxl_mem.4"
|
||||
}
|
||||
}
|
||||
]
|
||||
},
|
||||
{
|
||||
"port":"port10",
|
||||
"host":"cxl_switch_uport.2",
|
||||
"endpoints:port10":[
|
||||
{
|
||||
"endpoint":"endpoint16",
|
||||
"host":"mem7",
|
||||
"memdev":{
|
||||
"memdev":"mem7",
|
||||
"pmem_size":"256.00 MiB (268.44 MB)",
|
||||
"ram_size":"256.00 MiB (268.44 MB)",
|
||||
"serial":"0x6",
|
||||
"numa_node":0,
|
||||
"host":"cxl_mem.6"
|
||||
}
|
||||
},
|
||||
{
|
||||
"endpoint":"endpoint11",
|
||||
"host":"mem3",
|
||||
"memdev":{
|
||||
"memdev":"mem3",
|
||||
"pmem_size":"256.00 MiB (268.44 MB)",
|
||||
"ram_size":"256.00 MiB (268.44 MB)",
|
||||
"serial":"0x2",
|
||||
"numa_node":0,
|
||||
"host":"cxl_mem.2"
|
||||
}
|
||||
}
|
||||
]
|
||||
}
|
||||
]
|
||||
}
|
||||
]
|
||||
}
|
||||
|
||||
In that listing each "root", "port", and "endpoint" object correspond a kernel
|
||||
'struct cxl_port' object. A 'cxl_port' is a device that can decode CXL.mem to
|
||||
its descendants. So "root" claims non-PCIe enumerable platform decode ranges and
|
||||
decodes them to "ports", "ports" decode to "endpoints", and "endpoints"
|
||||
represent the decode from SPA (System Physical Address) to DPA (Device Physical
|
||||
Address).
|
||||
|
||||
Continuing the RAID analogy, disks have both topology metadata and on device
|
||||
metadata that determine RAID set assembly. CXL Port topology and CXL Port link
|
||||
status is metadata for CXL.mem set assembly. The CXL Port topology is enumerated
|
||||
by the arrival of a CXL.mem device. I.e. unless and until the PCIe core attaches
|
||||
the cxl_pci driver to a CXL Memory Expander there is no role for CXL Port
|
||||
objects. Conversely for hot-unplug / removal scenarios, there is no need for
|
||||
the Linux PCI core to tear down switch-level CXL resources because the endpoint
|
||||
->remove() event cleans up the port data that was established to support that
|
||||
Memory Expander.
|
||||
|
||||
The port metadata and potential decode schemes that a give memory device may
|
||||
participate can be determined via a command like::
|
||||
|
||||
# cxl list -BDMu -d root -m mem3
|
||||
{
|
||||
"bus":"root3",
|
||||
"provider":"cxl_test",
|
||||
"decoders:root3":[
|
||||
{
|
||||
"decoder":"decoder3.1",
|
||||
"resource":"0x8030000000",
|
||||
"size":"512.00 MiB (536.87 MB)",
|
||||
"volatile_capable":true,
|
||||
"nr_targets":2
|
||||
},
|
||||
{
|
||||
"decoder":"decoder3.3",
|
||||
"resource":"0x8060000000",
|
||||
"size":"512.00 MiB (536.87 MB)",
|
||||
"pmem_capable":true,
|
||||
"nr_targets":2
|
||||
},
|
||||
{
|
||||
"decoder":"decoder3.0",
|
||||
"resource":"0x8020000000",
|
||||
"size":"256.00 MiB (268.44 MB)",
|
||||
"volatile_capable":true,
|
||||
"nr_targets":1
|
||||
},
|
||||
{
|
||||
"decoder":"decoder3.2",
|
||||
"resource":"0x8050000000",
|
||||
"size":"256.00 MiB (268.44 MB)",
|
||||
"pmem_capable":true,
|
||||
"nr_targets":1
|
||||
}
|
||||
],
|
||||
"memdevs:root3":[
|
||||
{
|
||||
"memdev":"mem3",
|
||||
"pmem_size":"256.00 MiB (268.44 MB)",
|
||||
"ram_size":"256.00 MiB (268.44 MB)",
|
||||
"serial":"0x2",
|
||||
"numa_node":0,
|
||||
"host":"cxl_mem.2"
|
||||
}
|
||||
]
|
||||
}
|
||||
|
||||
...which queries the CXL topology to ask "given CXL Memory Expander with a kernel
|
||||
device name of 'mem3' which platform level decode ranges may this device
|
||||
participate". A given expander can participate in multiple CXL.mem interleave
|
||||
sets simultaneously depending on how many decoder resource it has. In this
|
||||
example mem3 can participate in one or more of a PMEM interleave that spans to
|
||||
Host Bridges, a PMEM interleave that targets a single Host Bridge, a Volatile
|
||||
memory interleave that spans 2 Host Bridges, and a Volatile memory interleave
|
||||
that only targets a single Host Bridge.
|
||||
|
||||
Conversely the memory devices that can participate in a given platform level
|
||||
decode scheme can be determined via a command like the following::
|
||||
|
||||
# cxl list -MDu -d 3.2
|
||||
[
|
||||
{
|
||||
"memdevs":[
|
||||
{
|
||||
"memdev":"mem1",
|
||||
"pmem_size":"256.00 MiB (268.44 MB)",
|
||||
"ram_size":"256.00 MiB (268.44 MB)",
|
||||
"serial":"0",
|
||||
"numa_node":0,
|
||||
"host":"cxl_mem.0"
|
||||
},
|
||||
{
|
||||
"memdev":"mem5",
|
||||
"pmem_size":"256.00 MiB (268.44 MB)",
|
||||
"ram_size":"256.00 MiB (268.44 MB)",
|
||||
"serial":"0x4",
|
||||
"numa_node":0,
|
||||
"host":"cxl_mem.4"
|
||||
},
|
||||
{
|
||||
"memdev":"mem7",
|
||||
"pmem_size":"256.00 MiB (268.44 MB)",
|
||||
"ram_size":"256.00 MiB (268.44 MB)",
|
||||
"serial":"0x6",
|
||||
"numa_node":0,
|
||||
"host":"cxl_mem.6"
|
||||
},
|
||||
{
|
||||
"memdev":"mem3",
|
||||
"pmem_size":"256.00 MiB (268.44 MB)",
|
||||
"ram_size":"256.00 MiB (268.44 MB)",
|
||||
"serial":"0x2",
|
||||
"numa_node":0,
|
||||
"host":"cxl_mem.2"
|
||||
}
|
||||
]
|
||||
},
|
||||
{
|
||||
"root decoders":[
|
||||
{
|
||||
"decoder":"decoder3.2",
|
||||
"resource":"0x8050000000",
|
||||
"size":"256.00 MiB (268.44 MB)",
|
||||
"pmem_capable":true,
|
||||
"nr_targets":1
|
||||
}
|
||||
]
|
||||
}
|
||||
]
|
||||
|
||||
...where the naming scheme for decoders is "decoder<port_id>.<instance_id>".
|
||||
|
||||
Driver Infrastructure
|
||||
=====================
|
||||
|
||||
@@ -28,6 +325,11 @@ CXL Memory Device
|
||||
.. kernel-doc:: drivers/cxl/pci.c
|
||||
:internal:
|
||||
|
||||
CXL Port
|
||||
--------
|
||||
.. kernel-doc:: drivers/cxl/port.c
|
||||
:doc: cxl port
|
||||
|
||||
CXL Core
|
||||
--------
|
||||
.. kernel-doc:: drivers/cxl/cxl.h
|
||||
|
||||
Reference in New Issue
Block a user