Re: [libvirt] [PATCH RFC] Add support for QEMU vhost-user feature

On 06/06/2014 11:49 AM, Laine Stump wrote: > On 06/05/2014 05:35 PM, Daniel P. Berrange wrote: >> I do agree that 'vhostuser' is a somewhat >> QEMU specific name - at least with 'tap' this was a common terminology >> across multiple OS and projects. This is really a variant on 'tap' >> which is avoiding use of kernel devices. To perhaps we should call >> this new mode 'usertap' ? Or another idea would be to call it 'tapstream' >> eg > For some reason I'm more partial to "tapstream". Maybe because it > doesn't force any future uses to only be in userspace. But at some level > a name is just a name, so... I think I've changed my opinion. After looking at the high level description of vhost-user, I found that it isn't implemented simply using a stream - the stream is used by qemu to learn the location of a shared memory region, and the shared memory region is what is actually used to send/receive the packets. So it isn't just a stream. Maybe it *is* reasonable to focus on the "this all happens in userspace" aspect, and simply user <interface type='user'> ? This would mean that the xml would look like this: <interface type='user'> <model type='virtio'/> <driver name='vhost'/> <source type='unix' path='xyzzy' mode='connect'/> ... </interface> Currently the "user" interface type has only one backend, which is the usermode networking of qemu. This would give it a 2nd backend, "vhost", which would be implemented by vhost-user.

(BTW, I have a question - is only root allowed to connect to the vhost-user socket? Is there any selinux protection of it that needs to be accounted for? If not, then you may want to consider doing this to prevent a rogue (e.g. a qemu guest that exploits some hypothetical exploit in qemu to break out into the qemu process) from wreaking havoc with your network infrastructure. Since libvirt usually starts up qemu processes with a non-privileged uid, if root access is required to open the socket, qemu needs to be able to accept an open file descriptor for this rather than a path, and libvirt should be opening the socket, then passing the fd to qemu.)