[libvirt] [PATCH RFC] Add support for QEMU vhost-user feature
Daniel P. Berrange
berrange at redhat.com
Thu Jun 5 14:35:42 UTC 2014
On Thu, Jun 05, 2014 at 05:09:02PM +0300, Laine Stump wrote:
> Daniel pointed out that qemu actually accepts any generic character
> device to connect to, and it makes sense to support this by using
> virDomainChrSourceDefPtr. However, the parse function for
> virDomainChrSourceDef requires that the type of character device be
> already parsed and set in the object, implying that it needs to be in
> the config somewhere outside of the <source> element itself.
>
> Related to that, I'm wondering if maybe instead of setting the type of
> <interface> to the very specific "vhostuser", maybe it could be set to
> the type of character device ("socket", "tcp", etc), and the fact that
> vhostuser is used could be specified in exactly the same way that
> vhost-net is turned on for tap devices - with <driver name="vhost"/>. So
> for example, you would have this:
>
>
> <interface type='unix'> <!-- for a unix domain socket -->
> <model type='virtio'/>
> <driver name='vhost'/>
> <source path='xyzzy' mode='server'/>
> ...
> </interface>
The problem with this is that some of the chardev 'type' options
clash with some of the interface 'type' options, so I think we
must keep them separated. 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
<interface type='usertap'>
<model type='virtio'/>
<driver name='vhost'/>
<source type='unix'>
...chardev source schema...
</source>
</interface>
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 :|
More information about the libvir-list
mailing list