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.)
--
libvir-list mailing list
libvir-list@xxxxxxxxxx
https://www.redhat.com/mailman/listinfo/libvir-list