On 03/02/16 04:59, David Gibson wrote: >> Going back to your earlier email you suggested that the host timebase is >> always continuously running, even when the guest is paused. But then >> resuming the guest then the timebase must jump in the guest regardless? >> >> If this is the case then this is the big difference between TCG and KVM >> guests: TCG timebase is derived from the virtual clock which solves the >> problem of paused guests during migration. For example with the existing >> migration code, what would happen if you did a migration with the guest >> paused on KVM? The offset would surely be wrong as it was calculated at >> the end of migration. > > So there are two different cases to consider here. Once is when the > guest is paused incidentally, such as during migration, the other is > when the guest is explicitly paused. > > In the first case the timebase absolutely should keep running (or > appear to do so), since it's the primary source of real time for the > guest.
I'm not sure I understand this, since if the guest is paused either deliberately or incidentally during migration then isn't the timebase also frozen? Or is it external to the CPU? > In the second case, it's a bit unclear what the right thing to do is. > Keeping the tb running means accurate realtime, but stopping it is > often better for debugging, which is one of the main reasons to > explicitly pause. > > I believe spapr on KVM HV will keep the TB going, but the TSC on x86 > will be stopped. Is this from a guest-centric view, i.e. if I pause a VM and wait 20 mins then when the guest resumes the timebase will jump forward by 20 mins worth of ticks? ATB, Mark.