On Sat, 26 Jul 2025 20:50:35 +0800
peng guo <engguop...@buaa.edu.cn> wrote:

> On Fri, Jul 25, 2025 at 02:53:37PM +0100, Jonathan Cameron wrote:
> > On Fri, 18 Jul 2025 21:35:45 +0800
> > peng guo <engguop...@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 <engguop...@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.
> >   
> 
> Checking `is_enabled` instead of `cxl_resv_end` makes sense.
> 
> Building on that, I wonder if it would be worthwhile to move the assignment 
> of 
> `res_mem_end` outside the conditional block. Then simply use `res_mem_end` 
> itself as the condition. That would eliminate the need to check `is_enabled` 
> directly in this spot and simplify the logic slighly. The benefit may 
> be minor, but it might help unify the logic around how `res_mem_end` is used.

That might indeed end up cleaner.

Jonathan


> 
> I will make an effort to identify the appropriate fixes tags related to this. 
> My 
> guess is that it relates to the patch where the CXL windows were originally 
> introduced and activated in the system.
> 
> > > ---
> > >  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;
> > >    
> 
> 


Reply via email to