WARNING - OLD ARCHIVES

This is an archived copy of the Xen.org mailing list, which we have preserved to ensure that existing links to archives are not broken. The live archive, which contains the latest emails, can be found at http://lists.xen.org/
   
 
 
Xen 
 
Home Products Support Community News
 
   
 

xen-devel

RE: [Xen-devel] [PATCH RFC 1/3] virtio infrastructure

To: "Rusty Russell" <rusty@xxxxxxxxxxxxxxx>
Subject: RE: [Xen-devel] [PATCH RFC 1/3] virtio infrastructure
From: "Santos, Jose Renato G" <joserenato.santos@xxxxxx>
Date: Mon, 4 Jun 2007 21:14:01 -0000
Cc: Jimi Xenidis <jimix@xxxxxxxxxxxxxx>, Stephen Rothwell <sfr@xxxxxxxxxxxxxxxx>, Xen Mailing List <xen-devel@xxxxxxxxxxxxxxxxxxx>, jmk@xxxxxxxxxxxxxxxxxxx, Herbert Xu <herbert@xxxxxxxxxxxxxxxxxxx>, kvm-devel <kvm-devel@xxxxxxxxxxxxxxxxxxxxx>, virtualization <virtualization@xxxxxxxxxxxxxxxxxxxxxxxxxx>, Christian Borntraeger <cborntra@xxxxxxxxxx>, Suzanne McIntosh <skranjac@xxxxxxxxxx>, Anthony Liguori <anthony@xxxxxxxxxxxxx>, Martin Schwidefsky <schwidefsky@xxxxxxxxxx>
Delivery-date: Mon, 04 Jun 2007 14:14:24 -0700
Envelope-to: www-data@xxxxxxxxxxxxxxxxxx
In-reply-to: <1180779167.9228.66.camel@xxxxxxxxxxxxxxxxxxxxx>
List-help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-id: Xen developer discussion <xen-devel.lists.xensource.com>
List-post: <mailto:xen-devel@lists.xensource.com>
List-subscribe: <http://lists.xensource.com/cgi-bin/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
List-unsubscribe: <http://lists.xensource.com/cgi-bin/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
References: <1180613947.11133.58.camel@xxxxxxxxxxxxxxxxxxxxx> <08CA2245AFCF444DB3AC415E47CC40AFBD2CCF@xxxxxxxxxxxxxxxxxxxxxxxxxxxx> <1180779167.9228.66.camel@xxxxxxxxxxxxxxxxxxxxx>
Sender: xen-devel-bounces@xxxxxxxxxxxxxxxxxxx
Thread-index: Acek/qZbb4RB0opQTNSnuBNHC2UE9gB6iEvw
Thread-topic: [Xen-devel] [PATCH RFC 1/3] virtio infrastructure
 

> -----Original Message-----
> From: Rusty Russell [mailto:rusty@xxxxxxxxxxxxxxx] 
> Sent: Saturday, June 02, 2007 3:13 AM
> To: Santos, Jose Renato G
> Cc: kvm-devel; Xen Mailing List; virtualization; Jimi 
> Xenidis; Stephen Rothwell; jmk@xxxxxxxxxxxxxxxxxxx; Herbert 
> Xu; Christian Borntraeger; Suzanne McIntosh; Anthony Liguori; 
> Martin Schwidefsky
> Subject: RE: [Xen-devel] [PATCH RFC 1/3] virtio infrastructure
> 
> 
> 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.
> 

  Rusty,

  Thanks for clarifying your thinking. This helped me understand
  your goals better.
  I agree it would be nice to reduce the number of drivers as it
  improves mantainability. However I am not convinced that
  adding an IO virtualization layer will remove the need
  for having different drivers for different virtualization
  technologies.
  It seems that we will still need specific devices drivers
  for each different virtualization flavor. For example,
  we will still need to have a specific Xen netfront 
  device that talks to a backend device in dom0, using
  page grants, and other Xen specific mechanisms.
  It looks like  will still need to maintain all the virtual device 
  drivers and in addition we will now have to maintain 
  another virtualization layer. 
  I confess I don't know well any of the other virtualization
  technologies besides Xen. Maybe for some of them there is
  enough similarities that you could benefit from a common
  virtualization layer, but I just can't see it yet. 
  
  Regards

  Renato
  
>       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.
> 
> 

_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxxxxxxxx
http://lists.xensource.com/xen-devel