[PATCH qemu 0/6] hw/cxl: Link speed and width control

Jonathan Cameron via posted 6 patches 2 months, 1 week ago
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(-)
[PATCH qemu 0/6] hw/cxl: Link speed and width control
Posted by Jonathan Cameron via 2 months, 1 week ago
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(-)

-- 
2.43.0
Re: [PATCH qemu 0/6] hw/cxl: Link speed and width control
Posted by Jonathan Cameron via 3 weeks, 4 days ago
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(-)
>