[RFC PATCH] KVM: arm/arm64: Don't let userspace update CNTVOFF once guest is running

[Christoffer Dall]

On Thu, Jul 09, 2015 at 02:24:06PM +0200, Christoffer Dall wrote:
> On Thu, Jul 09, 2015 at 01:07:24PM +0100, Peter Maydell wrote:
> > On 9 July 2015 at 13:05, Christoffer Dall <christoffer.dall at linaro.org> wrote:
> > > As I understand it, the problem is that if we ever run a VCPU after
> > > reading the value, and write back the value afterwards, you potentially
> > > make time go backwards and get inconsistent views of time from different
> > > VCPUs because they may have read the time before/after updating the
> > > CNTVOFF.
> > 
> > Right, but I think if QEMU does that it's a bug (and more to
> > the point I don't entirely understand why we would do that
> > yet, even given that we don't have a distinction between
> > "registers to sync always" and "registers to sync only on
> > reset"...)
> > 
> I think we have evidence that it does that, but we don't know why/how.
> 
So I ran this through GDB, and this happens when the guest probes the
virtio devices, specifically the backtrace tells me that

virtio_current_cpu_endian () at /root/src/qemu/hw/virtio/virtio.c:594
=> cc->virtio_is_big_endian
  -> arm_cpu_is_big_endian
    -> cpu_synchronize_state
      -> kvm_cpu_synchronize_state

which causes cpu->kvm_vcpu_dirty = true, which causes the run-loop to
write the CNTVOFF on a per-vcpu basis without stopping anything, as far
as I can tell.

So yeah, I guess the only required fix here is to fix QEMU in some way
as to not fiddle with the timer registers in this way, and then I
honestly don't know if we should try to fix legacy userspace in the
kernel, but based on the feedback from Jan, I suppose not.

Thanks,
-Christoffer