qemu-devel.nongnu.org archive mirror
 help / color / mirror / Atom feed
From: Jonathan Cameron via <qemu-devel@nongnu.org>
To: <mst@redhat.com>, Markus Armbruster <armbru@redhat.com>,
	<qemu-devel@nongnu.org>
Cc: <linux-cxl@vger.kernel.org>, <marcel.apfelbaum@gmail.com>,
	Dave Jiang <dave.jiang@intel.com>,
	Huang Ying <ying.huang@intel.com>,
	Michael Roth <michael.roth@amd.com>, <fan.ni@samsung.com>,
	<linuxarm@huawei.com>
Subject: Re: [PATCH qemu 0/6] hw/cxl: Link speed and width control
Date: Tue, 29 Oct 2024 10:30:50 +0000	[thread overview]
Message-ID: <20241029102850.000052c5@huawei.com> (raw)
In-Reply-To: <20240916173518.1843023-1-Jonathan.Cameron@huawei.com>

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(-)
> 



      parent reply	other threads:[~2024-10-29 10:31 UTC|newest]

Thread overview: 11+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2024-09-16 17:35 [PATCH qemu 0/6] hw/cxl: Link speed and width control Jonathan Cameron via
2024-09-16 17:35 ` [PATCH 1/6] hw/pci-bridge/cxl_root_port: Provide x-speed and x-width properties Jonathan Cameron via
2024-10-29 16:26   ` Fan Ni
2024-09-16 17:35 ` [PATCH 2/6] hw/pci-bridge/cxl_upstream: " Jonathan Cameron via
2024-10-29 16:37   ` Fan Ni
2024-10-30 13:04     ` Jonathan Cameron via
2024-09-16 17:35 ` [PATCH 3/6] hw/pcie: Factor out PCI Express link register filling common to EP Jonathan Cameron via
2024-09-16 17:35 ` [PATCH 4/6] hw/pcie: Provide a utility function for control of EP / SW USP link Jonathan Cameron via
2024-09-16 17:35 ` [PATCH 5/6] hw/mem/cxl-type3: Add properties to control link speed and width Jonathan Cameron via
2024-09-16 17:35 ` [PATCH 6/6] hw/pci-bridge/cxl-upstream: " Jonathan Cameron via
2024-10-29 10:30 ` Jonathan Cameron via [this message]

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20241029102850.000052c5@huawei.com \
    --to=qemu-devel@nongnu.org \
    --cc=Jonathan.Cameron@Huawei.com \
    --cc=armbru@redhat.com \
    --cc=dave.jiang@intel.com \
    --cc=fan.ni@samsung.com \
    --cc=linux-cxl@vger.kernel.org \
    --cc=linuxarm@huawei.com \
    --cc=marcel.apfelbaum@gmail.com \
    --cc=michael.roth@amd.com \
    --cc=mst@redhat.com \
    --cc=ying.huang@intel.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).