irqchip/gic-v4: Fix occasional VLPI drop
authorHeyi Guo <guoheyi@huawei.com>
Thu, 24 Jan 2019 13:37:08 +0000 (21:37 +0800)
committerGreg Kroah-Hartman <gregkh@linuxfoundation.org>
Wed, 13 Mar 2019 21:02:34 +0000 (14:02 -0700)
commitdc81cfafb4b96d83c740387ef880e720214c92ab
tree088a2017732ec8c694c8dda7a61b97ab6f671278
parent377ffe354dc0c4fc8d84662e2756d0eae191e87f
irqchip/gic-v4: Fix occasional VLPI drop

[ Upstream commit 6479450f72c1391c03f08affe0d0110f41ae7ca0 ]

1. In current implementation, every VLPI will temporarily be mapped to
the first CPU in system (normally CPU0) and then moved to the real
scheduled CPU later.

2. So there is a time window and a VLPI may be sent to CPU0 instead of
the real scheduled vCPU, in a multi-CPU virtual machine.

3. However, CPU0 may have not been scheduled as a virtual CPU after
system boots up, so the value of its GICR_VPROPBASER is unknown at
that moment.

4. If the INTID of VLPI is larger than 2^(GICR_VPROPBASER.IDbits+1),
while IDbits is also in unknown state, GIC will behave as if the VLPI
is out of range and simply drop it, which results in interrupt missing
in Guest.

As no code will clear GICR_VPROPBASER at runtime, we can safely
initialize the IDbits field at boot time for each CPU to get rid of
this issue.

We also clear Valid bit of GICR_VPENDBASER in case any ancient
programming gets left in and causes memory corrupting. A new function
its_clear_vpend_valid() is added to reuse the code in
its_vpe_deschedule().

Fixes: e643d8034036 ("irqchip/gic-v3-its: Add VPE scheduling")
Signed-off-by: Heyi Guo <guoheyi@huawei.com>
Signed-off-by: Heyi Guo <heyi.guo@linaro.org>
Signed-off-by: Marc Zyngier <marc.zyngier@arm.com>
Signed-off-by: Sasha Levin <sashal@kernel.org>
drivers/irqchip/irq-gic-v3-its.c