From mboxrd@z Thu Jan 1 00:00:00 1970 From: Anthony Liguori Subject: Re: [RFC] VMI for Xen? Date: Thu, 16 Mar 2006 17:24:49 -0600 Message-ID: <4419F3C1.7000004@us.ibm.com> References: Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Return-path: In-Reply-To: List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: xen-devel-bounces@lists.xensource.com Errors-To: xen-devel-bounces@lists.xensource.com To: Ian Pratt Cc: xen-devel List-Id: xen-devel@lists.xenproject.org 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 >>> >>