Re: Timekeeping on ARM guests/hosts

[Christoffer Dall <christoffer.dall@arm.com>]

On Tue, Nov 06, 2018 at 10:37:21AM -0800, Miriam Zimmerman wrote:
> On Mon, Nov 5, 2018 at 11:45 PM Christoffer Dall
> <christoffer.dall@arm.com> wrote:
> >
> > On Fri, Nov 02, 2018 at 02:23:45PM -0700, Miriam Zimmerman wrote:
> > > In researching KVM_REG_ARM_TIMER_CNT, I discovered your commit 4b7a6bf
> > > ("target-arm: kvm: Differentiate registers based on write-back
> > > levels"), which seems to limit when the KVM_REG_ARM_TIMER_CNT is used
> > > to save time. Under what circumstances should this be saved in order
> > > to provide a consistent view of wall clock time (as given by `date` in
> > > the VM)?
> >
> > In general, and not specific to QEMU, I think that the virtual
> > counter value should stop counting when the entirety of the VM is not
> > running, for example when the host machine is suspended, or when the
> > entire VM is stopped/suspended, either as part of a suspend/resume
> > operation, debug operation, or as part of migration of some sort.
> >
> > Supporting these timekeeping semantics is not something anyone has tried
> > up until now with KVM/Arm, as far as I'm aware, and as such is 'new'
> > work.
> 
> Hrm, that's perplexing to me. I thought you said that in your tests,
> going into S3 suspend on a host did *not* result in time drift on the
> guest? That would suggest to me that there is code that correctly
> handles it.

I don't believe I've said that.  I haven't actually tried that myself,
but I know anecdotally from others that time jumps on the guest when you
suspend the host, leading to warnings in a guest.

There must be some misunderstanding here.

> 
> Upthread, you said:
> > The key is whether the userspace program that controls the KVM VM
> > (kvmtool, QEMU, crosvm) uses the KVM_REG_ARM_TIMER_CNT ioctl to save the
> > VM view of virtual time, and to retore that at a later time.
> Is this a description of current behavior of any of these userspace
> programs, or a description of how they might opt to address the
> time-drift-on-suspend issue?
> 

That is how they might choose, using the current KVM/Arm api, to adjust
for suspending the VM (different from suspending the host).

> >
> >
> >
> > > The commit refers to 'machine initialization or on vmload
> > > operations', but I'm having difficulty figuring out what a vmload
> > > operation is on ARM. Does this include resume-from-sleep/suspend?
> >
> > I believe vmload is qemu-speak for loading in VM state from a stored
> > migration stream, but you'd have to ask the QEMU folks or study the code
> > more carefully to figure out when a vmload really happens.
> I see, okay. I misread the patch's commit log and thought you had written it.
> 

I did, but I'm (at best) a drive-by QEMU hacker, and I am not presently
in a position to contribute to QEMU.  There is also always the
possibility that my patch was wrong.  I think in this particular case,
though, I was trying to solve a differnet problem with that patch and
didn't realy consider the problem of virtual time back then.

Hope this helps,

    Christoffer