LWN.net Logo

Toward the merging of Xen

The Xen virtual machine has been getting a great deal of attention. Xen allows virtual systems to be run, over Linux, with high performance. Each machine can run a different operating system (perhaps even Windows, eventually), can have its resource usage limited, and can even be moved between physical hosts while it is running. Xen is of interest to people doing kernel development, or who are interested in providing virtual hosting services.

Xen works by creating its own virtual hardware architecture, to which guest kernels are ported. The separate architecture is required to enable Xen to truly isolate guest systems in such a way that they cannot break out. This approach also allows Xen to perform various performance-enhancing tricks, such as allowing Xen systems to communicate by transparently remapping pages between them. For Linux, the Xen patches create a completely new architecture (arch/xen) which, while resembling the i386 architecture (and copying many files from it), is separate from it.

For some time now, certain kernel developers have been saying that the merging of Xen was imminent. Nobody seems to object to having support for Xen in the mainline kernel, but there is one little glitch: back in December, Andi Kleen objected to the creation of a separate Xen architecture. The creation of a completely new architecture which duplicates much of the i386 code will, says Andi, lead to long-term maintenance problems. He would much rather see Xen support merged into an i386 subarchitecture.

Xen developer Ian Pratt initially responded that such a merge was not feasible, and, besides, maintaining the separate architecture had not been a problem for them so far. Andi remained convinced, however, that things would not work well in the long term. The discussion slowed to a halt without any real decisions being made, one way or another.

Andrew Morton recently decided to restart the conversation with an opinion of his own:

I tend to agree with Andi, and I'm not sure that the Xen team fully appreciate the downside of having an own-architecture in the kernel.org kernel and the upside of having their code integrated with the most-maintained architecture. It could be that the potential problems haven't been sufficiently well communicated.

Ian Pratt came back with a new proposal. The Xen group would start by doing the easy parts of merging the Xen code directly into the i386 architecture. Most of this work, he says, would involve cleaning up the i386 code; the result would be a halving of the number of files modified by the Xen patches. The remaining changes would then go in as an i386 subarchitecture except for any Xen code which is useful for all architectures; that, instead, would end up in drivers/xen/core. Further unification and cleanup could happen after the merge takes place.

This approach appears to have satisfied the critics, the obligatory minor quibbles notwithstanding. So that is probably the path Xen will take to get into the mainline. There is, it would seem, a fair amount of work to be done before that mainline merge can actually happen, though, so it's not at all clear that it can be done in time for 2.6.12.


(Log in to post comments)

Toward the merging of Xen

Posted Mar 3, 2005 15:46 UTC (Thu) by jzbiciak (✭ supporter ✭, #5246) [Link]

Questions this raises for me: What impact does Xen have on the future of User Mode Linux? Is Xen an ia32-only technology, and therefore each has a place in the future?

Toward the merging of Xen

Posted Mar 3, 2005 17:39 UTC (Thu) by doogie (subscriber, #2445) [Link]

They are working on a port to x86_64. Additionally, not mentioned above, there are OS ports of plan9, netbsd, and freebsd.

(the debian xen maintainer)

Copyright © 2005, Eklektix, Inc.
Comments and public postings are copyrighted by their creators.
Linux is a registered trademark of Linus Torvalds