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

[Xen-users] Re: Merge Xen (the hypervisor) into Linux

To: Steven Rostedt <rostedt@xxxxxxxxxxx>
Subject: [Xen-users] Re: Merge Xen (the hypervisor) into Linux
From: George Dunlap <george.dunlap@xxxxxxxxxxxxx>
Date: Wed, 03 Jun 2009 13:03:51 +0100
Cc: "npiggin@xxxxxxx" <npiggin@xxxxxxx>, Dan Magenheimer <dan.magenheimer@xxxxxxxxxx>, "xen-devel@xxxxxxxxxxxxxxxxxxx" <xen-devel@xxxxxxxxxxxxxxxxxxx>, Theodore Tso <tytso@xxxxxxx>, "wimcoekaerts@xxxxxxxxxxxx" <wimcoekaerts@xxxxxxxxxxxx>, "gregkh@xxxxxxx" <gregkh@xxxxxxx>, ksrinivasan <ksrinivasan@xxxxxxxxxx>, "kurt.hackel@xxxxxxxxxx" <kurt.hackel@xxxxxxxxxx>, "x86@xxxxxxxxxx" <x86@xxxxxxxxxx>, "jeremy@xxxxxxxx" <jeremy@xxxxxxxx>, "linux-kernel@xxxxxxxxxxxxxxx" <linux-kernel@xxxxxxxxxxxxxxx>, "xen-users@xxxxxxxxxxxxxxxxxxx" <xen-users@xxxxxxxxxxxxxxxxxxx>, Ian Pratt <Ian.Pratt@xxxxxxxxxxxxx>, Stephen Spector <stephen.spector@xxxxxxxxxx>, "avi@xxxxxxxxxx" <avi@xxxxxxxxxx>, "EAnderson@xxxxxxxxxx" <EAnderson@xxxxxxxxxx>, "jens.axboe@xxxxxxxxxx" <jens.axboe@xxxxxxxxxx>, Ingo Molnar <mingo@xxxxxxx>, "torvalds@xxxxxxxxxxxxxxxxxxxx" <torvalds@xxxxxxxxxxxxxxxxxxxx>, David Miller <davem@xxxxxxxxxxxxx>, Keir Fraser <Keir.Fraser@xxxxxxxxxxxxx>
Delivery-date: Thu, 04 Jun 2009 02:08:35 -0700
Envelope-to: www-data@xxxxxxxxxxxxxxxxxxx
In-reply-to: <alpine.DEB.2.00.0906030108500.14994@xxxxxxxxxxxxxxxxxxx>
List-help: <mailto:xen-users-request@lists.xensource.com?subject=help>
List-id: Xen user discussion <xen-users.lists.xensource.com>
List-post: <mailto:xen-users@lists.xensource.com>
List-subscribe: <http://lists.xensource.com/mailman/listinfo/xen-users>, <mailto:xen-users-request@lists.xensource.com?subject=subscribe>
List-unsubscribe: <http://lists.xensource.com/mailman/listinfo/xen-users>, <mailto:xen-users-request@lists.xensource.com?subject=unsubscribe>
References: <3ab07e3b-a601-48d5-b350-29cbaf111892@default> <alpine.DEB.2.00.0906030108500.14994@xxxxxxxxxxxxxxxxxxx>
Sender: xen-users-bounces@xxxxxxxxxxxxxxxxxxx
User-agent: Thunderbird 2.0.0.21 (X11/20090409)
Steven Rostedt wrote:
What's the issue with this? You get to keep your "micro hypervisor" design that has been stated to be the superior method.
It is a very interesting idea, but it would still be basically a completely new project. If someone started such a project, they could probably cannibalize a lot of Xen's existing code (a funny boomerang, since Xen cannibalized Linux's code when it started), but it would still require a lot of work and re-writing, and the result would be a lot different than Xen is now. It would be years before it was ready to be used in a production system. It's not really realistic to expect all the Xen developers and users to drop Xen development, shift gears into this new project, and wait until it's ready to be used. (That's not to say that the idea has no merit, just that Xen as it is wouldn't go away until it this hypothetical linux hypervisor component was mature enough for users and developers to jump onto.)

Yeah, lots of interesting implications for such a project.

Having a separate component to be a hypervisor, even if in the same tree, would mean we could have dedicated hypervisor schedulers, &c. They could (conceivably) work more closely with the dom0 scheduler to make things more efficient.

As others have said, it would limit the ability of such a hypervisor to be used with other dom0 operatings systems. Fixing the ABI sufficiently so that others can use it might be possible, but it seems to me unlikely to meet with much success without a lot of committment on both sides (i.e., w/in Linux and within other OS communities).

I'm not sure that it would turn out quite the way some people expect, though. From a technical perspective, I'm not sure getting rid of the "ring 1 hack" or requiring HVM support would be the best design choice for such a project. And it's hard to predict what kinds of technical, political, or cultural issues, directions, or potential dead-ends a project might take. From all angles, it's too risky to just abandon the current Xen codebase until this hypothetical linux hypervisor component has shown itself to be viable.

-George

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