The Xen patches
The patches in the 35-part set fall into two broad categories. The first of those creates a new architecture (a subarchitecture of i386) and a port of the Linux kernel for that architecture. This is the code which is built into the modified kernel which can run as a Xen guest. Some of the more significant changes include:
- Allowing for more interrupt vectors. Xen uses pseudo-interrupts for
various types of communications with guests, so there needs to be room
for more interrupt handlers.
- An events mechanism has been built on top of the interrupt management
code so that the hypervisor can pass information into guest systems.
The virtual machines can also use event channels to communicate with
each other.
- Much of the i386 initialization code is split out so that
subarchitectures can override it. Since a Xen-hosted kernel is not
booting on cold hardware, and it will not use a number of hardware
features, it will have to initialize itself differently than the host
system does.
- A version of the dynamic
tick patch is used to keep idle virtual machines from wasting time
servicing timer interrupts. There is also a separate timekeeping
implementation which allows guest systems to perform their own
timekeeping without having to involve the hypervisor.
- A whole range of virtual devices has been provided. These include a console, virtual network interfaces, and virtual block devices.
Then, there are a couple of changes to the core (host) kernel:
- A new set of synchronous bit operations, with names like
synch_set_bit(). These operations differ from the regular
bit operations in that they are always atomic. The regular bit
operations will, when built for a uniprocessor system, use
less-expensive, non-atomic operations. But that will not work well if
a uniprocessor Xen guest runs on an SMP host.
- The function apply_to_page_range() will call a given function for every page table entry in a given range. This patch seems worth merging ahead of the rest of Xen; currently, code iterating through PTEs duplicates a complicated set of functions for walking through the page table structure.
There has been a fair amount of comment on the patches, but few objections of great substance. Instead, the Xen developers look to have a long list of nits to address. The most fundamental complaints, perhaps, concern the network driver, which includes its own, built-in ARP implementation. The Xen developers defend this code as being necessary for fast migration of Xen guests. If the ARP code were moved to a more appropriate place - user space, for example - a migration which happens in milliseconds could turn into a one-second (or longer) affair, and that is not a cost the Xen folks want to pay. The addition of files to /proc is also unpopular, but that code was already on the list of things to fix.
When Xen might actually merge is still unclear. There is work to be done
still, and it is a large body of code for the developers to work through.
But that date is getting closer, now that there is code to discuss.
| Index entries for this article | |
|---|---|
| Kernel | Virtualization/Xen |
| Kernel | Xen |