From: Oliver Upton <oliver.upton@linux.dev>
To: David Woodhouse <dwmw2@infradead.org>
Cc: Marc Zyngier <maz@kernel.org>, Simon Veith <sveith@amazon.de>,
Catalin Marinas <catalin.marinas@arm.com>,
Will Deacon <will@kernel.org>, James Morse <james.morse@arm.com>,
Suzuki K Poulose <suzuki.poulose@arm.com>,
Zenghui Yu <yuzenghui@huawei.com>,
linux-arm-kernel@lists.infradead.org
Subject: Re: [PATCH] arm64: kvm: Expose timer offset directly via KVM_{GET,SET}_ONE_REG
Date: Mon, 6 Feb 2023 19:55:21 +0000 [thread overview]
Message-ID: <Y+FbKVw3LalcFISK@linux.dev> (raw)
In-Reply-To: <903da8727680b394a645b81ce9dcdf25354138b0.camel@infradead.org>
On Thu, Feb 02, 2023 at 03:18:55PM +0000, David Woodhouse wrote:
> On Thu, 2023-02-02 at 13:50 +0000, Marc Zyngier wrote:
> > On Thu, 02 Feb 2023 12:13:14 +0000, Simon Veith <sveith@amazon.de> wrote:
[...]
> > > The issue is further complicated when vCPU setup is performed by
> > > independent threads which may experience different delays, leading to
> > > jitter between the clocks of different vCPUs.
> >
> > How? I really hope that you will have restored *all* the vcpus before
> > restarting any. If you don't, your userspace is buggy.
>
> But the timer counts from the epoch of when the KVM itself was
> initialised, doesn't it? I haven't looked hard at the arm side but on
> x86 if the various vCPU threads all use the "TSC is <x> now" API, they
> only end up in sync because there's a hack for "if it's within one
> second of the previously-set vCPU's TSC, make it precisely match". And
> then they're only in sync with each *other* rather than what they were
> before the live update.
We don't have any analog to the x86 TSC synchronization game on arm64.
The UAPI we have relies strictly on the architecture, which effectively
states that all PEs in a system have a consistent view of the generic
counter.
As it relates to KVM, whenever the virtual counter value is written from
userspace, we apply the calculated offset to all vCPUs in the VM. And
yes, this results in some wasted cycles doing this broadcast from every
single vCPU. But oh well, it hasn't been consequential (yet).
--
Thanks,
Oliver
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
prev parent reply other threads:[~2023-02-06 19:56 UTC|newest]
Thread overview: 5+ messages / expand[flat|nested] mbox.gz Atom feed top
2023-02-02 12:13 [PATCH] arm64: kvm: Expose timer offset directly via KVM_{GET,SET}_ONE_REG Simon Veith
2023-02-02 12:54 ` David Woodhouse
2023-02-02 13:50 ` Marc Zyngier
2023-02-02 15:18 ` David Woodhouse
2023-02-06 19:55 ` Oliver Upton [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=Y+FbKVw3LalcFISK@linux.dev \
--to=oliver.upton@linux.dev \
--cc=catalin.marinas@arm.com \
--cc=dwmw2@infradead.org \
--cc=james.morse@arm.com \
--cc=linux-arm-kernel@lists.infradead.org \
--cc=maz@kernel.org \
--cc=suzuki.poulose@arm.com \
--cc=sveith@amazon.de \
--cc=will@kernel.org \
--cc=yuzenghui@huawei.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;
as well as URLs for NNTP newsgroup(s).