1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
|
semantic: 0.732
kernel: 0.728
files: 0.706
architecture: 0.654
x86: 0.651
device: 0.642
performance: 0.609
virtual: 0.591
user-level: 0.580
ppc: 0.577
hypervisor: 0.556
KVM: 0.553
network: 0.531
graphic: 0.530
vnc: 0.526
socket: 0.526
mistranslation: 0.516
peripherals: 0.503
permissions: 0.503
register: 0.452
PID: 0.440
risc-v: 0.422
boot: 0.404
i386: 0.390
VMM: 0.387
TCG: 0.341
arm: 0.335
debug: 0.306
assembly: 0.172
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.
|
