[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] Re: [Xen-devel] [PATCH-4.5 3/4] xen/arm: do not request maintenance_interrupts
On 02/10/2014 05:03 PM, Stefano Stabellini wrote: > >>> + inflight = 0; >>> + GICH[GICH_LR + i] = 0; >>> + clear_bit(i, &this_cpu(lr_mask)); >>> + >>> + spin_lock(&gic.lock); >>> + p = irq_to_pending(v, irq); >>> + if ( p->desc != NULL ) >>> + p->desc->status &= ~IRQ_INPROGRESS; >>> + clear_bit(GIC_IRQ_GUEST_VISIBLE, &p->status); >>> + if ( test_bit(GIC_IRQ_GUEST_PENDING, &p->status) && >>> + test_bit(GIC_IRQ_GUEST_ENABLED, &p->status)) >>> + { >> >> I would add a WARN_ON(p->desc != NULL) here. AFAIK, this code path shouldn't >> be used for physical IRQ. > > That's not true: an edge physical irq can come through while another one > of the same type is being handled. In fact pending and active bits exist > even on the physical GIC interface. > It won't be fired until the previous one is EOIed. The physical GIC interface will keep it internally. But ... after thinking the WARN is stupid here because we can have this following case: IRQ A fired -> inject IRQ A IRQ A eoied IRQ A fired -> set pending bits clear lrs -> re-inject IRQ A -- Julien Grall _______________________________________________ Xen-devel mailing list Xen-devel@xxxxxxxxxxxxx http://lists.xen.org/xen-devel
|
Lists.xenproject.org is hosted with RackSpace, monitoring our |