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