From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([2001:4830:134:3::10]:50461) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1bw4WJ-0002T7-FL for qemu-devel@nongnu.org; Mon, 17 Oct 2016 05:47:48 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1bw4WI-0002Az-Lz for qemu-devel@nongnu.org; Mon, 17 Oct 2016 05:47:47 -0400 Received: from mx1.redhat.com ([209.132.183.28]:57882) by eggs.gnu.org with esmtps (TLS1.0:DHE_RSA_AES_256_CBC_SHA1:32) (Exim 4.71) (envelope-from ) id 1bw4WI-0002Ap-GW for qemu-devel@nongnu.org; Mon, 17 Oct 2016 05:47:46 -0400 Date: Mon, 17 Oct 2016 07:47:09 -0200 From: Marcelo Tosatti Message-ID: <20161017094708.GB31691@amt.cnet> References: <20161014212031.GQ3275@thinpad.lan.raisama.net> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline In-Reply-To: <20161014212031.GQ3275@thinpad.lan.raisama.net> Content-Transfer-Encoding: quoted-printable Subject: Re: [Qemu-devel] invtsc + migration + TSC scaling List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Eduardo Habkost Cc: qemu-devel@nongnu.org, kvm@vger.kernel.org, Paolo Bonzini On Fri, Oct 14, 2016 at 06:20:31PM -0300, Eduardo Habkost wrote: > I have been wondering: should we allow live migration with the > invtsc flag enabled, if TSC scaling is available on the > destination? TSC scaling and invtsc flag, yes. >=20 > For reference, this is what the Intel SDM says about invtsc: >=20 > The time stamp counter in newer processors may support an > enhancement, referred to as invariant TSC. Processor=E2=80=99s suppor= t > for invariant TSC is indicated by CPUID.80000007H:EDX[8]. >=20 > The invariant TSC will run at a constant rate in all ACPI P-, > C-. and T-states. This is the architectural behavior moving > forward. On processors with invariant TSC support, the OS may > use the TSC for wall clock timer services (instead of ACPI or > HPET timers). TSC reads are much more efficient and do not > incur the overhead associated with a ring transition or access > to a platform resource. >=20 > --=20 > Eduardo Yes. The blockage happened for different reasons: 1) Migration: to host with different TSC frequency. 2) Savevm: It is not safe to use the TSC for wall clock timer services. By allowing savevm, you make a commitment to allow a feature at the expense of not complying with the spec (specifically the " the OS may use the TSC for wall clock timer services", because the TSC stops relative to realtime for the duration of the savevm stop window). But since Linux guests use kvmclock and Windows guests use Hyper-V enlightenment, it should be fine to disable 2). There is a bug open for this, btw:=20 https://bugzilla.redhat.com/show_bug.cgi?id=3D1353073