[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

RE: [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


 


Rackspace

Lists.xenproject.org is hosted with RackSpace, monitoring our
servers 24x7x365 and backed by RackSpace's Fanatical Support®.