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@xxxxxxxxxx> 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
--
To unsubscribe from this list: send the line "unsubscribe kvm" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
