From mboxrd@z Thu Jan 1 00:00:00 1970 From: Paolo Bonzini Subject: Re: invtsc + migration + TSC scaling Date: Mon, 17 Oct 2016 18:24:38 +0200 Message-ID: <72b8c6b3-f08a-735a-e283-99d0195dcf7d@redhat.com> References: <20161014212031.GQ3275@thinpad.lan.raisama.net> <20161017094708.GB31691@amt.cnet> <20161017145008.GA2307@potion> Mime-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 8bit Cc: Eduardo Habkost , kvm@vger.kernel.org, qemu-devel@nongnu.org To: =?UTF-8?B?UmFkaW0gS3LEjW3DocWZ?= , Marcelo Tosatti Return-path: In-Reply-To: <20161017145008.GA2307@potion> List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: qemu-devel-bounces+gceq-qemu-devel=gmane.org@nongnu.org Sender: "Qemu-devel" List-Id: kvm.vger.kernel.org On 17/10/2016 16:50, Radim Krčmář 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. > > 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. > > 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), so > we should keep migration forbidden then. We don't publish the ART leaf at all, do we? >> 1) Migration: to host with different TSC frequency. > > We shouldn't have done this even now when emulating anything newer than > Pentium 4, because those CPUs have constant TSC, which only lacks the > guarantee that it doesn't stop in deep C-states: Right, but: >> since Linux guests use kvmclock and Windows guests use Hyper-V >> enlightenment, it should be fine to disable 2). ... and 1 too. We should also blacklist the TSC deadline timer when invtsc is not available. Paolo