|
|
| (370 intermediate revisions by 4 users not shown) |
| Line 1: |
Line 1: |
| | [[Category:Virtualization]] <!-- do not copy into FWN issue --> |
| | |
| {{Anchor|Virtualization}} | | {{Anchor|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: [[DaleBewley | Dale Bewley]]
| |
|
| |
|
| === Enterprise Management Tools List === | | == Virtualization == |
| This section contains the discussion happening on the [https://www.redhat.com/mailman/listinfo/et-mgmt-tools et-mgmt-tools list]
| | In this section, we cover discussion of Fedora virtualization technologies on the |
| | | @fedora-virt list. |
| === Fedora Xen List ===
| |
| This section contains the discussion happening on the [https://www.redhat.com/mailman/listinfo/fedora-xen fedora-xen list].
| |
| | |
| ==== Status of dom0 Support in Vanilla Kernel ====
| |
| [[PasiKärkkäinen|Pasi Kärkkäinen]] forwarded[1] a message[2] from [[Jeremy Fitzhardinge|Jeremy Fitzhardinge]] originally to the @xen-devel list.
| |
| | |
| <pre>
| |
| .28 was a bit optimistic; .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.
| |
| </pre>
| |
| | |
| [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
| |
| | |
| Just two days later Jeremy posted[3] a large set of patches to @xen-devel.
| |
| | |
| <pre>
| |
| Here's the chunk of patches to add Xen Dom0 support (it's probably
| |
| worth creating a new xen/dom0 topic branch for it).
| |
| | |
| 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. An earlier patch introduced
| |
| the _PAGE_IOMAP pte flag, which we use to distinguish between a
| |
| regular pseudo-physical mapping and a real machine mapping.
| |
| Everything falls out pretty cleanly. A consequence is that the
| |
| various pieces of table-parsing code - DMI, ACPI, MP, etc - work out
| |
| of the box.
| |
| | |
| Similarly, the series adds hooks into swiotlb so that architectures
| |
| can allocate the swiotlb memory appropriately; on the x86/xen side,
| |
| Xen hooks these allocation functions to make special hypercalls to
| |
| guarantee that the allocated memory is contiguous in machine memory.
| |
| | |
| Interrupts are a very different affair. The descriptions in each
| |
| patch describe how it all fits together in detail, but the overview
| |
| is:
| |
| | |
| 1. Xen owns the local APICs; the dom0 kernel controls the IO APICs
| |
| 2. Hardware interrupts are delivered on event channels like everything else
| |
| 3. 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 into all this.
| | Contributing Writer: [[User:Dale | Dale Bewley]] |
|
| |
|
| So, in summary, this series contains:
| | === Fedora Virtualization List === |
| - dom0 console support
| | This section contains the discussion happening on the |
| - dom0 xenbus support
| | [http://www.redhat.com/mailman/listinfo/fedora-virt fedora-virt list]. |
| - 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
| | ==== Virt Status Report ==== |
| enabled. If it is enabled, it will only have an effect if booted as a
| | [[JustinForbes|Justin Forbes]] |
| dom0 kernel; normal native execution and domU execution should be
| | posted<ref>http://www.redhat.com/archives/fedora-virt/2009-December/msg00056.html</ref> a Fedora virtualization status report. |
| unaffected.
| | Justin pointed out F13 bugs<ref>http://fedoraproject.org/wiki/Virtualization_bugs</ref> now include Important and Pony classifications in addition to Blocker and Target. |
| </pre> | |
|
| |
|
| [3] http://lists.xensource.com/archives/html/xen-devel/2008-11/msg00268.html
| | <references /> |
|
| |
|
| === Libvirt List === | | ==== RHEL and Fedora Virtualization Feature Parity ==== |
| This section contains the discussion happening on the [http://www.redhat.com/mailman/listinfo/libvir-list libvir-list].
| | Robert Day wondered how the virtualization features<ref>http://www.redhat.com/virtualization/rhev/</ref> of Red Hat Enterprise Linux 5.4 |
| | compared to Fedora 12. |
|
| |
|
| ==== OpenVZ bridge support ====
| | [[DanielBerrange|Daniel Berrange]] |
| <pre> | | explained<ref>http://www.redhat.com/archives/fedora-virt/2009-December/msg00040.html</ref> |
| This is an update of the patch
| | "The KVM based virtualization in RHEL-5.4 is not nearly so far behind |
| | Fedora as you might think. The {{package|libvirt}} mgmt stack in RHEL-5.4 was |
| | rebased to be near parity with [[Releases/11|Fedora 11]], and KVM in RHEL-5.4 is |
| | also pretty close to that using what's best described as a hybrid of |
| | kvm-83 and kvm-84." |
|
| |
|
| http://www.redhat.com/archives/libvir-list/2008-October/msg00326.html
| | <references /> |
|
| |
|
| 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
| |
| </pre>
| |
|
| |
|
| [1] http://www.redhat.com/archives/libvir-list/2008-November/msg00117.html
| | ==== ==== |
| | <references /> |
|
| |
|
| === oVirt Devel List === | | ==== ==== |
| This section contains the discussion happening on the [https://www.redhat.com/mailman/listinfo/ovirt-devel ovirt-devel list].
| | <references /> |
libvirt