diff options
author | Peter Maydell <peter.maydell@linaro.org> | 2024-01-09 14:43:44 +0000 |
---|---|---|
committer | Peter Maydell <peter.maydell@linaro.org> | 2024-01-09 14:43:44 +0000 |
commit | 82a65e3188abebb509510b391726711606aca642 (patch) | |
tree | 789d3ed07b8aa9b649d05e5792cbc23da74ae319 /include/hw/misc/stm32l4x5_exti.h | |
parent | 3d65b958c5463a1c06cac51b6474097ecdbb576e (diff) | |
download | qemu-82a65e3188abebb509510b391726711606aca642.zip qemu-82a65e3188abebb509510b391726711606aca642.tar.gz qemu-82a65e3188abebb509510b391726711606aca642.tar.bz2 |
hw/intc/arm_gicv3_cpuif: handle LPIs in in the list registers
The hypervisor can deliver (virtual) LPIs to a guest by setting up a
list register to have an intid which is an LPI. The GIC has to treat
these a little differently to standard interrupt IDs, because LPIs
have no Active state, and so the guest will only EOI them, it will
not also deactivate them. So icv_eoir_write() must do two things:
* if the LPI ID is not in any list register, we drop the
priority but do not increment the EOI count
* if the LPI ID is in a list register, we immediately deactivate
it, regardless of the split-drop-and-deactivate control
This can be seen in the VirtualWriteEOIR0() and VirtualWriteEOIR1()
pseudocode in the GICv3 architecture specification.
Without this fix, potentially a hypervisor guest might stall because
LPIs get stuck in a bogus Active+Pending state.
Cc: qemu-stable@nongnu.org
Signed-off-by: Peter Maydell <peter.maydell@linaro.org>
Reviewed-by: Richard Henderson <richard.henderson@linaro.org>
Tested-by: Miguel Luis <miguel.luis@oracle.com>
Diffstat (limited to 'include/hw/misc/stm32l4x5_exti.h')
0 files changed, 0 insertions, 0 deletions