|
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] Re: [Xen-devel] [PATCH 1/2] xen/arm: save/restore irq flags in gic_disable_cpu
On Mon, 2013-04-15 at 17:50 +0100, Julien Grall wrote:
> On SMP board, gic_disable_cpu is called by an SGI call function when Xen is
> halting. In this specific case, the interrupts are disabled.
In the only other existing caller (__cpu_disable) interrupts are also
disabled and I'd argue that it would be invalid to call this function
with interrupts enabled due to its nature. I think it should start with
an assert to that effect.
In principal I think that would make spin_lock() OK to use rather irq or
irqsave? But the lockdep analyser (and/or reality) may not agree?
Or is the issue here not so much that IRQs are disabled but that this
new caller is in interrupt context?
> Signed-off-by: Julien Grall <julien.grall@xxxxxxxxxx>
> ---
> xen/arch/arm/gic.c | 6 ++++--
> 1 file changed, 4 insertions(+), 2 deletions(-)
>
> diff --git a/xen/arch/arm/gic.c b/xen/arch/arm/gic.c
> index aa179a9..c9f64f1 100644
> --- a/xen/arch/arm/gic.c
> +++ b/xen/arch/arm/gic.c
> @@ -419,10 +419,12 @@ void __cpuinit gic_init_secondary_cpu(void)
> /* Shut down the per-CPU GIC interface */
> void gic_disable_cpu(void)
> {
> - spin_lock_irq(&gic.lock);
> + unsigned long flags;
> +
> + spin_lock_irqsave(&gic.lock, flags);
> gic_cpu_disable();
So we apparently have gic_cpu_disable and gic_disable_cpu, nice!
Since the only caller of gic_cpu_disable is gic_disable_cpu I think we
should just inline it. Or call it gic_(cpu_)disable_gicc
> gic_hyp_disable();
Likewise this is the only caller of this function, either inline or
gic_(cpu)disable_gich?
> - spin_unlock_irq(&gic.lock);
> + spin_unlock_irqrestore(&gic.lock, flags);
> }
>
> void gic_route_ppis(void)
_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxx
http://lists.xen.org/xen-devel
|
![]() |
Lists.xenproject.org is hosted with RackSpace, monitoring our |