Xen.org and Linux Kernel Update

There has been a great deal of developer discussion lately around the proposed patches to extend the Linux kernel’s existing Xen support to include control domain capabilities (loosely known as “the dom0 patches”). These discussions are generating a great deal of interest in Xen and Linux so I thought I would add some perspective for people in the community looking to get a better understanding of the situation.
As a reminder, paravirtualized Xen guest support has been available in Linux kernels since 2.6.24 for 32 bit Guests and 2.6.27 for 64 bit Guests. This joint effort between Xen.org and the kernel.org communities now enable all Linux distributions to support para-virtualization “out of the box” with no locally-maintained patches, additional coding or porting efforts required by customers or Linux distribution vendors.
The second focus of our Linux integration efforts centers on the control Guest (Domain0) present in every Xen system. As far as the hypervisor is concerned, it is a normal paravirtualized domain which happens to have some additional privileges (such as direct hardware access, the ability to start other domains, and so on).  Its main claim to fame is that the hypervisor starts it automatically at boot time, akin to the “init” process in a Linux system. There’s no fundamental reason why there should be a unique, absolutely privileged domain.  The Xen architecture allows for multiple privileged domains, and splitting the initial domain’s responsibilities into a number of more special-purpose domains can make things more reliable and secure.
Patches exist today that allow users to provide these essential services for a variety of operating systems including Linux, NetBSD, and Solaris. Specifically for Linux users, the patches are currently not available in upstream Linux and require efforts by all Linux distribution vendors to ensure proper Xen support in their distribution; as they have to do with the many other features they ship which do not enjoy upstream Linux support.
The Xen.org community recognizes the additional work required by Linux distribution vendors to enable Xen in their solutions and is working directly with the kernel.org community to include these patches directly in the Linux kernel, thereby removing this effort for Linux distribution vendors. The current discussions within the Xen.org mailing lists center on the best way to achieve this integration and the feedback from the kernel.org community including Linus Torvalds is helping us understand the best method for integration.
The complete technical discussions on the merge is available in xen-users and xen-devel but I thought I would highlight some comments from Jeremy Fitzhardinge, the lead community developer from Xen.org on the merge:
The issue is about Dom0 support, a subset of Xen, which primarily relates to allowing Xen domains to have direct access to hardware.  It is technically challenging because it covers quite different set of functionality in different parts of the kernel – pci, dma, interrupts, etc.
In some cases, the dom0 changes are fairly uncontroversial because they’re just another user of existing interfaces (dma_ops) or slightly controversial because they need tweaks to an existing interface (swiotlb).
However, where the existing kernel code doesn’t have a suitable abstraction layer, or even particularly clean internal interfaces (like the apic code), working out how to make the appropriate Xen changes poses a tricky tradeoff: do I attempt to restructure a large complex subsystem with lots of subtle interactions with the rest of the kernel – not to mention subtle interactions with many types of quirky hardware – just to add my changes?  Or do I make some relatively small, low risk (but low beauty) changes to get the job done?
I went for the latter; the cost-benefit tradeoff just didn’t seem to justify a massive refactor.  But others have pretty pointedly had the opposite view, so I’m now investigating what its actually going to involve.