|
|
| (369 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 Upstream Kernel ====
| |
| [[PasiKärkkäinen|Pasi Kärkkäinen]] forwarded[1] a message[2] from [[Jeremy Fitzhardinge|Jeremy Fitzhardinge]], originally to the @xen-devel list, describing the state of dom0 support in the upstream <code>kernel</code>.
| |
| | |
| ".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 <code>blktap</code> 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:'''
| | Contributing Writer: [[User:Dale | Dale Bewley]] |
| * 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 <code>CONFIG_XEN_DOM0</code> is not
| | === Fedora Virtualization List === |
| enabled. If it is enabled, it will only have an effect if booted as a
| | This section contains the discussion happening on the |
| dom0 kernel; normal native execution and domU execution should be
| | [http://www.redhat.com/mailman/listinfo/fedora-virt fedora-virt list]. |
| unaffected."
| |
|
| |
|
| [4] http://lists.xensource.com/archives/html/xen-devel/2008-11/msg00268.html | | ==== Virt Status Report ==== |
| | [[JustinForbes|Justin Forbes]] |
| | posted<ref>http://www.redhat.com/archives/fedora-virt/2009-December/msg00056.html</ref> a Fedora virtualization status report. |
| | 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. |
|
| |
|
| [5] http://lwn.net/Articles/44139/
| | <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