Re: Timekeeping on ARM guests/hosts

[Bijan Mottahedeh <bijan.mottahedeh@oracle.com>]

On 11/2/2018 7:34 AM, Christoffer Dall wrote:
> 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.
>
> KVM adjusts the CNTVOFF_EL2 for the VM on which the ioctl is executed to
> represent the value written by userspace to the VM when the VM reads
> CNTVCT_EL0.
>
>>> The Arm ARM doesn't say a great deal about power saving modes so I
>>> wouldn't be surprised if there's differing behaviour as to whether the
>>> system clock is stopped during suspend modes. Indeed I wonder if the
>>> clock can even go backwards during a suspend-to-disk/resume cycle? I
>>> don't have hardware handy to test this.
>> The specific hardware I have in front of me is a Samsung Chromebook
>> Plus (board codename "kevin"), which I believe has an RK3399
>> processor. (More info at
>> https://www.chromium.org/chromium-os/developer-information-for-chrome-os-devices)
>>
> For the purpose of timekeeping in KVM, we need an architecturally
> meaningful solution, not something specific to any device.

I've been working on a QEMU patch to address a problem observed when an 
active guest is paused and resumed after a certain delay with virsh or 
the QEMU monitor.

A simple test to reproduce the problem executes one or more instances of 
the following command in the guest:

dd if=/dev/zero of=/dev/null &

and then pauses and resumes the guest after a certain delay:

virsh suspend <guest>        # pauses the guest
sleep 120
virsh resume <guest>

After the guest is resumed, there are soft lockup warning messages 
displayed on the console.

A comparison with x86 shows that hwclock and date values diverge after 
the above pause and resume sequence for x86 but remain the same for Arm.

The patch accumulates the total guest pause time in QEMU and adjusts the 
virtual offset counter accordingly with the KVM_REG_ARM_TIMER_CNT ioctl 
before the guest is resumed.  With the patch the time behavior is the 
same as x86 and the soft lockup messages go away.

I've tested the patch on an Ampere eMag server but I'm not sure how 
complete, generic, and backward compatible of a solution the patch is in 
terms of other Arm platforms.

Also, I'm not sure if and when this patch would be superseded by the 
proposal from your KVM Forum 2018 presentation:

Paravirtualized Time for Arm-based Systems
https://developer.arm.com/docs/den0057/a

Would it make sense to send the patch as an RFC for evaluation at this 
point or do you suggest any other considerations?

Thanks.

--bijan
_______________________________________________
kvmarm mailing list
kvmarm@lists.cs.columbia.edu
https://lists.cs.columbia.edu/mailman/listinfo/kvmarm