semantic: 0.167
other: 0.147
device: 0.112
files: 0.092
KVM: 0.064
performance: 0.056
graphic: 0.054
network: 0.052
socket: 0.049
vnc: 0.048
PID: 0.044
permissions: 0.043
boot: 0.037
debug: 0.035
KVM: 0.397
debug: 0.302
device: 0.083
files: 0.054
PID: 0.032
other: 0.022
semantic: 0.020
socket: 0.017
performance: 0.016
network: 0.016
graphic: 0.013
boot: 0.011
vnc: 0.009
permissions: 0.009

9p virtfs device reports error when opening certain files

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.

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

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) {



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.

Thanks, it works.

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


Fixed in QEMU 5.1 release.