RE: [PATCH RFC 1/3] virtio infrastructure

[Rusty Russell <rusty@rustcorp.com.au>]

On Fri, 2007-06-01 at 23:35 +0000, Santos, Jose Renato G wrote:
> 
> > -----Original Message-----
> > From: xen-devel-bounces@lists.xensource.com 
> > [mailto:xen-devel-bounces@lists.xensource.com] On Behalf Of 
> > Rusty Russell
> > Sent: Thursday, May 31, 2007 5:19 AM
> > To: kvm-devel; Xen Mailing List; virtualization
> > Cc: Jimi Xenidis; Stephen Rothwell; jmk@plan9.bell-labs.com; 
> > Herbert Xu; Christian Borntraeger; Suzanne McIntosh; Anthony 
> > Liguori; Martin Schwidefsky
> > Subject: [Xen-devel] [PATCH RFC 1/3] virtio infrastructure
> > 
> > This attempts to implement a "virtual I/O" layer which should 
> > allow common drivers to be efficiently used across most 
> > virtual I/O mechanisms.  It will no-doubt need further enhancement.
> 
> Rusty
> 
> Could you please clarify what is the purpose of this "virtual I/O"
> layer?
> At least for networking, why isn't the current linux net device
> abstraction sufficient for hiding the details of different virtual
> devices implementations? What am I missing?

Hi Renato!

	This is a very good question.  For currently-existing and working
devices it just seems like another layer of indirection, and not much
code saving.

	There are several reasons for having a common layer.  The obvious is to
reduce the amount of code, but that's the least important.  Slightly
more important is that noone wants to maintain and tune 5 different
virtual net drivers, 5 different virtual block drivers, etc.  In fact,
the kernel community will start to rebel at some point, especially if
they want different optimization hooks deeper into the kernel.

	We expect to see new device types (entropy device, anyone?), and so the
5 different drivers becomes the 5 x N different drivers.  Eventually we
may come up with common bus and probing which everyone loves, but until
then we can at least make it simple for each virtualization technology
to implement the new XYZZY device.

	Finally, virtual I/O techniques are *moving*.  KVM doesn't really have
one, XenSource are discussing more changes to theirs (at least for
networking) and lguest is still looking for an efficient one.  No doubt
the others would love to use clean and optimal Linux drivers, too (UML,
S/390, Power, VMWare?).

	When Linux doesn't provide a model of what it expects from virtual
devices, one end of the design process is untethered: we've already seen
some fairly random and gratuitously different results.  If we can
provide a simple interface which we like it encourages new
implementations to produce Linux-friendly interfaces.

	Of course, the new interface must not suck.

I hope that clarifies my thinking?
Rusty.