Re: [Xen-devel] [RFC 05/19] xen/arm: Release IRQ routed to a domain when it's destroying

[Stefano Stabellini <stefano.stabellini@xxxxxxxxxxxxx>]

On Wed, 18 Jun 2014, Julien Grall wrote:
> On 18/06/14 19:48, Stefano Stabellini wrote:
> > > I can add an ASSERT(irq_get_domain(desc)->is_dying) here...
> > 
> > The ASSERT is a good idea.
> > 
> > Given that the domain has been descheduled, gic_update_one_lr won't work
> > but you can read the saved lr (pending_irq->lr) from v->arch.gic_lr.
> > You can obtain the target vcpu calling vgic_get_target_vcpu.
> > You only need to write to GICC_DIR if (gic_lr &
> > (GICH_LR_ACTIVE|GICH_LR_PENDING)).
> > gic_remove_from_queues should still work.
> 
> Unless we assume a virq == pirq  we can't retrieve the irq_pending structure
> via an irq_desc.

That's annoying. We might have to fix this sooner or later.


> Also this may has been free earlier, even tho for now SPIs
> are stored directly in arch_domain.
> 
> I prefer to keep the check IRQ_INPROGRESS, and call gic_update_lrs before
> unscheduled the VCPU.

I was thinking about this alternative, and it is better (see below).


> BTW, is it the case?
 
At the moment gic_update_lrs is called on hypervisor entry, so whenever
the vcpu gets interrupted, gic_update_lrs is called.  If
gic_reset_guest_irq is called always after all the guest vcpus have been
descheduled, IRQ_INPROGRESS is surely up to date and you don't need to
go through the lrs.



> > Also I wonder if you need to call gic_reset_guest_irq before
> > desc->handler->shutdown.
> > The specification states (4.3.5):
> > 
> > 'Disabling an interrupt only disables the forwarding of the interrupt
> > from the Distributor to any CPU interface. It does not prevent the
> > interrupt from changing state, for example becoming pending, or active
> > and pending if it is already active.'
> > 
> > So from the text above I think that EOIing an interrupt that has been
> > disabled at the GICD level should work, but it is not 100% clear.
> 
> On oneshot IRQ, Linux is disabling the IRQ before EOIing it. This will avoid
> to receive spurious interrupt.
> 
> Here we need to do the same thing otherwise we may receive spurious interrupt.
> 

Good to know

_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxx
http://lists.xen.org/xen-devel