[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] Re: [Xen-devel] [PATCH for-4.12] arm: gic: deactivate sgi immediately after eoi
Hi Julien > -----Original Message----- > From: Julien Grall [mailto:julien.grall@xxxxxxx] > Sent: 2019年1月29日 23:57 > To: Peng Fan <peng.fan@xxxxxxx>; sstabellini@xxxxxxxxxx; jgross@xxxxxxxx > Cc: xen-devel@xxxxxxxxxxxxxxxxxxxx; Andre Przywara > <andre.przywara@xxxxxxx> > Subject: Re: [PATCH for-4.12] arm: gic: deactivate sgi immediately after eoi > > (+ Andre) > > Hi Peng, > > On 24/01/2019 12:43, Peng Fan wrote: > > On i.MX8, we implemented partition reboot which means Cortex-A reboot > > will not impact M4 cores and System control Unit core. However GICv3 > > is not reset because we also need to support A72 Cluster reboot > > without affecting A53 Cluster. > > How about the other interrupts? For instance, it would be theoretically > possible to have a PPI/SPI active and receive the order to turn it off. Is > this > going to be an issue? Currently we only met this issue when doing Xen reboot, because halt_this_cpu never return. For other interrupts, I think they are deactivated properly. > > > > > The gic-v3 controller is configured with EOImode to 1, so during xen > > reboot, there is a function call "smp_call_function(halt_this_cpu, NULL, > > 0);" > > ,but halt_this_cpu never return, that means other CPUs have no chance > > to > > s/,/, / > > > deactive the SGI interrupt, because the deactivate_irq operation is at > > s/deactive/deactivate/ > > > the end of do_sgi. During xen booting again, CPU0 will issue > > s/xen/Xen/ > > Also: > > "During the next boot of Xen," > > > GIC_SGI_CALL_FUNCTION to other CPUs. Because > GIC_SGI_CALL_FUNCTION of > > other CPUs are active during the last reboot, interrupts could not be > > s/of other/on the others/ > > > triggered unless we deactivate the interrupt first. > > I think it would be clearer if you say: "As the Active state for SGI is left > untouched during the reboot, the GIC_SGI_CALL_FUNCTION will still be > active on the non-boot CPUs. This means the interrupt cannot be triggered > again until it get deactivated." > > > > > To fix this issue, let's move the deactivate_irq operation just after > > eoi_irq, then the SGI interrupt will be in deactive state when > > s/deactive/deactivate/ > > > smp_call_function_interrupt. > > I would add: "This is fine because the interrupts are masked while handling > the > SGI.". > > > > > Signed-off-by: Peng Fan <peng.fan@xxxxxxx> > > I think the patch makes sense in itself. This is a saner behavior than turning > off the CPU with active interrupts. I want to double-check a few things before > committing it. But I will definitely commit it by the end of the week. > > No need to resend the patch if there are no changes in the code. I can take > care > for the commit message. Thanks, Peng. > > Cheers, > > -- > Julien Grall _______________________________________________ Xen-devel mailing list Xen-devel@xxxxxxxxxxxxxxxxxxxx https://lists.xenproject.org/mailman/listinfo/xen-devel
|
Lists.xenproject.org is hosted with RackSpace, monitoring our |