Hello. I've a bugreport against debian qemu package which basically states that 9pfs does not work. After some digging it turned out to be error reporting problem, plain and simple. The error message is:
qemu-system-x86_64: -device virtio-9p-pci,id=fs0,fsdev=fsdev-fs0,mount_tag=pwk,bus=pci.0,addr=0x7: Virtio-9p Failed to initialize fs-driver with id:fsdev-fs0 and export path:/home/stevie/Documents/PWK qemu-system-x86_64: -device virtio-9p-pci,id=fs0,fsdev=fsdev-fs0,mount_tag=pwk,bus=pci.0,addr=0x7: Device initialization failed. qemu-system-x86_64: -device virtio-9p-pci,id=fs0,fsdev=fsdev-fs0,mount_tag=pwk,bus=pci.0,addr=0x7: Device 'virtio-9p-pci' could not be initialized and the actual problem is that the path is not accessible from libvirt-spawned qemu due to permission denied (EPERM) error returned from statfs() call. The same happens when you mistype the pathname, or some other problem, -- in all cases it might be very difficult to find the actual cause, sort of strace'ing qemu process when it is at all possible. In this case, the prob is in hw/9pfs/virtio-9p-local.c:local_init(), the failing syscall is statfs(). But the thing is -- this init() method does not have Error argument to push error message, while upper layer, hw/9pfs/virtio-9p-device.c:virtio_9p_device_realize(), uses Error objects. In hw/9pfs/virtio-9p-proxy.c:proxy_init() (which implements the same init() method), there's a fprintf(stderr) which is used to report error (not even error_report()!). (And by the way, there, if socket init fails, there's no error reporting or checking at all). Should we revisit error checking and reporting for 9pfs somehow, so it is easier for the users? Thanks, /mjt
