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: Tue, 5 Jun 2007 02:39:36 -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 19:38:39 -0700
Envelope-to: www-data@xxxxxxxxxxxxxxxxxx
In-reply-to: <1181007892.25878.112.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> <08CA2245AFCF444DB3AC415E47CC40AFBD2FD4@xxxxxxxxxxxxxxxxxxxxxxxxxxxx> <1181007892.25878.112.camel@xxxxxxxxxxxxxxxxxxxxx>
Sender: xen-devel-bounces@xxxxxxxxxxxxxxxxxxx
Thread-index: AcenEywGjbqR0FQkR1es+d3p8Fx+NQABY7Lg
Thread-topic: [Xen-devel] [PATCH RFC 1/3] virtio infrastructure
 

> -----Original Message-----
> From: Rusty Russell [mailto:rusty@xxxxxxxxxxxxxxx] 
> Sent: Monday, June 04, 2007 6:45 PM
> 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
> 
> On Mon, 2007-06-04 at 21:14 +0000, Santos, Jose Renato G wrote:
> >   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.
> 
> Hi Renato,
> 
>       That definitely should be implementable as a virtio 
> layer; it was one of the design points.  I consulted with 
> Herbert Xu early on in the process, and I don't think it 
> would be too painful.  The devil, of course, is in the details.
> 

 Hi Rusty,
 Yes. I believe it should be implementable. The question is,
 does it achieve the desired benefits? Will the code be easier
 to maintain because it is sharing some generic code with
 other drivers? 

> >   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. 
> 
>       That would be silly, yes.
> 
> >   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. 
> 
> Well, S/390, PowerPC and UML both have virtual I/O already in 
> the kernel tree, as does Xen.  I believe VMWare have 
> out-of-tree drivers.  KVM is in tree, but currently doesn't 
> have paravirtualized drivers. 
> lguest is sitting in the -mm tree for merging in 2.6.23 with 
> its own drivers.
> 
> None of these drivers is optimal.  The Xen ones are closest, 
> and they're very Xen-specific and quite complex.  This is 
> good, and as it gives virtio drivers a target to beat 8)
> 

 Yes. It will be interesting to see how virtio could improve
 the situation. I hope you are right and we could simplify
 this complexity. 
 I apologize if I sounded negative. 
 Just wanted to have a reality check :)

 Regards

 Renato 

> Cheers,
> Rusty.
> 
> 

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