xen-devel
RE: [Xen-devel] [PATCH RFC 1/3] virtio infrastructure
To: |
"Jeremy Fitzhardinge" <jeremy@xxxxxxxx> |
Subject: |
RE: [Xen-devel] [PATCH RFC 1/3] virtio infrastructure |
From: |
"Santos, Jose Renato G" <joserenato.santos@xxxxxx> |
Date: |
Tue, 5 Jun 2007 02:05:31 -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>, Rusty Russell <rusty@xxxxxxxxxxxxxxx>, 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:04:03 -0700 |
Envelope-to: |
www-data@xxxxxxxxxxxxxxxxxx |
In-reply-to: |
<466481ED.8050209@xxxxxxxx> |
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> <466481ED.8050209@xxxxxxxx> |
Sender: |
xen-devel-bounces@xxxxxxxxxxxxxxxxxxx |
Thread-index: |
Acem7i/06z6DHKWoSz+DQxnfix/tOAAJ3zLA |
Thread-topic: |
[Xen-devel] [PATCH RFC 1/3] virtio infrastructure |
> -----Original Message-----
> From: Jeremy Fitzhardinge [mailto:jeremy@xxxxxxxx]
> Sent: Monday, June 04, 2007 2:20 PM
> To: Santos, Jose Renato G
> Cc: Rusty Russell; Jimi Xenidis; Stephen Rothwell; Xen
> Mailing List; jmk@xxxxxxxxxxxxxxxxxxx; Herbert Xu; kvm-devel;
> virtualization; Christian Borntraeger; Suzanne McIntosh;
> Anthony Liguori; Martin Schwidefsky
> Subject: Re: [Xen-devel] [PATCH RFC 1/3] virtio infrastructure
>
> Santos, Jose Renato G wrote:
> > 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.
> >
>
> The hope is that the Xen-specific elements of the driver will
> be restricted to Xen-specific things like grant tables, and
> the bulk of the driver and its logic can be common. Whether
> that can be achieved and still retain the full
> performance/features of the entirely Xen-specific netfront
> driver remains to be seen. I haven't had a chance to look at
> doing any Xen-virtio glue yet, so I'm not really sure how it
> will work out.
>
> J
>
Ok, if you share some common code this could be beneficial, but
in the specific case of Xen networking I believe most of netfront
code is Xen specific. I think that a generic "virtual-IO" layer
would not be beneficial in this case, but instead it would
only add extra complexity to glue the layers.
I don't know if this will be the case for other
virtualization technologies, but I think it would be useful to
have a better understanding of exactly which code could
be shared before proposing something like this to the linux
mantainers.
I think it will probably not be accepted upstream if
there is no clear evidence of code sharing. And if the sharing
is not uniform across all virtualization technologies,
we should keep an option of bypassing the virtio layer when
it does not help or when it makes code more complex (which
I suspect will be the case for Xen networking).
Just my 2 cents,
Regards
Renato
_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxxxxxxxx
http://lists.xensource.com/xen-devel
|
|
|