From: Jonathan Cameron via <qemu-devel@nongnu.org>
To: Fan Ni <fan.ni@samsung.com>
Cc: "qemu-devel@nongnu.org" <qemu-devel@nongnu.org>,
Ben Widawsky <bwidawsk@kernel.org>,
"linux-cxl@vger.kernel.org" <linux-cxl@vger.kernel.org>,
"linuxarm@huawei.com" <linuxarm@huawei.com>,
Ira Weiny <ira.weiny@intel.com>,
Dave Jiang <dave.jiang@intel.com>,
"alison.schofield@intel.com" <alison.schofield@intel.com>,
Adam Manzanares <a.manzanares@samsung.com>,
"dave@stgolabs.net" <dave@stgolabs.net>
Subject: Re: [RFC PATCH 0/2] hw/cxl: Passthrough HDM decoder emulation
Date: Tue, 24 Jan 2023 09:47:20 +0000 [thread overview]
Message-ID: <20230124094720.00005c97@Huawei.com> (raw)
In-Reply-To: <20230123175315.GA168673@bgt-140510-bm03>
On Mon, 23 Jan 2023 17:53:24 +0000
Fan Ni <fan.ni@samsung.com> wrote:
> On Mon, Jan 23, 2023 at 12:17:10PM +0000, Jonathan Cameron wrote:
>
>
>
> > Until now, testing using CXL has relied up always using two root ports
> > below a host bridge, to work around a current assumption in the Linux
> > kernel support that, in the single root port case, the implementation will
> > use the allowed passthrough decoder implementation choice. If that choice
> > is made all accesses are routed from the host bridge to the single
> > root port that is present. Effectively we have a pass through decoder
> > (it is called that in the kernel driver).
> >
> > This patch series implements that functionality and makes it the default
> > See patch 2 for a discussion of why I think we can make this change
> > without backwards compatibility issues (basically if it didn't work before
> > who are we breaking by making it work?)
> >
> > Whilst this limitation has been known since the initial QEMU patch
> > postings / kernel CXL region support, Fan Ni Ran into it recently reminding
> > me that we should solve it.
> >
> > https://lore.kernel.org/linux-cxl/20230113171044.GA24788@bgt-140510-bm03/
> >
> > Tree with a large set of patches before this at:
> > https://gitlab.com/jic23/qemu/-/tree/cxl-2023-01-20
> >
> > I've done some basic testing, though I did hit what appears to be
> > a kernel race on region bring up of existing region / namespace in a
> > 1HB 2RP 2EP test case. That is proving hard to replicate consistently
> > but doesn't seem to have anything to do with the emulation other than
> > perhaps we are opening up a race by responding slowly to something.
> >
> > Jonathan Cameron (2):
> > hw/pci: Add pcie_count_ds_port() and pcie_find_port_first() helpers
> > hw/pxb-cxl: Support passthrough HDM Decoders unless overridden
> >
> > hw/cxl/cxl-host.c | 31 +++++++++++++--------
> > hw/pci-bridge/pci_expander_bridge.c | 43 +++++++++++++++++++++++++----
> > hw/pci/pcie_port.c | 38 +++++++++++++++++++++++++
> > include/hw/cxl/cxl.h | 1 +
> > include/hw/cxl/cxl_component.h | 1 +
> > include/hw/pci/pci_bridge.h | 1 +
> > include/hw/pci/pcie_port.h | 2 ++
> > 7 files changed, 100 insertions(+), 17 deletions(-)
> >
> > --
> > 2.37.2
> >
> >
> Tried three different cxl topology setups (1HB1RP, 1HB2RP2Memdev, with
> switch), the patch works fine for me.
> Btw, there seem some format issues with the patch, got warnings with
> checkpatch tool.
Thanks! I'll clean those up. Was being lazy on it as it's an RFC for
now :) Given this is small and useful I'll probably pull it nearer the
head of the queue.
When I repost, if you could give a Tested-by tag that would be great!
Thanks,
Jonathan
next prev parent reply other threads:[~2023-01-24 9:48 UTC|newest]
Thread overview: 6+ messages / expand[flat|nested] mbox.gz Atom feed top
2023-01-23 12:17 [RFC PATCH 0/2] hw/cxl: Passthrough HDM decoder emulation Jonathan Cameron via
2023-01-23 12:17 ` [RFC PATCH 1/2] hw/pci: Add pcie_count_ds_port() and pcie_find_port_first() helpers Jonathan Cameron via
2023-01-23 12:17 ` [RFC PATCH 2/2] hw/pxb-cxl: Support passthrough HDM Decoders unless overridden Jonathan Cameron via
[not found] ` <CGME20230123175325uscas1p134d834ae3636c7c56e93299c01a4f351@uscas1p1.samsung.com>
2023-01-23 17:53 ` [RFC PATCH 0/2] hw/cxl: Passthrough HDM decoder emulation Fan Ni
2023-01-24 9:47 ` Jonathan Cameron via [this message]
2023-01-24 17:00 ` Fan Ni
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=20230124094720.00005c97@Huawei.com \
--to=qemu-devel@nongnu.org \
--cc=Jonathan.Cameron@Huawei.com \
--cc=a.manzanares@samsung.com \
--cc=alison.schofield@intel.com \
--cc=bwidawsk@kernel.org \
--cc=dave.jiang@intel.com \
--cc=dave@stgolabs.net \
--cc=fan.ni@samsung.com \
--cc=ira.weiny@intel.com \
--cc=linux-cxl@vger.kernel.org \
--cc=linuxarm@huawei.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).