[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

 


Rackspace

Lists.xenproject.org is hosted with RackSpace, monitoring our
servers 24x7x365 and backed by RackSpace's Fanatical Support®.