Date:	Wed, 03 Jun 2009 13:03:51 +0100
From:	George Dunlap <george.dunlap@...citrix.com>
To:	Steven Rostedt <rostedt@...dmis.org>
CC:	Dan Magenheimer <dan.magenheimer@...cle.com>,
	Theodore Tso <tytso@....edu>, Ingo Molnar <mingo@...e.hu>,
	David Miller <davem@...emloft.net>,
	"jeremy@...p.org" <jeremy@...p.org>,
	"avi@...hat.com" <avi@...hat.com>,
	"xen-devel@...ts.xensource.com" <xen-devel@...ts.xensource.com>,
	"x86@...nel.org" <x86@...nel.org>,
	"linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
	Keir Fraser <Keir.Fraser@...citrix.com>,
	"torvalds@...ux-foundation.org" <torvalds@...ux-foundation.org>,
	"gregkh@...e.de" <gregkh@...e.de>,
	"kurt.hackel@...cle.com" <kurt.hackel@...cle.com>,
	Ian Pratt <Ian.Pratt@...citrix.com>,
	"xen-users@...ts.xensource.com" <xen-users@...ts.xensource.com>,
	ksrinivasan <ksrinivasan@...ell.com>,
	"EAnderson@...ell.com" <EAnderson@...ell.com>,
	"wimcoekaerts@...mekes.net" <wimcoekaerts@...mekes.net>,
	Stephen Spector <stephen.spector@...rix.com>,
	"jens.axboe@...cle.com" <jens.axboe@...cle.com>,
	"npiggin@...e.de" <npiggin@...e.de>
Subject: Re: Merge Xen (the hypervisor) into Linux

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
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Powered by blists - more mailing lists