Re: [PATCH v1 0/5] target/arm/kvm: Provide an option to adjust virtual time

[Andrew Jones <drjones@redhat.com>]

On Tue, Dec 10, 2019 at 11:48:38AM +0000, Peter Maydell wrote:
> On Tue, 10 Dec 2019 at 11:05, Andrew Jones <drjones@redhat.com> wrote:
> > x86 developers could easily add this feature if/when they need a way to
> > disable their current default behavior. But, since the kvm-adjvtime
> > default would likely be 'on' for them, then they'd probably prefer the
> > feature be named kvm-no-adjvtime, and default 'off'. Should we try to
> > anticipate what x86 might want when naming this feature? IMO, we should
> > not, especially because I'm doubtful that x86 will ever want to implement
> > it. Also, what about the other KVM capable architectures? Which defaults
> > do they have now? And do we expect them to want to expose a switch to the
> > user to change it?
> 
> My perspective here is mostly that I don't really understand
> the ins and outs of KVM and in particular handling of
> time in VMs, beyond knowing that it's complicated. So I
> prefer approaches that push back to "do everything the same
> for all architectures rather than having something that's
> arm-specific", because then things get more review from
> the larger mass of non-arm KVM/QEMU developers. Arm-specific
> switches/interfaces/designs just make arm more of a
> special-snowflake. I don't really have a basis to be able
> to review the patchset beyond those general biases.
>

So the ins and outs of this particular timekeeping issue (to the best of
my knowledge) is that x86 has implemented this behavior since
00f4d64ee76e ("kvmclock: clock should count only if vm is running"), which
was committed over six years ago. Possibly x86 VM time would behave more
like arm VM time if kvmclock was disabled, but that's not a recommended
configuration.

PPC got an equivalent patch to the x86 one in 2017, 42043e4f1241 ("spapr:
clock should count only if vm is running"), but when stopping time during
pause on spapr they actually *keep* 'date' and 'hwclock' in synch. I guess
whatever clocksource 'hwclock' uses on spapr was already stopping when
paused? For x86 those values diverge, and for arm without this series they
stay the same but experience jumps, and with this series they diverge like
x86. I don't see any way to disable the behaviour 42043e4f1241 introduces.

s390x got what appears to be its equivalent patch last year 9bc9d3d1ae3b
("s390x/tod: Properly stop the KVM TOD while the guest is not running").
The commit message doesn't state how hwclock and date values change /
don't change, and I don't see any way to disable the behavior.

MIPS has had this implemented since KVM support was introduced. No way
to disable it that I know of.

So why is this arm-specific? arm is just trying to catch up, but also
offer a switch allowing the current behavior to be selected. If other
architectures see value in the switch then they're free to adopt it too.
After having done this git mining, it looks more and more like we should
at least consider naming this feature 'kvm-no-adjvtime' and probably
also change arm's default.

Thanks,
drew