Re: [RFC] VMI for Xen?

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

Thanks for the response Ian!

Ian Pratt wrote:
> Your analysis is still taking all the patches to make dom0 functionality
> work, which accounts for a lot of changes and is totally outside of the
> scope of VMI.
>   
Could you elaborate a little?  Do you mean direct access to hardware or 
the domain management stuff?  I would expect that it's the former since 
the later should be well isolated in privcmd.
> We've been working with a bunch of RH/Novell folks to create a stripped
> down domU-only Xen patch that would be a fairer comparison.
>   
Ah, excellent, is there code available anywhere?  Has there been 
progress on microxen?
> We're currently looking though the new VMI patchset to see whether
> there's anything worth having, in particular, if there's anything that
> should be added to our patch to support what we can deduce that their
> hypervisor probably needs.
Excellent.  The thing that stuck out to me the most is binary rewriting 
for native code.  There seems that there has been a bit of performance 
work done to suggest that that's the best way to ensure that there's no 
different on native.
>  We've also talking to the VirtualIron team to
> make sure we're inclusive as possible.
>   
Sweet.
> The current VMI patchset couldn't support Xen's direct-mode (non shadow)
> MMU virtualization, and hasn't really been thought through properly for
> SMP. I'm sure we'll get something worked out that keeps everyone happy.
>   
I hope this doesn't appear too prodding.  There seemed to be very little 
technical objection on LKML and I fear that Xen is not being represented 
well enough.  A note on LKML explaining the problems and how Xen solves 
them would certainly being really useful.

Regards,

Anthony Liguori
> Ian
>  
>   
>> 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
>>>       
>>