On Fri, Oct 31, 2025 at 10:13:15AM +0000, Jonathan Cameron wrote:
> On Wed, 29 Oct 2025 17:10:55 +0300
> Michael Tokarev <[email protected]> wrote:
> 
> > 29.10.2025 14:01, Jonathan Cameron via пишет:
> > > On Tue, 28 Oct 2025 22:26:12 +0300
> > > Michael Tokarev <[email protected]> wrote:
> > >   
> > >> On 10/6/25 20:08, Michael Tokarev wrote:  
> > >>> On 10/5/25 22:17, Michael S. Tsirkin wrote:  
> > >>>> From: peng guo <[email protected]>
> > >>>>
> > >>>> 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 <[email protected]>
> > >>>> Reviewed-by: Michael S. Tsirkin <[email protected]>
> > >>>> Message-ID: <[email protected]>
> > >>>> Signed-off-by: Michael S. Tsirkin <[email protected]>
> > >>>> ---
> > >>>>    hw/i386/pc.c | 20 +++++++++++---------
> > >>>>    1 file changed, 11 insertions(+), 9 deletions(-)  
> > >>>
> > >>> Hi!
> > >>>
> > >>> Is it qemu-stable material (10.0.x & 10.1.x)?  
> > > 
> > > I think it does make sense for stable.  
> > 
> > Aha.  I remember now why I had this question to begin with.
> > 
> > If it should be applied to 10.0.x series too (which is an LTS series),
> > I need help back-porting it before commit 8b1c560937467d0d9
> > "hw/i386/pc: Remove PCMachineClass::broken_reserved_end field"
> > which touches the same code.
> 
> I don't have strong opinions either way. peng guo, if you happen
> to be in a position to backport and test with QEMU LTS that would be
> great.
> 
> Jonathan
Hi Jonathan,

I'll move forward with back-porting and testing with the QEMU LTS as
soon as possible.

Apologies for the delayed reply. I didn't have a computer and env before
because i was on vacation.

BR
Peng.

> 
> > 
> > If it's worth the effort to begin with.
> > 
> > Meanwhile I picked it up for 10.1.x.
> > 
> > Thank you!
> > 
> > /mjt


Reply via email to