Re: [RFC] VMI for Xen?

[Anthony Liguori <aliguori@us.ibm.com>]

Just some food for thought,  I did a simple analysis of the size of Xen 
Linux patches verses the VMI patches.  To make things more fair, I 
removed everything from the XenoLinux port accept for the i386 xen 
subarch (so no drivers and no support for other architectures).

VMI:

124 files changed, 4964 insertions(+), 623 deletions(-)

Xen:

185 files changed, 31586 insertions(+), 142 deletions(-)

So the Xen port adds 6 times more code than VMI.  I certainly don't 
think VMI for Xen is going to be as fast as native Xen but I don't know 
of anything that would cause a substantial change in VMI to add the 
necessary optimizations that would result in a massive change in the 
size of the patches.

I should also mention that one should also consider the size of the VMI 
Xen ROM too.  For the L4-based ROM that's going to be ~10k lines but I 
expect that if the Xen hypercalls were adjusted a little bit, it would 
drop much less.  For instance, Xen already does platform device 
emulation in the hypervisor for HVM domains so if that were reused it 
would knock out a fair amount of the ROM code.

It seems like there are some merits to the VMI approach.  Is there 
something I'm missing?  I admit I don't understand the XenoLinux changes 
well enough to know with certainity if there's something major that 
justifies the difference in size.  I'm hoping someone can hit me with a 
clue stick though if there is :-)

Regards,

Anthony Liguori

Anthony Liguori wrote:
> I'm sure everyone has seen the drop of VMI patches for Linux at this 
> point, but just in case, the link is included below.
>
> I've read this version of the VMI spec and have made my way through 
> most of the patches.  While I wasn't really that impressed with the 
> first spec wrt Xen, the second version seems to be much more 
> palatable.  Specifically, the code inlining and afterburner-style 
> padding seems like a really promising approach to native-speed single 
> kernel images.  Also, this version seems much more friendly to p2m.
>
> There are still a few things missing (like guest DMA support) but I 
> think the basic ideas are pretty sane.  So what does everyone else 
> think?  Is there anything within VMI that would inhibit some of Xen's 
> optimizations?  Are there any disadvantages to a VMI-style approach to 
> the subarch changes?
>
> How close are we to being able to merge our stuff with mainline?  Have 
> we gotten feedback yet on how hard this is going to be?  Would VMI be 
> an easier approach to inclusion in mainline?
>
> Just thought it would be prudent to start a discussion here, at least, 
> about it...
>
> http://lkml.org/lkml/2006/3/13/140
>
> Regards,
>
> Anthony Liguori
>
> _______________________________________________
> Xen-devel mailing list
> Xen-devel@lists.xensource.com
> http://lists.xensource.com/xen-devel