From mboxrd@z Thu Jan 1 00:00:00 1970 From: Christoffer Dall Subject: Re: [RFC PATCH] KVM: arm/arm64: Don't let userspace update CNTVOFF once guest is running Date: Thu, 9 Jul 2015 16:17:23 +0200 Message-ID: <20150709141723.GP13530@cbox> References: <559D483A.40507@arm.com> <559D51C5.3070600@arm.com> <20150709102201.GH13530@cbox> <20150709120531.GL13530@cbox> <20150709122406.GN13530@cbox> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Cc: Marc Zyngier , Claudio Fontana , Jan Kiszka , "kvmarm@lists.cs.columbia.edu" , arm-mail-list , kvm-devel , Paolo Bonzini To: Peter Maydell Return-path: Received: from mail-la0-f46.google.com ([209.85.215.46]:33811 "EHLO mail-la0-f46.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1750894AbbGIORS (ORCPT ); Thu, 9 Jul 2015 10:17:18 -0400 Received: by lagx9 with SMTP id x9so247148091lag.1 for ; Thu, 09 Jul 2015 07:17:17 -0700 (PDT) Content-Disposition: inline In-Reply-To: <20150709122406.GN13530@cbox> Sender: kvm-owner@vger.kernel.org List-ID: 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 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