|
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] Re: [Xen-devel] [PATCH v7 11/12] xen/arm: gic_events_need_delivery and irq priorities
> > On Wed, 23 Apr 2014, Ian Campbell wrote:
> > > On Tue, 2014-04-08 at 16:12 +0100, Stefano Stabellini wrote:
> > > > + mask_priority = (GICH[GICH_VMCR] >> GICH_VMCR_PRIORITY_SHIFT) &
> > > > GICH_VMCR_PRIORITY_MASK;
> > >
> > > mask_priority is a bit meaningless (I know the docs call it
> > > priority_mask), but its the vcpus current priority, right?
> >
> > It is the minimum priority that an interrupt needs to have for the cpu
> > to be interrupted by the gic.
>
> OK, I think you are stating the same thing as me but from a different
> angle.
> >
> >
> > > Also, by adding a << 3 here then I think the rest of the logic reads
> > > more easily, because you are then using the priority directly, and
> > > ignoring the fact that VMCR has a limited precision. Whereas with the
> > > shift >> 3 at the comparison sights you kind of have to think about it
> > > in each case.
> > >
> > > > +
> > > > + spin_lock_irqsave(&v->arch.vgic.lock, flags);
> > > > +
> > > > + /* TODO: We order the guest irqs by priority, but we don't change
> > > > + * the priority of host irqs. */
> > > > + list_for_each_entry( p, &v->arch.vgic.inflight_irqs, inflight )
> > > > + {
> > > > + if ( test_bit(GIC_IRQ_GUEST_ACTIVE, &p->status) )
> > > > + {
> > > > + if ( p->priority < active_priority )
> > > > + active_priority = p->priority;
> > > > + break;
> > > > + } else if ( test_bit(GIC_IRQ_GUEST_ENABLED, &p->status) ) {
> > > > + if ( p->priority < max_priority )
> > > > + max_priority = p->priority;
> > > > + }
> > > > + if ( (p->priority >> 3) >= mask_priority )
> > > > + break;
> > >
> > > This lrs-- stuff needs a comment. I think along the lines of only the
> > > first nr_lrs interrupt need to be considered because XXX.
> > >
> > > Not sure what XXX is -- if we have 4 lrs and inflight_irqs has 10
> > > entries on it (say) of which the first 5 happen to be masked, don't we
> > > want to keep going until we've looked at more than the first 4 entries
> > > or something? Or should this decrement be conditional on ENABLE and/or
> > > ACTIVE perhaps?
> >
> > If we have 4 lrs and inflight_irqs has 10 entries on it (say) of which
> > the first 5 happen to be masked, we want to keep going until we've
> > looked at more than the first 4 entries but we certainly cannot swap
> > more than 4 entries.
>
> I think what is confusing me is that I don't see where the lrs-- is
> skipped for a masked interrupt. So aren't you counting down the lrs
> variable even for the first 5 which happen to be masked?
At the moment when the guest disables an irq, we remove it from the
lr_pending queue but we don't remove it from the inflight queue. So if
the irq has already been added to an LR register, the guest is going to
receive a notification still.
This patch doesn't change this behaviour: the eviction code in
gic_restore_pending_irqs doesn't distinguish between masked and unmasked
irqs, it treats them the same way, simply going by priority.
Consistently in gic_events_need_delivery, we only analyze the first
nr_lrs irqs by priority, regardless if they are masked or unmasked.
To answer your original question: no, we don't need to keep going past
the first 4 irqs in inflight_irqs, even if they are all masked.
Admittedly this behaviour could be improved, but it might be best to fix
it in a consequent patch series.
> > > You exit the loop as soon as you see an ACTIVE IRQ, but can't you also
> > > exit if you see an ENABLED IRQ? If you see an enabled IRQ but you
> > > haven't yet seen an active one then don't you know that max_priority <
> > > active_priority? (this might be best discussed around a whiteboard...)
> > >
> > > > + lrs--;
> > > > + if ( lrs == 0 )
> > > > + break;
> > > > + }
> > > > +
> > > > + spin_unlock_irqrestore(&v->arch.vgic.lock, flags);
> > > > +
> > > > + if ( max_priority < active_priority &&
> > > > + (max_priority >> 3) < mask_priority )
> > > > + return 1;
> > > > + else
> > > > + return 0;
> > > > }
> > > >
> > > > void gic_inject(void)
> > >
> > > Ian
> > >
>
>
_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxx
http://lists.xen.org/xen-devel
|
![]() |
Lists.xenproject.org is hosted with RackSpace, monitoring our |