Hi Alexandru, Zenghui On 11/26/20 10:30 AM, Zenghui Yu wrote: > 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. Yes I agree with Zenghui, we can remove the INT and just check the pending LPI set while disabled eventually hits Thanks Eric > > > Thanks, > Zenghui > _______________________________________________ kvmarm mailing list kvmarm@xxxxxxxxxxxxxxxxxxxxx https://lists.cs.columbia.edu/mailman/listinfo/kvmarm
