aboutsummaryrefslogtreecommitdiff
path: root/include/hw/misc/stm32l4x5_exti.h
diff options
context:
space:
mode:
authorPeter Maydell <peter.maydell@linaro.org>2024-01-09 14:43:44 +0000
committerPeter Maydell <peter.maydell@linaro.org>2024-01-09 14:43:44 +0000
commit82a65e3188abebb509510b391726711606aca642 (patch)
tree789d3ed07b8aa9b649d05e5792cbc23da74ae319 /include/hw/misc/stm32l4x5_exti.h
parent3d65b958c5463a1c06cac51b6474097ecdbb576e (diff)
downloadqemu-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