From mboxrd@z Thu Jan 1 00:00:00 1970 From: Eduardo Habkost Subject: Re: [PATCH v2 0/3] target-i386: save/restore vcpu's TSC rate during migration Date: Fri, 23 Oct 2015 10:22:46 -0200 Message-ID: <20151023122246.GE3736@thinpad.lan.raisama.net> References: <1445325774-7195-1-git-send-email-haozhong.zhang@intel.com> <20151022184521.GB3736@thinpad.lan.raisama.net> <20151023103517.GA24590@amt.cnet> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Cc: Haozhong Zhang , qemu-devel@nongnu.org, kvm@vger.kernel.org, "Michael S. Tsirkin" , afaerber@suse.de, Paolo Bonzini , Richard Henderson To: Marcelo Tosatti Return-path: Received: from mx1.redhat.com ([209.132.183.28]:45794 "EHLO mx1.redhat.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1750938AbbJWMWv (ORCPT ); Fri, 23 Oct 2015 08:22:51 -0400 Content-Disposition: inline In-Reply-To: <20151023103517.GA24590@amt.cnet> Sender: kvm-owner@vger.kernel.org List-ID: On Fri, Oct 23, 2015 at 08:35:20AM -0200, Marcelo Tosatti wrote: > On Thu, Oct 22, 2015 at 04:45:21PM -0200, Eduardo Habkost wrote: > > On Tue, Oct 20, 2015 at 03:22:51PM +0800, Haozhong Zhang wrote: > > > This patchset enables QEMU to save/restore vcpu's TSC rate during the > > > migration. When cooperating with KVM which supports TSC scaling, guest > > > programs can observe a consistent guest TSC rate even though they are > > > migrated among machines with different host TSC rates. > > > > > > A pair of cpu options 'save-tsc-freq' and 'load-tsc-freq' are added to > > > control the migration of vcpu's TSC rate. > > > > The requirements and goals aren't clear to me. I see two possible use > > cases, here: > > > > 1) Best effort to keep TSC frequency constant if possible (but not > > aborting migration if not possible). This would be an interesting > > default, but a bit unpredictable. > > 2) Strictly ensuring TSC frequency stays constant on migration (and > > aborting migration if not possible). This would be an useful feature, > > but can't be enabled by default unless both hosts have the same TSC > > frequency or support TSC scaling. > > Only destination needs to support TSC scaling, to match the frequency > of the incoming host. True. > > The KVM code for this feature has submitted or integrated? > > > Which one(s) you are trying to implement? > > > > In other words, what is the right behavior when KVM_SET_TSC_KHZ fails or > > KVM_CAP_TSC_CONTROL is not available? We can't answer that question if > > the requirements and goals are not clear. > > > > Once we know what exactly is the goal, we could enable the new mode with > > a single option, instead of raw options to control migration stream > > loading/saving. > > Windows and Linux guests have paravirt clocks and/or options to > disable direct TSC usage for timekeeping purposes. So disabling > migration seems overkill. I assume that users who set TSC frequency explicitly in the VM config care about it (otherwise they wouldn't be setting it explicitly) and don't want it to change after migration. -- Eduardo