On 2020/3/30 20:38, Auger Eric wrote:
Hi Zenghui,
[...]
+
+ ptr = gicv3_data.redist_base[pe0] + GICR_PENDBASER;
+ pendbaser = readq(ptr);
+ writeq(pendbaser & ~GICR_PENDBASER_PTZ, ptr);
+
+ ptr = gicv3_data.redist_base[pe1] + GICR_PENDBASER;
+ pendbaser = readq(ptr);
+ writeq(pendbaser & ~GICR_PENDBASER_PTZ, ptr);
+
+ gicv3_lpi_rdist_enable(pe0);
+ gicv3_lpi_rdist_enable(pe1);
I don't know how the migration gets implemented in kvm-unit-tests.
But is there any guarantee that the LPIs will only be triggered on the
destination side? As once the EnableLPIs bit becomes 1, VGIC will start
reading the pending bit in guest memory and potentially injecting LPIs
into the target vcpu (in the source side).
I expect some LPIs to hit on source and some others to hit on the
destination. To me, this does not really matter as long as the handlers
gets called and accumulate the stats. Given the number of LPIs, we will
at least test the migration of some of the pending bits and especially
adjacent ones. It does work as it allows to test your fix:
ca185b260951 KVM: arm/arm64: vgic: Don't rely on the wrong pending table
Fair enough. Thanks for your explanation!
Zenghui
_______________________________________________
kvmarm mailing list
kvmarm@xxxxxxxxxxxxxxxxxxxxx
https://lists.cs.columbia.edu/mailman/listinfo/kvmarm
