[Qemu-devel] Re: virtio-serial: An interface for host-guest communication

[Amit Shah]

On (Thu) Aug 06 2009 [18:37:40], Jamie Lokier wrote:
> Amit Shah wrote:
> > On (Thu) Aug 06 2009 [08:58:01], Anthony Liguori wrote:
> > > Amit Shah wrote:
> > >> On (Thu) Aug 06 2009 [08:29:40], Anthony Liguori wrote:
> > >>   
> > >>> Amit Shah wrote:
> > >>>     
> > >>>> Sure; but there's been no resistance from anyone from including the
> > >>>> virtio-serial device driver so maybe we don't need to discuss that.
> > >>>>         
> > >>> There certainly is from me.  The userspace interface is not 
> > >>> reasonable  for guest applications to use.
> > >>>     
> > >>
> > >> One example that would readily come to mind is dbus. A daemon running on
> > >> the guest that reads data off the port and interacts with the desktop by
> > >> appropriate dbus commands. All that's needed is a stream of bytes and
> > >> virtio-serial provides just that.
> > >>   
> > >
> > > dbus runs as an unprivileged user, how does dbus know which  
> > > virtio-serial port to open and who sets the permissions on that port?
> > 
> > The permission part can be handled by package maintainers and sysadmins
> > via udev policies.
> > 
> > So all data destined for dbus consumption gets to a daemon and that
> > daemon then sends it over to dbus.
> 
> virtio-serial is nice, easy, simple and versatile.  We like that; it
> should stay that way.
> 
> dbus isn't a good match for this.
> 
> dbus is not intended for communication between hosts, by design.

Oh; I don't mean to say dbus on the host will communicate directly with
dbus on the guest via virtio-serial. I'm just saying there'll be some
daemon on the guest and if there's a request for, say, updating guest
clipboard with some contents, it can be passed on to dbus on the guest.

> It depends on per-app configuration files in
> /etc/dbus/{session,system}.d/, which are expected to match the
> installed services.
> 
> For this, the guest's files in /etc/dbus/ would have to match the QEMU
> host host services in detail.  dbus doesn't have a good mechanism for
> copying with version skew between both of them, because normally
> everything resides on the same machine and the config and service are
> updated at the same time.  This is hard to guarantee with a VM.

Right. Not proposing this at all.

> Apart from dbus, hard-coded meanings of small N in /dev/vmchN are
> asking for trouble.  It is bound to break when widely deployed and

It's no different from the way major-minor numbering works on the Linux
kernel: they uniquely identify a device. Or the way tcp port number
works. In the same way, /dev/vmchN will uniquely identify some function
over a port. You idea of introducing a symlink to /dev/clipboard is a
good one and it takes one udev rule to generate that link.

> guest/host configs don't match.  It also doesn't fit comfortably when
> you have, say, bob and alice both logged in with desktops on separate
> VTs.  Clashes are inevitable, as third-party apps pick N values for
> themselves then get distributed - unless N values can be large
> (/dev/vmch44324 == kernelstats...).

Hm, so there can be one daemon on the guest handling all clipboard
events. There's some work done already by the fast-user-switch support
and that can be extended to daemons that talk over virtio-serial.

> Sysadmins shouldn't have to hand-configure each app, and shouldn't
> have to repair clashes in defaults.  Just Work is better.

No; they shouldn't need to.

> virtio-serial is nice.  The only ugly part is _finding_ the right
> /dev/vmchN.
> 
> Fortunately, _any_ out-of-band id string or id number makes it perfect.
> 
> An option to specify PCI vendor/product ids in the QEMU host
> configuration is good enough.
> 
> An option to specify one or more id strings is nicer.
> 
> Finally, Anthony hit on an interesting idea with USB.  Emulating USB
> sucks.  But USB's _descriptors_ are quite effective, and the USB basic
> protocol is quite reasonable too.
> 
> Descriptors are just a binary blob in a particular format, which
> describe a device and also say what it supports, and what standard
> interfaces can be used with it too.  Bluetooth is similar; they might
> even use the same byte format, I'm not sure.

And doing something similar is akin to populating some files in /sys.

> All the code for parsing USB descriptors is already present in guest
> kernels, and the code for making appropriate device nodes and
> launching apps is already in udev.  libusb also allows devices to be
> used without a kernel driver, and is cross-platform.  There are plenty
> of examples of creating USB descriptors in QEMU, and may be the code
> can be reused.
> 
> The only down side of USB is that emulating it sucks :-)  That's mainly
> due to the host controllers, and the way interrupts use polling.
> 
> So here's a couple of ideas:
> 
>    - virtio-usb, using virtio instead of a hardware USB host
>      controller.  That would provide all the features of USB
>      naturally, like hotplug, device binding, access from userspace,
>      but with high performance, low overhead, and no interrupt polling.

I wonder how that's any different or less complex that virtio-serial.
Essentially the idea is the same. It's just the name that's different,
the way I see it.

>      You'd even have the option of cross-platform guest apps, as well
>      as working on all Linux versions, by emulating a host controller
>      when the guest doesn't have virtio-usb.
> 
>      As a bonus, existing USB support would be accelerated.
> 
>    - virtio-serial providing a binary id blob, whose format is the
>      same as USB descriptors.  Reuse the guest's USB parsing and
>      binding to find and identify, but the actual device functionality
>      would just be a byte pipe.
> 
>      That might be simple, as all it involves is a blob passed to the
>      guest from QEMU.  QEMU would build the id blob, maybe reusing
>      existing USB code, and the guest would parse the blob as it
>      already does for USB devices, with udev creating devices as it
>      already does.

Hm, making a very simple transport into something complicated involving
a few more subsystems just to expose a usb device which functions as a
char device in the end. I don't see a big benefit. People are deploying
virtio anyway for block and net. I don't see why using the same
transport for a char device would be an impediment.

		Amit