[<prev] [next>] [thread-next>] [day] [month] [year] [list]
Message-Id: <cover.1234573847.git.jeremy.fitzhardinge@citrix.com>
Date: Fri, 13 Feb 2009 17:11:57 -0800
From: Jeremy Fitzhardinge <jeremy@...p.org>
To: Ingo Molnar <mingo@...e.hu>
Cc: the arch/x86 maintainers <x86@...nel.org>,
Xen-devel <xen-devel@...ts.xensource.com>,
Linux Kernel Mailing List <linux-kernel@...r.kernel.org>,
Yinghai Lu <yinghai@...nel.org>,
Ian Campbell <Ian.Campbell@...rix.com>,
Jeremy Fitzhardinge <jeremy.fitzhardinge@...rix.com>
Subject: [PATCH 0/9] x86/apic: hooks for Xen dom0 support
From: Jeremy Fitzhardinge <jeremy.fitzhardinge@...rix.com>
This series adds a some hooks into the APIC code to allow Xen's dom0
support to hook in.
A dom0 kernel's interactions with the hypervisor and the platform
interrupt hardware are... interesting.
The overview is:
Xen itself owns the local APICs, and the kernel is not allowed to
touch them directly. Instead, interrupts from hardware are
delivered like all other interrupts in Xen: as events coming over
an event channel. This means that Xen is also responsible for
vector allocation.
The dom0 kernel does, however, own the IO APICs, and is responsible
for programming them appropriately. It uses ACPI to do the interrupt
routing to find the GSI for a given device, and then asks Xen to
allocate a vector for it, which gets mapped to an event channel. It
then programs that vector into the IO APICs so that hardware
interrupts are deliverered on that event channel. When an event is
raised, it feeds it into the kernel's normal interrupt handling path
to be distributed among the interested device drivers as normal.
Details:
1. We change acpi_register_lapic and acpi_register_lapic_address to
prevent the lapics from actually being registered under Xen. We
still want them to be discovered by ACPI, just not used.
2. Despite controlled the IO APICs, the dom0 kernel can't map them
directly as usual, but must program their registers via hypercalls,
so we need to hook into the io_apic accessors accordingly. This is
done with an explicit test and call for Xen, rather than being
abstracted via an _ops layer, on the grounds that this is something
that's unlikely for anyone else to want to do (and we can always
add an _ops layer if there's a second user).
3. Hook acpi_register_gsi(). This sets up all the pirq event channel
state for the gsi, including allocating an event channel bound to a
vector and setting up the routing. It returns the irq, which is always
equal to the gsi.
Thanks,
J
Ian Campbell (1):
xen: pre-initialize legacy irqs early
Jeremy Fitzhardinge (8):
xen/dom0: handle acpi lapic parsing in Xen dom0
xen: hook io_apic read/write operations
xen: create dummy ioapic mapping
xen: implement pirq type event channels
x86/io_apic: add get_nr_irqs_gsi()
xen/apic: identity map gsi->irqs
xen: direct irq registration to pirq event channels
xen: bind pirq to vector and event channel
arch/x86/include/asm/io_apic.h | 7 +
arch/x86/include/asm/xen/pci.h | 13 ++
arch/x86/kernel/acpi/boot.c | 18 +++-
arch/x86/kernel/io_apic.c | 37 +++++-
arch/x86/xen/Kconfig | 11 ++
arch/x86/xen/Makefile | 4 +-
arch/x86/xen/apic.c | 57 +++++++++
arch/x86/xen/enlighten.c | 2 +
arch/x86/xen/mmu.c | 10 ++
arch/x86/xen/pci.c | 81 +++++++++++++
arch/x86/xen/xen-ops.h | 6 +
drivers/xen/events.c | 260 +++++++++++++++++++++++++++++++++++++++-
include/xen/events.h | 22 ++++
13 files changed, 520 insertions(+), 8 deletions(-)
create mode 100644 arch/x86/include/asm/xen/pci.h
create mode 100644 arch/x86/xen/apic.c
create mode 100644 arch/x86/xen/pci.c
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Powered by blists - more mailing lists