On Thu, 29 Feb 2024 at 12:52, Mattias Nissler <mniss...@rivosinc.com> wrote: > > On Thu, Feb 29, 2024 at 1:35 PM Peter Maydell <peter.mayd...@linaro.org> > wrote: > > > > On Thu, 29 Feb 2024 at 11:17, Heinrich Schuchardt > > <heinrich.schucha...@canonical.com> wrote: > > > > But yes, I'm not surprised that CXL runs into this. Heinrich, > > > > are you doing CXL testing, or is this some other workload? > > > > > > I am running the UEFI Self-Certification Tests (SCT) on EDK 2 using: > > > > > > qemu-system-riscv64 \ > > > -M virt,acpi=off -accel tcg -m 4096 \ > > > -serial mon:stdio \ > > > -device virtio-gpu-pci \ > > > -device qemu-xhci \ > > > -device usb-kbd \ > > > -drive > > > if=pflash,format=raw,unit=0,file=RISCV_VIRT_CODE.fd,readonly=on \ > > > -drive if=pflash,format=raw,unit=1,file=RISCV_VIRT_VARS.fd \ > > > -drive file=sct.img,format=raw,if=virtio \ > > > -device virtio-net-device,netdev=net0 \ > > > -netdev user,id=net0 > > > > > > This does not invoke any CXL related stuff. > > > > Hmm, that doesn't seem like it ought to be running into this. > > What underlying memory region is the guest trying to do > > the virtio queue access to? > > FWIW, I have seen multiple bounce buffer usage with the generic net TX > path as well as the XHCI controller, so it might be either of these. > Bounce buffering should only take place when the memory region can't > be accessed directly though - I don't see why that's the case for the > given command line.
Yeah, exactly -- the only thing I can see there where a reasonable guest program ought to be trying to do DMA to/from non-host-RAM would be if (a) it's reading data from directly out of the pflash image and (b) the flash device has got itself into programming mode somehow. But that doesn't happen for the other architectures that have pflash for boot firmware as far as I know. The bounce buffering stuff does need to be fixed but it's also worth looking at why we're hitting the code path at all here, because even if it works the performance is terrible (doubly so if you try to execute code out of that MR). -- PMM
