WARNING - OLD ARCHIVES

This is an archived copy of the Xen.org mailing list, which we have preserved to ensure that existing links to archives are not broken. The live archive, which contains the latest emails, can be found at http://lists.xen.org/
   
 
 
Xen 
 
Home Products Support Community News
 
   
 

xen-devel

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

To: xen-devel <xen-devel@xxxxxxxxxxxxxxxxxxx>
Subject: Re: [Xen-devel] [RFC] VMI for Xen?
From: Anthony Liguori <aliguori@xxxxxxxxxx>
Date: Sun, 19 Mar 2006 09:51:25 -0600
Cc: Ian Pratt <m+Ian.Pratt@xxxxxxxxxxxx>, Christian Limpach <Christian.Limpach@xxxxxxxxxxxx>
Delivery-date: Sun, 19 Mar 2006 15:53:00 +0000
Envelope-to: www-data@xxxxxxxxxxxxxxxxxxx
In-reply-to: <4419C5A8.2010105@xxxxxxxxxx>
List-help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-id: Xen developer discussion <xen-devel.lists.xensource.com>
List-post: <mailto:xen-devel@lists.xensource.com>
List-subscribe: <http://lists.xensource.com/cgi-bin/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
List-unsubscribe: <http://lists.xensource.com/cgi-bin/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
References: <44173D41.2080009@xxxxxxxxxx> <4419C5A8.2010105@xxxxxxxxxx>
Sender: xen-devel-bounces@xxxxxxxxxxxxxxxxxxx
User-agent: Mail/News 1.5 (X11/20060309)
Christian pointed out that the current Xen tree copies a number of files and makes changes to them (renaming them to -xen). It's unclear how to properly count this in my mind since if they went into the tree as-is today, it would be a pure addition. Presumably, they would go in with some conditional logic which would reduce the total insertion count (dramatically) but also increase the diff size.

This probably helps explains why Chris is seeing such a dramatic reduction too. It's becoming clear to me that when reworked, the Xen changes are pretty much identical in code-size to VMI (give or take a couple thousand slocs).

Regards,

Anthony Liguori

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




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