From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([2001:4830:134:3::10]:57377) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1VowJQ-0002gt-Cc for qemu-devel@nongnu.org; Fri, 06 Dec 2013 09:23:32 -0500 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1VowJK-0005LW-4q for qemu-devel@nongnu.org; Fri, 06 Dec 2013 09:23:24 -0500 Received: from mx1.redhat.com ([209.132.183.28]:53131) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1VowJJ-0005LO-SQ for qemu-devel@nongnu.org; Fri, 06 Dec 2013 09:23:18 -0500 Date: Fri, 6 Dec 2013 12:22:52 -0200 From: Marcelo Tosatti Message-ID: <20131206142252.GA7081@amt.cnet> References: <529D90A6.2080801@lab.ntt.co.jp> <52A0186A.2050207@lab.ntt.co.jp> <1386224104.3091.3.camel@nexus> <52A04732.4040105@redhat.com> <52A07C5A.9090105@lab.ntt.co.jp> <52A08541.6090702@redhat.com> <52A09EF4.5080800@lab.ntt.co.jp> <20131205161707.GB17277@amt.cnet> <52A0AC09.4090202@redhat.com> <52A189B2.4060305@lab.ntt.co.jp> MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: inline In-Reply-To: <52A189B2.4060305@lab.ntt.co.jp> Content-Transfer-Encoding: quoted-printable Subject: Re: [Qemu-devel] [PATCH] target-i386: clear guest TSC on reset List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Fernando Luis =?iso-8859-1?Q?V=E1zquez?= Cao Cc: Gleb Natapov , Paolo Bonzini , Will Auld , qemu-devel@nongnu.org, kvm@vger.kernel.org On Fri, Dec 06, 2013 at 05:24:18PM +0900, Fernando Luis V=E1zquez Cao wro= te: > On 12/06/2013 01:38 AM, Paolo Bonzini wrote: > >Il 05/12/2013 17:17, Marcelo Tosatti ha scritto: > >>>>I agree it is a bit ugly, but in my testing QEMU seemed to loop ove= r all > >>>>the VCPUS fast enough for the kernel side kvm_write_tsc() to do a > >>>>reasonable job of matching the offsets (the Linux guest did not mar= k > >>>>the TSC unstable due to the TSCs being unsynchronized). Am I missin= g > >>>>something? > >>Right, modern kernels (see kvm_write_tsc) perform synchronization, so= in > >>theory the "KVM is yet unable to synchronize ..." code is not necessa= ry > >>anymore. > >> > >>I vote for dropping the thing entirely. >=20 > When I was writing the original patch I was tempted to do that, > but I feared that it could break older kernels that do not have > TSC synchronization code. Should we care about such uses > (recent QEMU user space + old kernel)? Unfortunately there is no clean way to detect kernels that support TSC write synchronization (not directly at least). However the combination of recent qemu, pre-2010 kernel, and no kvmclock Linux guest can be ignored in my POV. > I also wanted to make sure that the initialization that we do > in kvm_arch_vcpu_postcreate on power up and the subsequent > TSC writeback work well together, but I didn't have time to > test it (reading the code, I would say that the TSC generation > counter may end up being increased a few times but the TSCs > would eventually converge). A basic test should be fine, because the matching code is in use=20 today. > >If it can be dropped entirely, I certainly have no problem with starti= ng > >with a simple patch first. >=20 > Could we start with the patch that I already sent? It's been > tested, it is conservative in the sense that it does the minimum > necessary to fix an existing bug, and should be easy to > backport. I will be replying to this email with an updated > version that has a more appropriate and less scary patch > description. >=20 > I will also be sending a patch that makes the TSC writeback > unconditional, but this one should probably be kept on hold > until it is properly tested. >=20 > As a follow-up effort we can work on Paolo's suggestions. >=20 > Is this an acceptable way forward? >=20 > Thanks, > Fernando