[Qemu-devel] reporting 9pfs init errors

[Michael Tokarev <mjt@tls.msk.ru>]

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