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

[Rusty Russell <rusty@xxxxxxxxxxxxxxx>]

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.

>   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)

Cheers,
Rusty.


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