9p virtfs device reports error when opening certain files

[A A]

Reading certain files on a 9p mounted FS produces this error message:

qemu-system-x86_64: VirtFS reply type 117 needs 12 bytes, buffer has 12, less than minimum

After this error message is generated, further accesses to the 9p FS hangs whatever tries to access it. The Arch Linux guest system is otherwise usable. This happens with QEMU 5.0.0 and guest kernel version 5.6.11, hosted on an Arch Linux distro. I use the following command to launch QEMU:

exec qemu-system-x86_64 -enable-kvm -display gtk -vga virtio -cpu host -m 4G -netdev tap,ifname=vmtap0,id=vn0,script=no,downscript=no -device virtio-net-pci,netdev=vn0 -kernel kernel.img -drive file=file.img,format=raw,if=virtio -virtfs local,path=mnt,mount_tag=host0,security_model=passthrough,id=host0 -append "console=ttyS0 root=/dev/vda rw"

There's nothing relevant in the guest kernel logs as far as I'm aware of with loglevel set to 7.

I tracked down the issue to readv() with a small buffer(<=12 bytes) and then a large buffer(>= 1024 bytes). A C program is provided to trigger this behavior.

[A A (c3bacd17)]

Here's a C program to trigger this behavior. I don't think it matters what the contents of "file" or its size is.

[Christian Schoenebeck (schoenebeck)]

Looks like being introduced by this change:
https://patchwork.kernel.org/patch/11319993/

More specifically this one exactly:

- if (buf_size < size) {
+ if (buf_size < P9_IOHDRSZ) {

[Christian Schoenebeck (schoenebeck)]

The following patch should fix this bug for the kvm backend (not for the XEN backend yet).

Please let me know if it fixes this bug for you.

[A A (c3bacd17)]

Thanks, it works.

[Christian Schoenebeck (schoenebeck)]

Fix is now committed on master as SHA-1 cf45183b718f02b1369e18c795dc51bc1821245d, which actually just reverted the mentioned commit that was leading to this broken behavior:
https://github.com/qemu/qemu/commit/cf45183b718f02b1369e18c795dc51bc1821245d

The original Xen transport bug that motivated that change, was now fixed differently by handling that Xen issue solely on Xen transport driver side:
https://github.com/qemu/qemu/commit/a4c4d462729466c4756bac8a0a8d77eb63b21ef7

[Christian Schoenebeck (schoenebeck)]

Fixed in QEMU 5.1 release.