From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([2001:4830:134:3::10]:57981) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1bwUZB-0002Ro-Qh for qemu-devel@nongnu.org; Tue, 18 Oct 2016 09:36:30 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1bwUZ6-0006K7-Ur for qemu-devel@nongnu.org; Tue, 18 Oct 2016 09:36:29 -0400 Received: from mx1.redhat.com ([209.132.183.28]:38456) by eggs.gnu.org with esmtps (TLS1.0:DHE_RSA_AES_256_CBC_SHA1:32) (Exim 4.71) (envelope-from ) id 1bwUZ6-0006Jr-P3 for qemu-devel@nongnu.org; Tue, 18 Oct 2016 09:36:24 -0400 Date: Tue, 18 Oct 2016 15:36:20 +0200 From: Radim =?utf-8?B?S3LEjW3DocWZ?= Message-ID: <20161018133619.GB2205@potion> References: <20161014212031.GQ3275@thinpad.lan.raisama.net> <20161017094708.GB31691@amt.cnet> <20161017145008.GA2307@potion> <72b8c6b3-f08a-735a-e283-99d0195dcf7d@redhat.com> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline In-Reply-To: <72b8c6b3-f08a-735a-e283-99d0195dcf7d@redhat.com> 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: Paolo Bonzini Cc: Marcelo Tosatti , Eduardo Habkost , qemu-devel@nongnu.org, kvm@vger.kernel.org 2016-10-17 18:24+0200, Paolo Bonzini: > On 17/10/2016 16:50, Radim Kr=C4=8Dm=C3=A1=C5=99 wrote: >> 2016-10-17 07:47-0200, Marcelo Tosatti: >>> 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 >> Yes, if we have well synchronized time between hosts, then we might be >> able to migrate with a TSC shift that cannot be perceived by the guest= . >>=20 >> Unless the VM also has a migratable assigned PCI device that uses ART, >> because we have no protocol to update the setting of ART (in CPUID), s= o >> we should keep migration forbidden then. >=20 > We don't publish the ART leaf at all, do we? Yes, it's a matter of time, though -- someone already asked for PTP in guests, so we'll have to either provide a paravirtual host<->guest time synchronization protocol that shares PTP from the host or let them use assigned devices ... >>> 1) Migration: to host with different TSC frequency. >>=20 >> We shouldn't have done this even now when emulating anything newer tha= n >> Pentium 4, because those CPUs have constant TSC, which only lacks the >> guarantee that it doesn't stop in deep C-states: >=20 > Right, but: >=20 >>> since Linux guests use kvmclock and Windows guests use Hyper-V >>> enlightenment, it should be fine to disable 2). >=20 > ... and 1 too. Yes. We could stop exposing TSC then, because it should have no direct users -- kvmclock can work even if TSC is not in CPUID, because we paravirtualize it. > We should also blacklist the TSC deadline timer when invtsc is not > available. True. I was thinking that with Wanpeng's VMX preemption patches, we might not need the TSC nor paravirtual deadline timer, the because performance of LAPIC one-shot could be very similar.