[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

[Xen-users] 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.


Xen-users mailing list



Lists.xenproject.org is hosted with RackSpace, monitoring our
servers 24x7x365 and backed by RackSpace's Fanatical Support®.