On 12/18/23 22:32, Peter Maydell wrote:
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-sta...@nongnu.org Signed-off-by: Peter Maydell <peter.mayd...@linaro.org> --- Weirdly, I only saw this being a problem when the hypervisor guest was an EL2-enabled one under my FEAT_NV/FEAT_NV2 implementation. But there's nothing FEAT_NV specific about the bug. --- hw/intc/arm_gicv3_cpuif.c | 17 +++++++++++++---- 1 file changed, 13 insertions(+), 4 deletions(-)
Reviewed-by: Richard Henderson <richard.hender...@linaro.org> r~
