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

[Julien Grall <julien.grall@xxxxxxxxxx>]

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. 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. BTW, is it the case?
> 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.
Regards,

--
Julien Grall

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