FWN/Beats/Virtualization

Virtualization

In this section, we cover discussion on the @et-mgmnt-tools-list, @fedora-xen-list, @libvirt-list and @ovirt-devel-list of Fedora virtualization technologies.

Contributing Writer: Dale Bewley

Enterprise Management Tools List

This section contains the discussion happening on the et-mgmt-tools list

Fedora Xen List

This section contains the discussion happening on the fedora-xen list.

Status of dom0 Support in Upstream Kernel

Pasi Kärkkäinen forwarded[1] a message[2] from Jeremy Fitzhardinge, originally to the @xen-devel list, describing the state of dom0 support in the upstream kernel.

".28 was a bit optimistic; (FWN#137[3]) .29 seems reasonable. The current dom0 kernel patches can boot up to a fully functional dom0 usersmode, and you can start xend to see that domain 0 is running. I *think* in theory you can create a deviceless domain, but I haven't tried it. I'm currently working on blktap support.

I really need to put together a proper status update. Now that dom0 usermode is working, its a much better base for other people start contributing."

[1] http://www.redhat.com/archives/fedora-xen/2008-November/msg00011.html

[2] http://lists.xensource.com/archives/html/xen-devel/2008-11/msg00205.html

[3] http://fedoraproject.org/wiki/FWN/Issue137#State_of_Xen_in_Upstream_Linux

Just two days later Jeremy posted[4] a large set of patches to @xen-devel with the following explaination.

"A dom0 Xen domain is basically the same as a normal domU domain, but it has extra privileges to directly access hardware. There are two issues to deal with:

translating to and from the domain's pseudo-physical addresses and real machine addresses (for ioremap and setting up DMA)
routing hardware interrupts into the domain

ioremap is relatively easy to deal with. ..."

"... Interrupts are a very different affair. The descriptions in each patch describe how it all fits together in detail, but the overview is:

Xen owns the local APICs; the dom0 kernel controls the IO APICs
Hardware interrupts are delivered on event channels like everything else
To set this up, we intercept at pcibios_enable_irq:

given a dev+pin, we use ACPI to get a gsi
hook acpi_register_gsi to call xen_register_gsi, which
allocates an irq (generally not 1:1 with the gsi)
asks Xen for a vector and event channel for the irq
program the IO APIC to deliver the hardware interrupt to the allocated vector

The upshot is that the device driver gets an irq, and when the hardware raises an interrupt, it gets delivered on that irq.

We maintain our own irq allocation space, since the hardware-bound event channel irqs are intermixed with all the other normal Xen event channel irqs (inter-domain, timers, IPIs, etc). For compatibility the irqs 0-15 are reserved for legacy device interrupts, but the rest of the range is dynamically allocated.

Initialization also requires care. The dom0 kernel parses the ACPI tables as usual, in order to discover the local and IO APICs, and all the rest of the ACPI-provided data the kernel requires. However, because the kernel doesn't own the local APICs and can't directly map the IO APICs, we must be sure to avoid actually touching the hardware when running under Xen.

TODO: work out how to fit MSI[5] into all this.

So, in summary, this series contains:

dom0 console support
dom0 xenbus support
CPU features and IO access for a privleged domain
mtrrs
making ioremap work on machine addresses
swiotlb allocation hooks
interrupts:
- introduce PV io_apic operations
- add Xen-specific IRQ allocator
- switch to using all-Xen event delivery
- add pirq Xen interrupt type
- table parsing and setup
- intercept driver interrupt registration

All this code will compile away to nothing when CONFIG_XEN_DOM0 is not enabled. If it is enabled, it will only have an effect if booted as a dom0 kernel; normal native execution and domU execution should be unaffected."

[4] http://lists.xensource.com/archives/html/xen-devel/2008-11/msg00268.html

[5] http://lwn.net/Articles/44139/

Libvirt List

This section contains the discussion happening on the libvir-list.

OpenVZ Bridge Support Committed

Daniel P. Berrange updated[1] a previous patch[2] designed to "enable bridge support in the OpenVZ driver. As well as the fixes suggested last time, it includes an initial bit of HTML doc for the OpenVZ driver, covering example XML, and the bridge configuration requirements."

[1] http://www.redhat.com/archives/libvir-list/2008-November/msg00117.html

[2] http://www.redhat.com/archives/libvir-list/2008-October/msg00326.html

Qemu/KVM Live Migration Implemented

Chris Lalancette posted[1] the patch to implement Qemu/KVM live migration. After a little upstream cleanup[2], the patch was committed.

"Now that upstream Qemu has settled on an interface that is friendly to libvirt (i.e. one that doesn't block the monitor on -incoming), we can implement it here. Note that the bulk of this patch was written by Rich Jones quite a while ago. My hand in it has mostly been to forward port it to current libvirt CVS, tweak it for the new Qemu style, and test it out with a recent KVM (kvm-78, in particular)."

[1] http://www.redhat.com/archives/libvir-list/2008-November/msg00087.html

[2] http://www.redhat.com/archives/libvir-list/2008-November/msg00092.html