Re: Keystone Issue

[Julien Grall <julien@xxxxxxx>]

On 09/06/2020 16:28, Bertrand Marquis wrote:
> Hi,
>
> > On 9 Jun 2020, at 15:33, CodeWiz2280 <codewiz2280@xxxxxxxxx> wrote:
> >
> > There does appear to be a secondary (CIC) controller that can forward
> > events to the GIC-400 and EDMA controllers for the keystone 2 family.
> > Admittedly, i'm not sure how it is being used with regards to the
> > peripherals.  I only see mention of the GIC-400 parent for the devices
> > in the device tree.  Maybe Bertrand has a better idea on whether any
> > peripherals go through the CIC first?  I see that gic_interrupt ()
> > fires once in Xen, which calls doIRQ to push out the virtual interrupt
> > to the dom0 kernel.  The dom0 kernel then handles the interrupt and
> > returns, but gic_interrupt() never fires again in Xen.
> I do not remember of any CIC but the behaviour definitely look like an 
> interrupt acknowledge problem.
>
> Could you try the following:
> --- a/xen/arch/arm/gic-v2.c
> +++ b/xen/arch/arm/gic-v2.c
> @@ -667,6 +667,9 @@ static void gicv2_guest_irq_end(struct irq_desc *desc)
>       /* Lower the priority of the IRQ */
>       gicv2_eoi_irq(desc);
>       /* Deactivation happens in maintenance interrupt / via GICV */
> +
> +    /* Test for Keystone2 */
> +    gicv2_dir_irq(desc);
>   }
>
> I think the problem I had was related to the vgic not deactivating properly the 
> interrupt.
Are you suggesting the guest EOI is not properly forwarded to the 
hardware when LR.HW is set? If so, this could possibly be workaround in 
Xen by raising a maintenance interrupt every time a guest EOI an interrupt.
> This might make the interrupt fire indefinitely !!
Most likely with level interrupt ;).

Cheers,

--
Julien Grall