Re: Timekeeping on ARM guests/hosts

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



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.

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?

>
>
>
> > 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.

Thanks,
Miriam
_______________________________________________
kvmarm mailing list
kvmarm@xxxxxxxxxxxxxxxxxxxxx
https://lists.cs.columbia.edu/mailman/listinfo/kvmarm



[Index of Archives]     [Linux KVM]     [Spice Development]     [Libvirt]     [Libvirt Users]     [Linux USB Devel]     [Linux Audio Users]     [Yosemite News]     [Linux Kernel]     [Linux SCSI]

  Powered by Linux