diff options
author | Marc Zyngier <maz@kernel.org> | 2022-02-03 12:24:45 +0300 |
---|---|---|
committer | Greg Kroah-Hartman <gregkh@linuxfoundation.org> | 2022-03-08 21:12:30 +0300 |
commit | 8694330db9b0ccdb51ff9608f3d48448c420fc7f (patch) | |
tree | 7966c608fb0378ce097f6aeb72ae100b31fd8efd /drivers/block | |
parent | 850a77c999b81dd2724efd2684068d6f90db8c16 (diff) | |
download | linux-8694330db9b0ccdb51ff9608f3d48448c420fc7f.tar.xz |
KVM: arm64: vgic: Read HW interrupt pending state from the HW
[ Upstream commit 5bfa685e62e9ba93c303a9a8db646c7228b9b570 ]
It appears that a read access to GIC[DR]_I[CS]PENDRn doesn't always
result in the pending interrupts being accurately reported if they are
mapped to a HW interrupt. This is particularily visible when acking
the timer interrupt and reading the GICR_ISPENDR1 register immediately
after, for example (the interrupt appears as not-pending while it really
is...).
This is because a HW interrupt has its 'active and pending state' kept
in the *physical* distributor, and not in the virtual one, as mandated
by the spec (this is what allows the direct deactivation). The virtual
distributor only caries the pending and active *states* (note the
plural, as these are two independent and non-overlapping states).
Fix it by reading the HW state back, either from the timer itself or
from the distributor if necessary.
Reported-by: Ricardo Koller <ricarkol@google.com>
Tested-by: Ricardo Koller <ricarkol@google.com>
Reviewed-by: Ricardo Koller <ricarkol@google.com>
Signed-off-by: Marc Zyngier <maz@kernel.org>
Link: https://lore.kernel.org/r/20220208123726.3604198-1-maz@kernel.org
Signed-off-by: Sasha Levin <sashal@kernel.org>
Diffstat (limited to 'drivers/block')
0 files changed, 0 insertions, 0 deletions