From mboxrd@z Thu Jan 1 00:00:00 1970 From: "Jan Beulich" Subject: [PATCH] x86: start PCI IRQs Xen uses from Dom0-invoked io_apic_set_pci_routing() Date: Wed, 31 Mar 2010 09:18:20 +0100 Message-ID: <4BB3216C0200007800038133@vpn.id2.novell.com> Mime-Version: 1.0 Content-Type: multipart/mixed; boundary="=__PartC9E33C5C.0__=" Return-path: List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: xen-devel-bounces@lists.xensource.com Errors-To: xen-devel-bounces@lists.xensource.com To: xen-devel@lists.xensource.com List-Id: xen-devel@lists.xenproject.org This is a MIME message. If you are reading this text, you may want to consider changing to a mail reader or gateway that understands how to properly handle MIME multipart messages. --=__PartC9E33C5C.0__= Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: quoted-printable Content-Disposition: inline When using a serial port from an add-in PCI card, and that IRQ is (as usual) outside of the legacy range (0...15), Xen would never really enable the IRQ, as at the time setup_irq() runs the handler for the IRQ still is &no_irq_type. Consequently, once the trigger mode and polarity of the interrupt become known to Xen, it should start such IRQ(s) it uses for itself. The question is whether the same should also be done in ioapic_guest_write(): Legacy kernels don't use PHYSDEVOP_setup_gsi (and hence don't trigger the code path modified).=20 Note however that even when a kernel is using PHYSDEVOP_setup_gsi in the way the pv-ops kernel currently does, there's still no guarantee that the call would ever be issued for IRQs Xen may be using, since this happens only when devices get enabled. For Xen's purposes, this function should be called for *all* device IRQs, regardless of whether those would actually be (attempted to be) used by the kernel, i.e. in a subsys_initcall() from drivers/acpi/pci_irq.c iterating over all PCI devices and doing mostly what acpi_pci_irq_enable() does except for calling this function in place of acpi_register_gsi(). The downside of this approach is that without extra filtering in Xen (based on a hint from Dom0), vectors will then get up even for IRQs that are unused by both hypervisor and kernel. Signed-off-by: Jan Beulich --- 2010-03-22.orig/xen/arch/x86/io_apic.c 2010-03-22 00:00:00.0000000= 00 +0100 +++ 2010-03-22/xen/arch/x86/io_apic.c 2010-03-23 15:48:14.000000000 = +0100 @@ -2113,6 +2113,7 @@ int __init io_apic_get_redir_entries (in =20 int io_apic_set_pci_routing (int ioapic, int pin, int irq, int edge_level,= int active_high_low) { + struct irq_desc *desc =3D irq_to_desc(irq); struct IO_APIC_route_entry entry; unsigned long flags; int vector; @@ -2166,6 +2167,11 @@ int io_apic_set_pci_routing (int ioapic, set_native_irq_info(irq, TARGET_CPUS); spin_unlock_irqrestore(&ioapic_lock, flags); =20 + spin_lock(&desc->lock); + if (!(desc->status & (IRQ_DISABLED | IRQ_GUEST))) + desc->handler->startup(irq); + spin_unlock(&desc->lock); + return 0; } =20 --=__PartC9E33C5C.0__= Content-Type: text/plain; name="x86-startup-irq-from-setup-gsi.patch" Content-Transfer-Encoding: quoted-printable Content-Disposition: attachment; filename="x86-startup-irq-from-setup-gsi.patch" When using a serial port from an add-in PCI card, and that IRQ is = (as=0Ausual) outside of the legacy range (0...15), Xen would never = really=0Aenable the IRQ, as at the time setup_irq() runs the handler for = the=0AIRQ still is &no_irq_type. Consequently, once the trigger mode = and=0Apolarity of the interrupt become known to Xen, it should start = such=0AIRQ(s) it uses for itself.=0A=0AThe question is whether the same = should also be done in=0Aioapic_guest_write(): Legacy kernels don't use = PHYSDEVOP_setup_gsi=0A(and hence don't trigger the code path modified). = =0A=0ANote however that even when a kernel is using PHYSDEVOP_setup_gsi = in=0Athe way the pv-ops kernel currently does, there's still no = guarantee=0Athat the call would ever be issued for IRQs Xen may be using, = since=0Athis happens only when devices get enabled. For Xen's purposes, = this=0Afunction should be called for *all* device IRQs, regardless = of=0Awhether those would actually be (attempted to be) used by the = kernel,=0Ai.e. in a subsys_initcall() from drivers/acpi/pci_irq.c = iterating=0Aover all PCI devices and doing mostly what acpi_pci_irq_enable(= ) does=0Aexcept for calling this function in place of acpi_register_gsi(). = The=0Adownside of this approach is that without extra filtering in = Xen=0A(based on a hint from Dom0), vectors will then get up even for = IRQs=0Athat are unused by both hypervisor and kernel.=0A=0ASigned-off-by: = Jan Beulich =0A=0A--- 2010-03-22.orig/xen/arch/x86/io_= apic.c 2010-03-22 00:00:00.000000000 +0100=0A+++ 2010-03-22/xen/arch/x86/i= o_apic.c 2010-03-23 15:48:14.000000000 +0100=0A@@ -2113,6 +2113,7 = @@ int __init io_apic_get_redir_entries (in=0A =0A int io_apic_set_pci_rout= ing (int ioapic, int pin, int irq, int edge_level, int active_high_low)=0A = {=0A+ struct irq_desc *desc =3D irq_to_desc(irq);=0A struct = IO_APIC_route_entry entry;=0A unsigned long flags;=0A int = vector;=0A@@ -2166,6 +2167,11 @@ int io_apic_set_pci_routing (int = ioapic,=0A set_native_irq_info(irq, TARGET_CPUS);=0A spin_unlock_ir= qrestore(&ioapic_lock, flags);=0A =0A+ spin_lock(&desc->lock);=0A+ = if (!(desc->status & (IRQ_DISABLED | IRQ_GUEST)))=0A+ desc->handler-= >startup(irq);=0A+ spin_unlock(&desc->lock);=0A+=0A return 0;=0A = }=0A =0A --=__PartC9E33C5C.0__= Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel --=__PartC9E33C5C.0__=--