The its-trigger test checks that LPI 8195 is not delivered to the CPU while it is disabled at the ITS level. After that it is re-enabled and the test checks that the interrupt is properly asserted. After it's re-enabled and before the stats are examined, the test triggers the interrupt again, which can lead to the same interrupt being delivered twice: once after the configuration invalidation and before the INT command, and once after the INT command.
Add an explicit check that the interrupt has fired after the invalidation. Leave the check after the INT command to make sure the INT command still works for the now re-enabled LPI. CC: Auger Eric <[email protected]> Suggested-by: Zenghui Yu <[email protected]> Reviewed-by: Andre Przywara <[email protected]> Reviewed-by: Eric Auger <[email protected]> Signed-off-by: Alexandru Elisei <[email protected]> --- arm/gic.c | 3 +++ 1 file changed, 3 insertions(+) diff --git a/arm/gic.c b/arm/gic.c index af2c112336e7..8bc2a35908f2 100644 --- a/arm/gic.c +++ b/arm/gic.c @@ -802,6 +802,9 @@ static void test_its_trigger(void) /* Now call the invall and check the LPI hits */ its_send_invall(col3); + lpi_stats_expect(3, 8195); + check_lpi_stats("dev2/eventid=20 pending LPI is received"); + lpi_stats_expect(3, 8195); its_send_int(dev2, 20); check_lpi_stats("dev2/eventid=20 now triggers an LPI"); -- 2.30.1 _______________________________________________ kvmarm mailing list [email protected] https://lists.cs.columbia.edu/mailman/listinfo/kvmarm
