summaryrefslogtreecommitdiff
path: root/drivers/block
diff options
context:
space:
mode:
authorMarc Zyngier <maz@kernel.org>2022-02-03 12:24:45 +0300
committerGreg Kroah-Hartman <gregkh@linuxfoundation.org>2022-03-08 21:12:30 +0300
commit8694330db9b0ccdb51ff9608f3d48448c420fc7f (patch)
tree7966c608fb0378ce097f6aeb72ae100b31fd8efd /drivers/block
parent850a77c999b81dd2724efd2684068d6f90db8c16 (diff)
downloadlinux-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