[PATCH] arm64: kvm: Expose timer offset directly via KVM_{GET,SET}_ONE_REG

Oliver Upton oliver.upton at linux.dev
Mon Feb 6 11:55:21 PST 2023


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



More information about the linux-arm-kernel mailing list