From: peng guo <engguopeng@buaa.edu.cn>
To: Jonathan Cameron <Jonathan.Cameron@huawei.com>
Cc: mst@redhat.com, marcel.apfelbaum@gmail.com, pbonzini@redhat.com,
richard.henderson@linaro.org, eduardo@habkost.net,
qemu-devel@nongnu.org, linux-cxl@vger.kernel.org,
wyguopeng@163.com
Subject: Re: [PATCH] hw/i386/pc: Avoid overlap between CXL window and PCI 64bit BARs in QEMU
Date: Tue, 29 Jul 2025 20:56:37 +0800 [thread overview]
Message-ID: <aIjFBVLHOy1tp4fD@gp-VMware-Virtual-Platform> (raw)
In-Reply-To: <20250725145337.00003c91@huawei.com>
On Fri, Jul 25, 2025 at 02:53:37PM +0100, Jonathan Cameron wrote:
> On Fri, 18 Jul 2025 21:35:45 +0800
> peng guo <engguopeng@buaa.edu.cn> wrote:
>
> > When using a CXL Type 3 device together with a virtio 9p device in QEMU, the
> > 9p device fails to initialize properly. The kernel reports the following:
> >
> > 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 uses the value of `cxl_resv_end` 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
> >
> > Tested in a QEMU setup with a CXL Type 3 device and a 9pnet virtio device.
> >
> > Signed-off-by: peng guo <engguopeng@buaa.edu.cn>
> Analysis looks good.
>
> For the patch I wonder if we should match the check that follows
> for pcms->cxl_devices_state.is_enabled rather than checking cxl_resv_end
> (which is only set to non 0 if that is_enabled is set).
>
> Probably better to use a consistent condition for checking if CXL is
> there or not.
>
> We also ideally need a suitable fixes tag. I couldn't immediately find one
> so maybe it goes a long way back.
>
Would the following be the correct Fixes tag for this patch?
Fixes: 03b39fcf64bc ("hw/cxl: Make the CXL fixed memory window setup a machine parameter")
Although earlier versions already had overlapping memory regions, they didn't
affect device 64-bit BAR access.
> > ---
> > hw/i386/pc.c | 2 +-
> > 1 file changed, 1 insertion(+), 1 deletion(-)
> >
> > diff --git a/hw/i386/pc.c b/hw/i386/pc.c
> > index 2f58e73d3347..180bc615f3f0 100644
> > --- a/hw/i386/pc.c
> > +++ b/hw/i386/pc.c
> > @@ -975,7 +975,7 @@ void pc_memory_init(PCMachineState *pcms,
> >
> > rom_set_fw(fw_cfg);
> >
> > - if (machine->device_memory) {
> > + if (machine->device_memory || cxl_resv_end) {
> > uint64_t *val = g_malloc(sizeof(*val));
> > uint64_t res_mem_end;
> >
WARNING: multiple messages have this Message-ID (diff)
From: peng guo via <qemu-devel@nongnu.org>
To: Jonathan Cameron <Jonathan.Cameron@huawei.com>
Cc: mst@redhat.com, marcel.apfelbaum@gmail.com, pbonzini@redhat.com,
richard.henderson@linaro.org, eduardo@habkost.net,
qemu-devel@nongnu.org, linux-cxl@vger.kernel.org,
wyguopeng@163.com
Subject: Re: [PATCH] hw/i386/pc: Avoid overlap between CXL window and PCI 64bit BARs in QEMU
Date: Tue, 29 Jul 2025 20:56:37 +0800 [thread overview]
Message-ID: <aIjFBVLHOy1tp4fD@gp-VMware-Virtual-Platform> (raw)
In-Reply-To: <20250725145337.00003c91@huawei.com>
On Fri, Jul 25, 2025 at 02:53:37PM +0100, Jonathan Cameron wrote:
> On Fri, 18 Jul 2025 21:35:45 +0800
> peng guo <engguopeng@buaa.edu.cn> wrote:
>
> > When using a CXL Type 3 device together with a virtio 9p device in QEMU, the
> > 9p device fails to initialize properly. The kernel reports the following:
> >
> > 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 uses the value of `cxl_resv_end` 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
> >
> > Tested in a QEMU setup with a CXL Type 3 device and a 9pnet virtio device.
> >
> > Signed-off-by: peng guo <engguopeng@buaa.edu.cn>
> Analysis looks good.
>
> For the patch I wonder if we should match the check that follows
> for pcms->cxl_devices_state.is_enabled rather than checking cxl_resv_end
> (which is only set to non 0 if that is_enabled is set).
>
> Probably better to use a consistent condition for checking if CXL is
> there or not.
>
> We also ideally need a suitable fixes tag. I couldn't immediately find one
> so maybe it goes a long way back.
>
Would the following be the correct Fixes tag for this patch?
Fixes: 03b39fcf64bc ("hw/cxl: Make the CXL fixed memory window setup a machine parameter")
Although earlier versions already had overlapping memory regions, they didn't
affect device 64-bit BAR access.
> > ---
> > hw/i386/pc.c | 2 +-
> > 1 file changed, 1 insertion(+), 1 deletion(-)
> >
> > diff --git a/hw/i386/pc.c b/hw/i386/pc.c
> > index 2f58e73d3347..180bc615f3f0 100644
> > --- a/hw/i386/pc.c
> > +++ b/hw/i386/pc.c
> > @@ -975,7 +975,7 @@ void pc_memory_init(PCMachineState *pcms,
> >
> > rom_set_fw(fw_cfg);
> >
> > - if (machine->device_memory) {
> > + if (machine->device_memory || cxl_resv_end) {
> > uint64_t *val = g_malloc(sizeof(*val));
> > uint64_t res_mem_end;
> >
next prev parent reply other threads:[~2025-07-29 12:56 UTC|newest]
Thread overview: 15+ messages / expand[flat|nested] mbox.gz Atom feed top
2025-07-18 13:35 [PATCH] hw/i386/pc: Avoid overlap between CXL window and PCI 64bit BARs in QEMU peng guo
2025-07-18 13:35 ` peng guo via
2025-07-24 7:43 ` Michael S. Tsirkin
2025-07-24 7:47 ` Jonathan Cameron
2025-07-24 7:47 ` Jonathan Cameron via
2025-07-25 13:53 ` Jonathan Cameron
2025-07-25 13:53 ` Jonathan Cameron via
2025-07-26 12:50 ` peng guo
2025-07-26 12:50 ` peng guo via
2025-07-28 9:42 ` Jonathan Cameron
2025-07-28 9:42 ` Jonathan Cameron via
2025-07-26 17:01 ` Fan Ni
2025-07-29 12:56 ` peng guo [this message]
2025-07-29 12:56 ` peng guo via
2025-08-01 12:14 ` Michael S. Tsirkin
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=aIjFBVLHOy1tp4fD@gp-VMware-Virtual-Platform \
--to=engguopeng@buaa.edu.cn \
--cc=Jonathan.Cameron@huawei.com \
--cc=eduardo@habkost.net \
--cc=linux-cxl@vger.kernel.org \
--cc=marcel.apfelbaum@gmail.com \
--cc=mst@redhat.com \
--cc=pbonzini@redhat.com \
--cc=qemu-devel@nongnu.org \
--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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.