On Wed, Dec 31, 2025 at 10:08 PM Matias Ezequiel Vara Larsen <[email protected]> wrote: > > On Mon, Dec 29, 2025 at 09:55:50PM +0100, Francesco Valla wrote: > > Hi Matias, > > > > On Mon, Dec 29, 2025 at 07:53:48PM +0100, Matias Ezequiel Vara Larsen 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. > > > > > > I tried this and I could not reproduce it. [2] requires a minimal change > > > to apply, i.e., qdev-properties.h has changed to /core. I'll send a v2 > > > for that. I used latest vhost-device-can. I run `candump can0` in the > > > guest and `while true; do cangen vcan0; done` in the host. Am I missing > > > something? > > > > With the plain 'cangen' you are not really flooding the interface, since > > you are only sending a random CAN frame every 200ms. The only way I can > > reproduce this behaviour in a consistent manner is running from the host: > > > > while true; do cansend vcan0 134#00; done > > > > which seems to generate the maximum amount of traffic. > > > You were right. I could reproduce it. After a while, I stop to get packets > in the guest. I'll investigate. >
I think I found the problem and it is in the device. When the driver adds descriptors in the rx queue, It seems the device is collecting all descriptors from the rx queue and trying to consume them in one run. However, in some situations, there are not enough msgs to write in a descriptor and the device returns but the descriptor is never consumed and the driver does not provide a new one. I can see that the host continues to send msgs to the device but the number of descriptors in the rx queue continues to be 0. I am trying to figure out how to fix it. Matias
