Re: Keystone Issue

[Bertrand Marquis <Bertrand.Marquis@xxxxxxx>]

> On 9 Jun 2020, at 16:58, CodeWiz2280 <codewiz2280@xxxxxxxxx> wrote:
> 
> On Tue, Jun 9, 2020 at 11:47 AM Julien Grall <julien@xxxxxxx> wrote:
>> 
>> 
>> 
>> 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.
>> 
> This seemed to help with the edge triggered interrupts, e.g. UART

So the missing ack is definitely the issue.

> 
>> 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 ;).
>> 
> This is what's happening with the Ethernet driver which is level
> triggered.  I had to temporarily disable it
> to check the patch with the UART driver, otherwise the system would
> hang processing the interrupt
> repeatedly.

This is quite logic yes.
The way forward, as mentioned by Julien, will be to use a maintenance interrupt 
when the interrupt has been handled by the guest so that Xen can do the 
deactivation of the corresponding interrupt.
This will add some overhead but there is probably no other solution.

Cheers
Bertrand