From: Christoffer Dall <christoffer.dall@arm.com>
To: Bijan Mottahedeh <bijan.mottahedeh@oracle.com>
Cc: marc.zyngier@arm.com, steven.price@arm.com, lersek@redhat.com,
Miriam Zimmerman <mutexlox@google.com>,
kvmarm@lists.cs.columbia.edu
Subject: Re: Timekeeping on ARM guests/hosts
Date: Tue, 6 Nov 2018 08:49:39 +0100 [thread overview]
Message-ID: <20181106074939.GD12057@e113682-lin.lund.arm.com> (raw)
In-Reply-To: <4966eb6c-cc5f-a97b-1738-ba8a67b5948d@oracle.com>
On Fri, Nov 02, 2018 at 05:19:20PM -0700, Bijan Mottahedeh wrote:
> 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.
Without having looked at the patch, that sounds to me like it would work
on all Arm implementations (ignoring hardware bugs around the
counter/time, if any should exist).
>
> 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
I think that patch would be part of the work to support the semantics
in the PV Timer spec. This is part of what userspace would have to do
to communicate 'Live Physical Time (LPT)' to the guest, by telling KVM
to preserve a previous value of LPT, which it in turns does by adjusting
the offset in CNTVOFF_EL2 (which effectively accounts for 'paused' time
- in PV Timer spec terms).
>
> Would it make sense to send the patch as an RFC for evaluation at this point
> or do you suggest any other considerations?
>
Definitely that would make sense.
We need additional work to account for suspended time, either via hooks
in userspace or via hooks directly in the arch timer in KVM, and all of
the PV features come on top.
Thanks,
Christoffer
_______________________________________________
kvmarm mailing list
kvmarm@lists.cs.columbia.edu
https://lists.cs.columbia.edu/mailman/listinfo/kvmarm
prev parent reply other threads:[~2018-11-06 7:49 UTC|newest]
Thread overview: 21+ messages / expand[flat|nested] mbox.gz Atom feed top
2018-10-09 23:39 Timekeeping on ARM guests/hosts Miriam Zimmerman
2018-10-10 10:01 ` Marc Zyngier
2018-10-10 18:38 ` Miriam Zimmerman
2018-10-11 7:54 ` Marc Zyngier
2018-10-11 15:21 ` Laszlo Ersek
2018-10-11 18:40 ` Miriam Zimmerman
2018-10-31 16:41 ` Steven Price
2018-10-31 18:49 ` Miriam Zimmerman
2018-11-02 14:34 ` Christoffer Dall
2018-11-02 18:28 ` Miriam Zimmerman
2018-11-02 21:23 ` Miriam Zimmerman
2018-11-06 7:45 ` Christoffer Dall
2018-11-06 13:39 ` Alex Bennée
2018-11-06 18:37 ` Miriam Zimmerman
2018-11-07 9:42 ` Christoffer Dall
2018-11-07 18:22 ` Miriam Zimmerman
2018-11-08 10:26 ` Christoffer Dall
2018-11-08 16:34 ` Steven Price
2018-11-08 20:06 ` Christoffer Dall
2018-11-03 0:19 ` Bijan Mottahedeh
2018-11-06 7:49 ` Christoffer Dall [this message]
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20181106074939.GD12057@e113682-lin.lund.arm.com \
--to=christoffer.dall@arm.com \
--cc=bijan.mottahedeh@oracle.com \
--cc=kvmarm@lists.cs.columbia.edu \
--cc=lersek@redhat.com \
--cc=marc.zyngier@arm.com \
--cc=mutexlox@google.com \
--cc=steven.price@arm.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox