search for: irq_inprogress

<<handle_msi_irq_storm.patch>> Hi, Keir, This patch handles MSI irq storm. Unluckily, I have observed this phenomenon again. This will happen when some kind of MSI-X capable NIC is assigned to an HVM guest. The basic idea is to mask the interrupt on receiving the second interrupt and set a timer to unmask after 1ms. Can you have a look and give some comments on that? Thanks! Best

Patch 1 removes CONFIG_SMP Patch 2 removes separate smp_{,r,w}mb()s as a result of patch 1 Patch 4 removes __ia64__ defines from the x86 arch tree Patch 3 is related to patch 4 and changes the VIOAPIC to emulate version 0x20 as a performance gain. It preceeds Patch 4 so as to be more clear about the functional change. Signed-off-by: Andrew Cooper <andrew.cooper3@citrix.com>

...= 0; spin_lock_irq(&gic.lock); lr = GICH[GICH_LR + i]; @@ -754,11 +764,23 @@ static void maintenance_interrupt(int irq, void *dev_id, struct cpu_user_regs *r p = irq_to_pending(v, virq); if ( p->desc != NULL ) { p->desc->status &= ~IRQ_INPROGRESS; - GICC[GICC_DIR] = virq; + /* Assume only one pcpu needs to EOI the irq */ + cpu = cpumask_first(&p->eoimask); + cpumask_clear(&p->eoimask); + eoi = 1; } list_del_init(&p->inflight); spin_unlock_...

...= 0; spin_lock_irq(&gic.lock); lr = GICH[GICH_LR + i]; @@ -754,11 +764,22 @@ static void maintenance_interrupt(int irq, void *dev_id, struct cpu_user_regs *r p = irq_to_pending(v, virq); if ( p->desc != NULL ) { p->desc->status &= ~IRQ_INPROGRESS; - GICC[GICC_DIR] = virq; + /* Assume only one pcpu needs to EOI the irq */ + cpu = p->desc->arch.eoi_cpu; + eoi = 1; } list_del_init(&p->inflight); spin_unlock_irq(&v->arch.vgic.lock); + if ( eoi )...

...} + spin_unlock(&gic.lock); spin_lock(&current->arch.vgic.lock); p = irq_to_pending(current, virq); @@ -449,7 +501,6 @@ static void maintenance_interrupt(int irq, void *dev_id, struct cpu_user_regs *r p->desc->status &= ~IRQ_INPROGRESS; GICC[GICC_DIR] = virq; } - gic_inject_irq_stop(); list_del(&p->link); INIT_LIST_HEAD(&p->link); cpu_raise_softirq(current->processor, VGIC_SOFTIRQ); diff --git a/xen/include/asm-arm/domain.h b/xen/incl...

...uct irqaction *new) goto out_thread; } else compat_irq_chip_set_default_handler(desc); -#if defined(CONFIG_IRQ_PER_CPU) + if (new->flags & IRQF_PERCPU) desc->status |= IRQ_PER_CPU; -#endif desc->status &= ~(IRQ_AUTODETECT | IRQ_WAITING | IRQ_ONESHOT | IRQ_INPROGRESS | IRQ_SPURIOUS_DISABLED); _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel

There is a BUG_ON() at xen/arch/x86/physdev.c:169 which appears to be dependent upon guest behavior (should close event channel before un-mapping pirq), rather than on internal hypervisor state. In 2.6.18, this likely goes unnoticed because pci_device_shutdown() only calls all the driver shutdown routines. In newer kernels, however, it also calls pci_msi_shutdown() and pci_msix_shutdown(), which

(moving to xen-devel, xen-arm is for the older PV ARM port) On Tue, 2013-06-25 at 23:59 +0000, Eric Trudeau wrote: > Hi, I am trying to build the XEN tools for our port of XEN to our > Cortex A15-based platform. > > I am using the repo at git://xenbits.xenproject.org/xen.git to > cross-compile the tools into our rootfs. Which branch/changeset are you using? I've heard that

Hello everyone, this is the fourth version of the patch series that introduces ARMv7 with virtualization extensions support in Xen. The series allows Xen and Dom0 to boot on a Cortex-A15 based Versatile Express simulator. See the following announce email for more informations about what we are trying to achieve, as well as the original git history: See

Hello everyone, this is the very first version of the patch series that introduces ARMv7 with virtualization extensions support in Xen. The series allows Xen and Dom0 to boot on a Cortex-A15 based Versatile Express simulator. See the following announce email for more informations about what we are trying to achieve, as well as the original git history: See

Hi, Keir, These patches are rebased version of Yunhong''s original patches, which were sent out before XEN 3.2 was released. These patches enable MSI support and limited MSI-X support in XEN. Here is the original description of the patches from Yunhong''s mail. The basic idea including: 1) Keep vector global resource owned by xen, while split pirq into per-domain