[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] Re: [Xen-devel] [PATCH v4 03/10] xen/arm: support HW interrupts, do not request maintenance_interrupts
Hi Stefano, On 03/19/2014 12:31 PM, Stefano Stabellini wrote: [..] > @@ -625,16 +628,19 @@ int __init setup_dt_irq(const struct dt_irq *irq, > struct irqaction *new) > static inline void gic_set_lr(int lr, struct pending_irq *p, > unsigned int state) > { > - int maintenance_int = GICH_LR_MAINTENANCE_IRQ; > + uint32_t lr_reg; > > BUG_ON(lr >= nr_lrs); > BUG_ON(lr < 0); > BUG_ON(state & ~(GICH_LR_STATE_MASK<<GICH_LR_STATE_SHIFT)); > > - GICH[GICH_LR + lr] = state | > - maintenance_int | > - ((p->priority >> 3) << GICH_LR_PRIORITY_SHIFT) | > + lr_reg = state | ((p->priority >> 3) << GICH_LR_PRIORITY_SHIFT) | > ((p->irq & GICH_LR_VIRTUAL_MASK) << GICH_LR_VIRTUAL_SHIFT); > + if ( p->desc != NULL ) > + lr_reg |= GICH_LR_HW | > + ((p->desc->irq & GICH_LR_PHYSICAL_MASK) << > GICH_LR_PHYSICAL_SHIFT); > + > + GICH[GICH_LR + lr] = lr_reg; > > set_bit(GIC_IRQ_GUEST_VISIBLE, &p->status); > clear_bit(GIC_IRQ_GUEST_PENDING, &p->status); > @@ -669,7 +675,7 @@ void gic_remove_from_queues(struct vcpu *v, unsigned int > virtual_irq) > spin_unlock_irqrestore(&gic.lock, flags); > } > > -void gic_set_guest_irq(struct vcpu *v, unsigned int virtual_irq, > +void gic_set_guest_irq(struct vcpu *v, unsigned int irq, Any reason to rename virtual_irq into irq? [..] > +static void gic_clear_lrs(struct vcpu *v) > +{ > + struct pending_irq *p; > + int i = 0, irq; > + uint32_t lr; > + bool_t inflight; > + > + ASSERT(!local_irq_is_enabled()); > + > + while ((i = find_next_bit((const long unsigned int *) &this_cpu(lr_mask), > + nr_lrs, i)) < nr_lrs) { > + lr = GICH[GICH_LR + i]; > + if ( !(lr & (GICH_LR_PENDING|GICH_LR_ACTIVE)) ) > + { > + inflight = 0; > + GICH[GICH_LR + i] = 0; > + clear_bit(i, &this_cpu(lr_mask)); > + > + irq = (lr >> GICH_LR_VIRTUAL_SHIFT) & GICH_LR_VIRTUAL_MASK; > + spin_lock(&gic.lock); Not completely related to this patch ... taking gic.lock seems a bit too strong here. The critical section only update data for the current domain. It seems a bit stupid to block the other interrupt to handle their interrupts at the same time. Maybe introducing a dist lock would be a better solution? [..] > void gic_dump_info(struct vcpu *v) > diff --git a/xen/arch/arm/vgic.c b/xen/arch/arm/vgic.c > index aab490c..566f0ff 100644 > --- a/xen/arch/arm/vgic.c > +++ b/xen/arch/arm/vgic.c > @@ -701,8 +701,7 @@ void vgic_vcpu_inject_irq(struct vcpu *v, unsigned int > irq) > if ( (irq != current->domain->arch.evtchn_irq) || > (!test_bit(GIC_IRQ_GUEST_VISIBLE, &n->status)) ) > set_bit(GIC_IRQ_GUEST_PENDING, &n->status); > - spin_unlock_irqrestore(&v->arch.vgic.lock, flags); > - return; > + goto out; We don't want to kick the other VCPU every time. I think it's enough when the interrupt is updated. Regards, -- Julien Grall _______________________________________________ Xen-devel mailing list Xen-devel@xxxxxxxxxxxxx http://lists.xen.org/xen-devel
|
Lists.xenproject.org is hosted with RackSpace, monitoring our |