On Sun, 19 Jan 2020 at 13:32, Zenghui Yu <yuzenghui@xxxxxxxxxx> wrote: > > If LPIs are disabled, KVM will just ignore the GICR_PENDBASER.PTZ bit when > restoring GICR_CTLR. Setting PTZ here makes littlt sense in "reduce GIC > initialization time". > > And what's worse, PTZ is generally programmed by guest to indicate to the > Redistributor whether the LPI Pending table is zero when enabling LPIs. > If migration is triggered when the PTZ has just been cleared by guest (and > before enabling LPIs), we will see PTZ==1 on the destination side, which > is not as expected. Let's just drop this hackish userspace behavior. > > Also take this chance to refine the comment a bit. I pulled up the original code-review discussion where this code was added: https://lists.gnu.org/archive/html/qemu-devel/2015-10/msg05889.html It looks like the original reason for adding it was that the GICR_PENDBASER.PTZ bit is write-only, and so there's no way for the migration code in QEMU to accurately restore it on the destination end of a migration. So Pavel picked a heuristic for guessing what the right value of the PTZ bit was. It sounds like the penalty if userspace sets the bit to 0 always on a migration is not significant, so I guess that just setting this bit to 0 always is an OK thing to do (as you say, there's a window in the existing implementation where we do the wrong thing sometimes if migration happens at the wrong time, because the current code's heuristic can sometimes fail in the wrong direction). Applied to target-arm.next. thanks -- PMM _______________________________________________ kvmarm mailing list kvmarm@xxxxxxxxxxxxxxxxxxxxx https://lists.cs.columbia.edu/mailman/listinfo/kvmarm
