On Fri, Jun 06, 2014 at 12:11:57PM +0300, Laine Stump wrote: > 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. No, this isn't good. type='user' specifically means that we're applying NAT via the SLIRP ethernet munging layer. This is very different to what vhost user is doing. In fact looking at the QEMU code again, it says that this QEMU net backend is in fact sending data over the chardev using the vhost packet format. So in fact I think the choice was right in the first patch - type='vhostuser' is a semantically good thing to use because the data is indeed in a vhost specific format. > (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.) I think this is all the same as any chardev backend - we need to apply whatever security manager labelling code we already have for chardevs to this new net backend. Regards, Daniel -- |: http://berrange.com -o- http://www.flickr.com/photos/dberrange/ :| |: http://libvirt.org -o- http://virt-manager.org :| |: http://autobuild.org -o- http://search.cpan.org/~danberr/ :| |: http://entangle-photo.org -o- http://live.gnome.org/gtk-vnc :| -- libvir-list mailing list libvir-list@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/libvir-list