Re: [Xen-devel] [RFC] VMI for Xen?

[Anthony Liguori <aliguori@xxxxxxxxxx>]

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@xxxxxxxxxxxxxxxxxxx
> > > http://lists.xensource.com/xen-devel
> > >       
> >     

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