Re: [PATCH] arm/acpi: Fix the deadlock in function vgic_lock_rank()

[Julien Grall <julien.grall@arm.com>]

Hello Shanker,

On 27/05/16 01:39, Shanker Donthineni wrote:
> Commit 9d77b3c01d1261c (Configure SPI interrupt type and route to
> Dom0 dynamically) causing dead loop inside the spinlock function.
> Note that spinlocks in XEN are not recursive. Re-acquiring a spinlock
> that has already held by calling CPU leads to deadlock. This happens
> whenever dom0 does writes to GICD regs ISENABLER/ICENABLER.

Thank you for spotting it, I have not noticed it while I was  reviewing, 
only tested on a model without any SPIs.

> The following call trace explains the problem.
>
> DOM0 writes GICD_ISENABLER/GICD_ICENABLER
>    vgic_v3_distr_common_mmio_write()
>      vgic_lock_rank()  -->  acquiring first time
>        vgic_enable_irqs()
>          route_irq_to_guest()
>            gic_route_irq_to_guest()
>              vgic_get_target_vcpu()
>                vgic_lock_rank()  -->  attemping acquired lock
>
> The simple fix release spinlock before calling vgic_enable_irqs()
> and vgic_disable_irqs().

You should explain why you think it is valid to release the lock earlier.

In this case, I think the fix is not correct because the lock is 
protecting both the register value and the internal state in Xen 
(modified by vgic_enable_irqs). By releasing the lock earlier, they may 
become inconsistent if another vCPU is disabling the IRQs at the same time.

I cannot find an easy fix which does not involve release the lock. When 
I was reviewing this patch, I suggested to split the IRQ configuration 
from the routing.

The routing (call to route_irq_to_guest) will be done before DOM0 is 
booting. The IRQ configuration will be done in the ICFGR register.

This will also help for PCI-passthrough as the guest will have to 
configure the SPIs (we can't expect DOM0 doing it for it). But the 
routing will be done ahead.

This would resolve the locking issue, however it is a big task. Feel 
free to suggest a simpler one.

Regards,

-- 
Julien Grall

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel