| Message ID | 20240916173518.1843023-1-Jonathan.Cameron@huawei.com (mailing list archive) |
|---|---|
| Headers | show |
| Series | hw/cxl: Link speed and width control | expand |
Gentle ping. I'm less worried about hitting this cycle for this than the Generic Port work but this is the missing piece for ensuring we can test the kernel code that builds NUMA description for CXL devices. I'd like to have the full solution for that upstream. The bulk of this is a refactor with functional changes limited to the CXL components. Jonathan On Mon, 16 Sep 2024 18:35:12 +0100 Jonathan Cameron <Jonathan.Cameron@huawei.com> wrote: > Changes since RFC: > - rebase > > Question: > - I could enable this for all PCIe device (including ports). > Does that makes sense, or is it better to limit this to my cases? > It is quite easy to build broken setups (downstream device reports > faster link than the port etc) because QEMU 'link' training' is > simplistic. I'm not sure it is worth making it more clever. > > The Generic Ports support added the ability to describe the bandwidth and > Latency within a host to a CXL host bridge. To be able to test the of the > discovery path used by Linux [1] we also need to be able to create > bottlenecks at difference places in the topology. There are two parts to > this > * CXL link characteristics as described by PCI Express Capability Link > status etc. > * Bandwidth and latency across CXL Switches (via CDAT data from the switch > USP) > * Bandwidth and latency from the CXL type 3 device port to the actual > memory (Via CDAT data from the EP). > > Currently we have fixed values for the CXL CDAT tables, and to test this > I recommend changing those as per the patch at the end of this cover letter > (so they aren't always the bottleneck). Making those configurable will be > handled in a future patch set. > > RFC has a set of examples but those were to help testing the kernel code > rather than providing much info for QEMU review so I haven't repeated > them ehre. > > https://lore.kernel.org/qemu-devel/20240712122414.1448284-1-Jonathan.Cameron@huawei.com/ > > Jonathan Cameron (6): > hw/pci-bridge/cxl_root_port: Provide x-speed and x-width properties. > hw/pci-bridge/cxl_upstream: Provide x-speed and x-width properties. > hw/pcie: Factor out PCI Express link register filling common to EP. > hw/pcie: Provide a utility function for control of EP / SW USP link > hw/mem/cxl-type3: Add properties to control link speed and width > hw/pci-bridge/cxl-upstream: Add properties to control link speed and > width > > include/hw/cxl/cxl_device.h | 4 + > include/hw/pci-bridge/cxl_upstream_port.h | 4 + > include/hw/pci/pcie.h | 2 + > hw/mem/cxl_type3.c | 6 ++ > hw/pci-bridge/cxl_downstream.c | 23 +++-- > hw/pci-bridge/cxl_root_port.c | 5 ++ > hw/pci-bridge/cxl_upstream.c | 6 ++ > hw/pci/pcie.c | 105 ++++++++++++++-------- > 8 files changed, 103 insertions(+), 52 deletions(-) >
Changes since RFC: - rebase Question: - I could enable this for all PCIe device (including ports). Does that makes sense, or is it better to limit this to my cases? It is quite easy to build broken setups (downstream device reports faster link than the port etc) because QEMU 'link' training' is simplistic. I'm not sure it is worth making it more clever. The Generic Ports support added the ability to describe the bandwidth and Latency within a host to a CXL host bridge. To be able to test the of the discovery path used by Linux [1] we also need to be able to create bottlenecks at difference places in the topology. There are two parts to this * CXL link characteristics as described by PCI Express Capability Link status etc. * Bandwidth and latency across CXL Switches (via CDAT data from the switch USP) * Bandwidth and latency from the CXL type 3 device port to the actual memory (Via CDAT data from the EP). Currently we have fixed values for the CXL CDAT tables, and to test this I recommend changing those as per the patch at the end of this cover letter (so they aren't always the bottleneck). Making those configurable will be handled in a future patch set. RFC has a set of examples but those were to help testing the kernel code rather than providing much info for QEMU review so I haven't repeated them ehre. https://lore.kernel.org/qemu-devel/20240712122414.1448284-1-Jonathan.Cameron@huawei.com/ Jonathan Cameron (6): hw/pci-bridge/cxl_root_port: Provide x-speed and x-width properties. hw/pci-bridge/cxl_upstream: Provide x-speed and x-width properties. hw/pcie: Factor out PCI Express link register filling common to EP. hw/pcie: Provide a utility function for control of EP / SW USP link hw/mem/cxl-type3: Add properties to control link speed and width hw/pci-bridge/cxl-upstream: Add properties to control link speed and width include/hw/cxl/cxl_device.h | 4 + include/hw/pci-bridge/cxl_upstream_port.h | 4 + include/hw/pci/pcie.h | 2 + hw/mem/cxl_type3.c | 6 ++ hw/pci-bridge/cxl_downstream.c | 23 +++-- hw/pci-bridge/cxl_root_port.c | 5 ++ hw/pci-bridge/cxl_upstream.c | 6 ++ hw/pci/pcie.c | 105 ++++++++++++++-------- 8 files changed, 103 insertions(+), 52 deletions(-)