Hi Matias, On Wed, Jan 07, 2026 at 05:14:25PM +0100, Matias Ezequiel Vara Larsen wrote: > On Fri, Dec 26, 2025 at 4:09 PM Francesco Valla <[email protected]> wrote: > > > > Hi, > > > > On Sun, Dec 14, 2025 at 04:25:54PM +0100, Francesco Valla wrote: > > > While stress testing this, I noticed that flooding the virtio-can > > > interface with packets leads to an hang of the interface itself. > > > I am seeing this issuing, at host side: > > > > > > while true; do cansend can0 123#00; done > > > > > > with: > > > > > > - QEMU: the tip of the master branch plus [2] > > > - vhost-device: the tip of the main branch > > > > > > and the following QEMU invocation: > > > > > > qemu-system-x86_64 -serial mon:stdio \ > > > -m 2G -smp 2 \ > > > -kernel $(pwd)/BUILD.bin/arch/x86/boot/bzImage \ > > > -initrd /home/francesco/SRC/LINUX_KERNEL/initramfs.gz \ > > > -append "loglevel=7 console=ttyS0" \ > > > -machine memory-backend=pc.ram \ > > > -object > > > memory-backend-file,id=pc.ram,size=2G,mem-path=/tmp/pc.ram,share=on \ > > > -chardev socket,id=can0,path=/tmp/sock-can0 \ > > > -device vhost-user-can-pci,chardev=can0 > > > > > > > > > Restarting the interface (i.e.: ip link set down and the up) does not > > > fix the situation. > > > > > > I'll try to do some more testing during the next days. > > > > After a deep dive, I _think_ the problem actually lies in vhost-device, > > since it is not there (or al least, it seems so) using an alternative > > implementation that uses the qemu socketcan support [0] (implementation > > which builds on top of the work done by Harald and Mikhail): > > > > qemu-system-x86_64 -serial mon:stdio \ > > -m 2G -smp 2 -enable-kvm \ > > -kernel $(pwd)/BUILD.bin/arch/x86/boot/bzImage \ > > -initrd /home/francesco/SRC/LINUX_KERNEL/initramfs.gz \ > > -append "loglevel=7 console=ttyS0" \ > > -object can-bus,id=canbus0 -object > > can-host-socketcan,id=canhost0,if=vcan0,canbus=canbus0 \ > > -device virtio-can-pci,canbus=canbus0 > > > > Unfortunately, my Rust knoweledge is not sufficient to understand the > > vhost-device implementation [1]; the issue seems to be related to the > > host->guest vring becoming empty and not refilling anymore. > > > > Can you try with > https://github.com/MatiasVara/vhost-device/commits/fix-for-923/?
I'll stress test it during the night, but this seems to fix it. Before it was reproducible in a consistent manner after mere seconds, while i now in a bunch of runs I never reproduced it. I also agree with your analysis on the commit. > > Thanks, Matias > > Thank you! Francesco
