From: Andrew Jones <drjones@redhat.com>
To: Peter Maydell <peter.maydell@linaro.org>
Cc: Marc Zyngier <maz@kernel.org>, qemu-arm <qemu-arm@nongnu.org>,
Richard Henderson <richard.henderson@linaro.org>,
QEMU Developers <qemu-devel@nongnu.org>,
bijan.mottahedeh@oracle.com
Subject: Re: [PATCH v1 0/5] target/arm/kvm: Provide an option to adjust virtual time
Date: Fri, 6 Dec 2019 16:53:27 +0100 [thread overview]
Message-ID: <20191206155327.7adiyjjkjh56mg2t@kamzik.brq.redhat.com> (raw)
In-Reply-To: <CAFEAcA8j8M_J8Ocdpms8a2XufigVQ6oB4JBy2BcYAkXfJX5y5A@mail.gmail.com>
On Fri, Dec 06, 2019 at 03:22:58PM +0000, Peter Maydell wrote:
> On Wed, 16 Oct 2019 at 15:34, Andrew Jones <drjones@redhat.com> wrote:
> >
> > v2:
> > - move from RFC status to v1
> > - put kvm_arm_vm_state_change() in kvm.c to share among kvm32.c and kvm64.c
> > - add r-b's from Richard
> >
> >
> > This series is inspired by a series[1] posted by Bijan Mottahedeh about
> > a year ago. The problem described in the cover letter of [1] is easily
> > reproducible and some users would like to have the option to avoid it.
> > However the solution, which is to adjust the virtual counter offset each
> > time the VM transitions to the running state, introduces a different
> > problem, which is that the virtual and physical counters diverge. As
> > described in the cover letter of [1] this divergence is easily observed
> > when comparing the output of `date` and `hwclock` after suspending the
> > guest, waiting a while, and then resuming it. Because this different
> > problem may actually be worse for some users, unlike [1], the series
> > posted here makes the virtual counter offset adjustment optional and not
> > even enabled by default. Besides the adjustment being optional, this
> > series approaches the needed changes differently to apply them in more
> > appropriate locations. Finally, unlike [1], this series doesn't attempt
> > to measure "pause time" itself. Simply using QEMU_CLOCK_VIRTUAL, which
> > only ticks when the VM is not stopped, is sufficient.
>
> So I guess my overall question is "what is the x86 solution to
> this problem, and why is this all arm-specific?" It would also
x86 adjusts the counter offset by default, and I don't think there's any
way to turn that behavior off. I think it's too late to follow that
default for arm, but this series provides a way to opt into the same
behavior.
> be helpful to know how it fits into all the other proposals regarding
> time in VMs.
I've been lightly following the other stuff, but haven't yet seen any
overlap.
BTW, this series needs to be rebased and reposted. I've been waiting for
4.2 though.
Thanks,
drew
next prev parent reply other threads:[~2019-12-06 17:06 UTC|newest]
Thread overview: 29+ messages / expand[flat|nested] mbox.gz Atom feed top
2019-10-16 14:34 [PATCH v1 0/5] target/arm/kvm: Provide an option to adjust virtual time Andrew Jones
2019-10-16 14:34 ` [PATCH v1 1/5] target/arm/kvm64: kvm64 cpus have timer registers Andrew Jones
2019-10-16 14:34 ` [PATCH v1 2/5] timer: arm: Introduce functions to get the host cntfrq Andrew Jones
2019-12-10 15:47 ` Peter Maydell
2019-12-10 16:41 ` Andrew Jones
2019-10-16 14:34 ` [PATCH v1 3/5] target/arm/kvm: Implement cpu feature kvm-adjvtime Andrew Jones
2019-12-10 15:54 ` Peter Maydell
2019-12-10 16:10 ` Andrew Jones
2019-10-16 14:34 ` [PATCH v1 4/5] tests/arm-cpu-features: Check feature default values Andrew Jones
2019-10-16 14:34 ` [PATCH v1 5/5] target/arm/cpu: Add the kvm-adjvtime CPU property Andrew Jones
2019-10-17 21:17 ` [PATCH v1 0/5] target/arm/kvm: Provide an option to adjust virtual time Masayoshi Mizuma
2019-10-18 12:02 ` Andrew Jones
2019-10-28 18:39 ` Masayoshi Mizuma
2019-12-06 15:22 ` Peter Maydell
2019-12-06 15:53 ` Andrew Jones [this message]
2019-12-10 9:51 ` Andrea Bolognani
2019-12-10 10:29 ` Peter Maydell
2019-12-10 11:05 ` Andrew Jones
2019-12-10 11:48 ` Peter Maydell
2019-12-10 13:32 ` Andrew Jones
2019-12-10 14:21 ` Andrea Bolognani
2019-12-10 14:33 ` Andrew Jones
2019-12-10 15:47 ` Andrea Bolognani
2019-12-10 16:08 ` Andrew Jones
2019-12-10 17:16 ` Andrea Bolognani
2019-12-10 15:45 ` Peter Maydell
2019-12-11 8:02 ` Guoheyi
2019-12-11 9:00 ` Andrew Jones
2019-12-11 13:50 ` Guoheyi
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=20191206155327.7adiyjjkjh56mg2t@kamzik.brq.redhat.com \
--to=drjones@redhat.com \
--cc=bijan.mottahedeh@oracle.com \
--cc=maz@kernel.org \
--cc=peter.maydell@linaro.org \
--cc=qemu-arm@nongnu.org \
--cc=qemu-devel@nongnu.org \
--cc=richard.henderson@linaro.org \
/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;
as well as URLs for NNTP newsgroup(s).