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. _______________________________________________ Virtualization mailing list Virtualization@xxxxxxxxxxxxxxxxxxxxxxxxxx https://lists.linux-foundation.org/mailman/listinfo/virtualization
