From: Jonathan Cameron via <qemu-devel@nongnu.org>
To: peng guo <engguopeng@buaa.edu.cn>
Cc: <mst@redhat.com>, <marcel.apfelbaum@gmail.com>,
<pbonzini@redhat.com>, <richard.henderson@linaro.org>,
<eduardo@habkost.net>, <qemu-devel@nongnu.org>,
<wyguopeng@163.com>
Subject: Re: [PATCH v2] hw/i386/pc: Avoid overlap between CXL window and PCI 64bit BARs in QEMU
Date: Mon, 4 Aug 2025 15:58:22 +0100 [thread overview]
Message-ID: <20250804155822.000027e2@huawei.com> (raw)
In-Reply-To: <20250804142421.153126-1-engguopeng@buaa.edu.cn>
On Mon, 4 Aug 2025 22:24:21 +0800
peng guo <engguopeng@buaa.edu.cn> wrote:
> When using a CXL Type 3 device together with a virtio 9p device in QEMU on a
> physical server, the 9p device fails to initialize properly. The kernel reports
> the following error:
>
> virtio: device uses modern interface but does not have VIRTIO_F_VERSION_1
> 9pnet_virtio virtio0: probe with driver 9pnet_virtio failed with error -22
>
> Further investigation revealed that the 64-bit BAR space assigned to the 9pnet
> device was overlapped by the memory window allocated for the CXL devices. As a
> result, the kernel could not correctly access the BAR region, causing the
> virtio device to malfunction.
>
> An excerpt from /proc/iomem shows:
>
> 480010000-cffffffff : CXL Window 0
> 480010000-4bfffffff : PCI Bus 0000:00
> 4c0000000-4c01fffff : PCI Bus 0000:0c
> 4c0000000-4c01fffff : PCI Bus 0000:0d
> 4c0200000-cffffffff : PCI Bus 0000:00
> 4c0200000-4c0203fff : 0000:00:03.0
> 4c0200000-4c0203fff : virtio-pci-modern
>
> To address this issue, this patch adds the reserved memory end calculation
> for cxl devices to reserve sufficient address space and ensure that CXL memory
> windows are allocated beyond all PCI 64-bit BARs. This prevents overlap with
> 64-bit BARs regions such as those used by virtio or other pcie devices,
> resolving the conflict.
>
> QEMU Build Configuration:
>
> ./configure --prefix=/home/work/qemu_master/build/ \
> --target-list=x86_64-softmmu \
> --enable-kvm \
> --enable-virtfs
>
> QEMU Boot Command:
>
> sudo /home/work/qemu_master/qemu/build/qemu-system-x86_64 \
> -nographic -machine q35,cxl=on -enable-kvm -m 16G -smp 8 \
> -hda /home/work/gp_qemu/rootfs.img \
> -virtfs local,path=/home/work/gp_qemu/share,mount_tag=host0,security_model=passthrough,id=host0 \
> -kernel /home/work/linux_output/arch/x86/boot/bzImage \
> --append "console=ttyS0 crashkernel=256M root=/dev/sda rootfstype=ext4 rw loglevel=8" \
> -object memory-backend-ram,id=vmem0,share=on,size=4096M \
> -device pxb-cxl,bus_nr=12,bus=pcie.0,id=cxl.1 \
> -device cxl-rp,port=0,bus=cxl.1,id=root_port13,chassis=0,slot=2 \
> -device cxl-type3,bus=root_port13,volatile-memdev=vmem0,id=cxl-vmem0,sn=0x123456789 \
> -M cxl-fmw.0.targets.0=cxl.1,cxl-fmw.0.size=4G
>
> Fixes: 03b39fcf64bc ("hw/cxl: Make the CXL fixed memory window setup a machine parameter")
> Signed-off-by: peng guo <engguopeng@buaa.edu.cn>
> ---
> v1 -> v2: Make the patch clearer and add fixes
>
> hw/i386/pc.c | 18 +++++++++---------
> 1 file changed, 9 insertions(+), 9 deletions(-)
>
> diff --git a/hw/i386/pc.c b/hw/i386/pc.c
> index 2f58e73d3347..0f10f6edd23e 100644
> --- a/hw/i386/pc.c
> +++ b/hw/i386/pc.c
> @@ -975,16 +975,16 @@ void pc_memory_init(PCMachineState *pcms,
>
> rom_set_fw(fw_cfg);
>
> - if (machine->device_memory) {
> - uint64_t *val = g_malloc(sizeof(*val));
> - uint64_t res_mem_end;
> + uint64_t res_mem_end = 0;
Looking at local code style, it's declarations at top of scope not
inline. That's what the coding style suggests as well:
https://qemu-project.gitlab.io/qemu/devel/style.html#declarations
Given we do want that 0 to be obviously set near here, you could go
with a final
} else {
res_mem_end = 0;
}
And not initialize at declaration (which will be up a long way).
> + if (pcms->cxl_devices_state.is_enabled) {
> + res_mem_end = cxl_resv_end;
> + } else if (machine->device_memory) {
> + res_mem_end = machine->device_memory->base
> + + memory_region_size(&machine->device_memory->mr);
> + }
>
> - if (pcms->cxl_devices_state.is_enabled) {
> - res_mem_end = cxl_resv_end;
> - } else {
> - res_mem_end = machine->device_memory->base
> - + memory_region_size(&machine->device_memory->mr);
> - }
> + if (res_mem_end) {
> + uint64_t *val = g_malloc(sizeof(*val));
> *val = cpu_to_le64(ROUND_UP(res_mem_end, 1 * GiB));
> fw_cfg_add_file(fw_cfg, "etc/reserved-memory-end", val, sizeof(*val));
> }
prev parent reply other threads:[~2025-08-04 16:49 UTC|newest]
Thread overview: 2+ messages / expand[flat|nested] mbox.gz Atom feed top
2025-08-04 14:24 [PATCH v2] hw/i386/pc: Avoid overlap between CXL window and PCI 64bit BARs in QEMU peng guo via
2025-08-04 14:58 ` 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=20250804155822.000027e2@huawei.com \
--to=qemu-devel@nongnu.org \
--cc=Jonathan.Cameron@huawei.com \
--cc=eduardo@habkost.net \
--cc=engguopeng@buaa.edu.cn \
--cc=marcel.apfelbaum@gmail.com \
--cc=mst@redhat.com \
--cc=pbonzini@redhat.com \
--cc=richard.henderson@linaro.org \
--cc=wyguopeng@163.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).