From: Itaru Kitayama <itaru.kitayama@linux.dev>
To: Jonathan Cameron <Jonathan.Cameron@huawei.com>
Cc: qemu-devel@nongnu.org, "Fan Ni" <fan.ni@samsung.com>,
"Peter Maydell" <peter.maydell@linaro.org>,
mst@redhat.com, linuxarm@huawei.com, linux-cxl@vger.kernel.org,
qemu-arm@nongnu.org,
"Yuquan Wang" <wangyuquan1236@phytium.com.cn>,
"Philippe Mathieu-Daudé" <philmd@linaro.org>,
"Alireza Sanaee" <alireza.sanaee@huawei.com>
Subject: Re: [PATCH v14 2/5] hw/cxl: Make the CXL fixed memory windows devices.
Date: Tue, 10 Jun 2025 07:53:31 +0900 [thread overview]
Message-ID: <aEdl6xvqyOsU+Z2S@vm4> (raw)
In-Reply-To: <20250529160801.00003ade@huawei.com>
On Thu, May 29, 2025 at 04:08:01PM +0100, Jonathan Cameron wrote:
> On Wed, 28 May 2025 12:07:23 +0100
> Jonathan Cameron <Jonathan.Cameron@huawei.com> wrote:
>
> > Previously these somewhat device like structures were tracked using a list
> > in the CXLState in each machine. This is proving restrictive in a few
> > cases where we need to iterate through these without being aware of the
> > machine type. Just make them sysbus devices.
> >
> > Restrict them to not user created as they need to be visible to early
> > stages of machine init given effects on the memory map.
> >
> > This change both simplifies state tracking and enables features needed
> > for performance optimization and hotness tracking by making it possible
> > to retrieve the fixed memory window on actions elsewhere in the topology.
> >
> > In some cases the ordering of the Fixed Memory Windows matters.
> > For those utility functions provide a GSList sorted by the window index.
> > This ensures that we get consistency across:
> > - ordering in the command line
> > - ordering of the host PA ranges
> > - ordering of ACPI CEDT structures describing the CFMWS.
> >
> > Other aspects don't have this constraint. For those direct iteration
> > of the underlying hash structures is fine.
> >
> > Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
>
> I'll not post v15 for a while to give time for review, but I just realized
> this snippet was in a patch I was carrying on top of this and should have
> been in this patch.
>
> diff --git a/include/hw/cxl/cxl.h b/include/hw/cxl/cxl.h
> index a610795c87..de66ab8c35 100644
> --- a/include/hw/cxl/cxl.h
> +++ b/include/hw/cxl/cxl.h
> @@ -46,7 +46,6 @@ typedef struct CXLState {
> bool is_enabled;
> MemoryRegion host_mr;
> unsigned int next_mr_idx;
> - GList *fixed_windows;
> CXLFixedMemoryWindowOptionsList *cfmw_list;
> } CXLState;
With this one line removed on top of v14, today's Dave's cxl/next kernel makes
cxl test suite ran through without a single failure.
Tested-by: Itaru Kitayama <itaru.kitayama@fujitsu.com>
Jonathan, Zhi jian of Fujitsu gave you feedback on the QEMU core CXL emulation code,
are you still waiting on any other reviewers to take a look at the series v14 (or
v14-ish)?
Thanks,
Itaru.
>
next prev parent reply other threads:[~2025-06-09 22:53 UTC|newest]
Thread overview: 18+ messages / expand[flat|nested] mbox.gz Atom feed top
2025-05-28 11:07 [PATCH v14 0/5] arm/virt: CXL support via pxb_cxl Jonathan Cameron
2025-05-28 11:07 ` [PATCH v14 1/5] hw/cxl-host: Add an index field to CXLFixedMemoryWindow Jonathan Cameron
2025-05-28 11:07 ` [PATCH v14 2/5] hw/cxl: Make the CXL fixed memory windows devices Jonathan Cameron
2025-05-29 15:08 ` Jonathan Cameron
2025-06-09 22:53 ` Itaru Kitayama [this message]
2025-06-10 9:18 ` Jonathan Cameron
2025-06-09 1:17 ` Zhijian Li (Fujitsu)
2025-05-28 11:07 ` [PATCH v14 3/5] hw/cxl-host: Allow split of establishing memory address and mmio setup Jonathan Cameron
2025-06-09 1:15 ` Zhijian Li (Fujitsu)
2025-06-12 12:50 ` Jonathan Cameron
2025-05-28 11:07 ` [PATCH v14 4/5] hw/arm/virt: Basic CXL enablement on pci_expander_bridge instances pxb-cxl Jonathan Cameron
2025-05-28 11:07 ` [PATCH v14 5/5] qtest/cxl: Add aarch64 virt test for CXL Jonathan Cameron
2025-06-04 14:32 ` Alireza Sanaee
2025-05-28 21:57 ` [PATCH v14 0/5] arm/virt: CXL support via pxb_cxl Itaru Kitayama
2025-05-29 9:08 ` Jonathan Cameron
2025-05-29 5:13 ` Itaru Kitayama
2025-06-12 13:13 ` Jonathan Cameron
2025-06-09 1:41 ` Zhijian Li (Fujitsu)
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=aEdl6xvqyOsU+Z2S@vm4 \
--to=itaru.kitayama@linux.dev \
--cc=Jonathan.Cameron@huawei.com \
--cc=alireza.sanaee@huawei.com \
--cc=fan.ni@samsung.com \
--cc=linux-cxl@vger.kernel.org \
--cc=linuxarm@huawei.com \
--cc=mst@redhat.com \
--cc=peter.maydell@linaro.org \
--cc=philmd@linaro.org \
--cc=qemu-arm@nongnu.org \
--cc=qemu-devel@nongnu.org \
--cc=wangyuquan1236@phytium.com.cn \
/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).