From mboxrd@z Thu Jan 1 00:00:00 1970 From: =?ISO-8859-1?Q?Fernando_Luis_V=E1zquez_Cao?= Subject: Re: [PATCH] target-i386: clear guest TSC on reset Date: Mon, 09 Dec 2013 17:50:17 +0900 Message-ID: <52A58449.6020707@lab.ntt.co.jp> 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> <20131206142252.GA7081@amt.cnet> Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: QUOTED-PRINTABLE Cc: Paolo Bonzini , Gleb Natapov , Will Auld , qemu-devel@nongnu.org, kvm@vger.kernel.org To: Marcelo Tosatti Return-path: Received: from tama500.ecl.ntt.co.jp ([129.60.39.148]:51636 "EHLO tama500.ecl.ntt.co.jp" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1754336Ab3LIIuh (ORCPT ); Mon, 9 Dec 2013 03:50:37 -0500 In-Reply-To: <20131206142252.GA7081@amt.cnet> Sender: kvm-owner@vger.kernel.org List-ID: On 12/06/2013 11:22 PM, Marcelo Tosatti wrote: > On Fri, Dec 06, 2013 at 05:24:18PM +0900, Fernando Luis V=E1zquez Cao= wrote: >> 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 > today. I applied my two patches to QEMU and I did some testing with SMP guests (4 VCPUs). When the host's TSC is stable all the TSC offsets are matched as expected: [ 4544.779699] kvm: VCPU 0 new tsc generation 1, clock 0 [ 4544.799691] kvm: VCPU 1 matched tsc offset for 0 [ 4544.835687] kvm: VCPU 2 matched tsc offset for 0 [ 4544.882229] kvm: VCPU 3 matched tsc offset for 0 [ 4544.983740] kvm: VCPU 0 matched tsc offset for 0 [ 4545.015727] kvm: VCPU 1 matched tsc offset for 0 [ 4545.031762] kvm: VCPU 2 matched tsc offset for 0 [ 4545.043756] kvm: VCPU 3 matched tsc offset for 0 [ 4545.382113] kvm: VCPU 0 matched tsc offset for 0 [ 4545.382138] kvm: VCPU 1 matched tsc offset for 0 [ 4545.382155] kvm: VCPU 2 matched tsc offset for 0 [ 4545.382171] kvm: VCPU 3 matched tsc offset for 0 Regarding unstable TSC hosts, I created one by executing TSCBSP=3D`rdmsr -d -p 0 16`; sleep 1s; wrmsr -p 0 16 $TSCBSP as you suggested. After doing this KVM will adjust the TSC offsets to make up for the deltas on the host side: [ 5232.172074] kvm: VCPU 0 new tsc generation 1, clock 0 [ 5232.180759] kvm: SMP vm created on host with unstable TSC; guest= =20 TSC will not be reliable [ 5232.204069] kvm: VCPU 1 adjusted tsc offset by 105344 [ 5232.268070] kvm: VCPU 2 adjusted tsc offset by 210721 [ 5232.332066] kvm: VCPU 3 adjusted tsc offset by 210708 [ 5232.444127] kvm: VCPU 0 adjusted tsc offset by 368959 [ 5232.458448] kvm: VCPU 1 adjusted tsc offset by 47158 [ 5232.470400] kvm: VCPU 2 adjusted tsc offset by 39352 [ 5232.482359] kvm: VCPU 3 adjusted tsc offset by 39371 [ 5232.875343] kvm: VCPU 0 adjusted tsc offset by 1293878 [ 5232.875371] kvm: VCPU 1 adjusted tsc offset by 121 [ 5232.875392] kvm: VCPU 2 adjusted tsc offset by 69 [ 5232.875412] kvm: VCPU 3 adjusted tsc offset by 62 But despite KVM's efforts on the guest side the check in check_tsc_sync_source() fails and the TSC is marked unstable: tsc: Marking TSC unstable due to check_tsc_sync_source failed By the way, without my patches applied to QEMU the end result is the same: [ 266.300068] kvm: VCPU 0 new tsc generation 1, clock 0 [ 266.308746] kvm: SMP vm created on host with unstable TSC; guest= =20 TSC will not be reliable [ 266.332067] kvm: VCPU 1 adjusted tsc offset by 105354 [ 266.396065] kvm: VCPU 2 adjusted tsc offset by 210714 [ 266.428273] kvm: VCPU 3 adjusted tsc offset by 106045 In other words, things seem to be working as expected. - Fernando