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@xxxxxxx> 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
_______________________________________________
kvmarm mailing list
kvmarm@xxxxxxxxxxxxxxxxxxxxx
https://lists.cs.columbia.edu/mailman/listinfo/kvmarm
