Hi > On 9 Jun 2020, at 16:47, Julien Grall <jul...@xen.org> wrote: > > > > On 09/06/2020 16:28, Bertrand Marquis wrote: >> Hi, >>> On 9 Jun 2020, at 15:33, CodeWiz2280 <codewiz2...@gmail.com> 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.
Agree the maintenance interrupt would definitely be the right solution. This was an easy ack to check if that was the source of the problem. > >> This might make the interrupt fire indefinitely !! > > Most likely with level interrupt ;). Yes but this is just to confirm ;-) > > Cheers, > > -- > Julien Grall
