On 2020/11/25 23:51, Alexandru Elisei wrote:
The reason for the failure is that the test "dev2/eventid=20 now triggers an LPI" triggers 2 LPIs, not one. This behavior was present before this patch, but it was ignored because check_lpi_stats() wasn't looking at the acked array. I'm not familiar with the ITS so I'm not sure if this is expected, if the test is incorrect or if there is something wrong with KVM emulation.
I think this is expected, or not. Before INVALL, the LPI-8195 was already pending but disabled. On receiving INVALL, VGIC will reload configuration for all LPIs targeting collection-3 and deliver the now enabled LPI-8195. We'll therefore see and handle it before sending the following INT (which will set the LPI-8195 pending again).
Did some more testing on an Ampere eMAG (fast out-of-order cores) using qemu and kvmtool and Linux v5.8, here's what I found: - Using qemu and gic.flat built from*master*: error encountered 864 times out of 1088 runs. - Using qemu: error encountered 852 times out of 1027 runs. - Using kvmtool: error encountered 8164 times out of 10602 runs.
If vcpu-3 hadn't seen and handled LPI-8195 as quickly as possible (e.g., vcpu-3 hadn't been scheduled), the following INT will set the already pending LPI-8195 pending again and we'll receive it *once* on vcpu-3. And we won't see the mentioned failure. I think we can just drop the (meaningless and confusing?) INT. Thanks, Zenghui
