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.
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.
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
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...).
Sysadmins shouldn't have to hand-configure each app, and shouldn't
have to repair clashes in defaults. Just Work is better.
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.
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.
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.
-- Jamie
--
To unsubscribe from this list: send the line "unsubscribe kvm" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
