From mboxrd@z Thu Jan 1 00:00:00 1970 From: haozhong.zhang@intel.com Subject: Re: [PATCH v2 3/3] target-i386: load the migrated vcpu's TSC rate Date: Mon, 26 Oct 2015 10:09:08 +0800 Message-ID: <20151026020908.GA12789@hzzhang-OptiPlex-9020.sh.intel.com> References: <1445325774-7195-1-git-send-email-haozhong.zhang@intel.com> <1445325774-7195-4-git-send-email-haozhong.zhang@intel.com> <20151022181137.GA3736@thinpad.lan.raisama.net> <20151023031448.GC3830@hzzhang-OptiPlex-9020.sh.intel.com> <20151023145802.GG3736@thinpad.lan.raisama.net> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Cc: , , "Michael S. Tsirkin" , , Paolo Bonzini , Richard Henderson , Marcelo Tosatti To: Eduardo Habkost Return-path: Received: from mga03.intel.com ([134.134.136.65]:43758 "EHLO mga03.intel.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1752364AbbJZCJL (ORCPT ); Sun, 25 Oct 2015 22:09:11 -0400 Content-Disposition: inline In-Reply-To: <20151023145802.GG3736@thinpad.lan.raisama.net> Sender: kvm-owner@vger.kernel.org List-ID: On Fri, Oct 23, 2015 at 12:58:02PM -0200, Eduardo Habkost wrote: > On Fri, Oct 23, 2015 at 11:14:48AM +0800, Haozhong Zhang wrote: > > On Thu, Oct 22, 2015 at 04:11:37PM -0200, Eduardo Habkost wrote: > > > On Tue, Oct 20, 2015 at 03:22:54PM +0800, Haozhong Zhang wrote: > > > > Set vcpu's TSC rate to the migrated value (if any). If KVM supports TSC > > > > scaling, guest programs will observe TSC increasing in the migrated rate > > > > other than the host TSC rate. > > > > > > > > The loading is controlled by a new cpu option 'load-tsc-freq'. If it is > > > > present, then the loading will be enabled and the migrated vcpu's TSC > > > > rate will override the value specified by the cpu option > > > > 'tsc-freq'. Otherwise, the loading will be disabled. > > > > > > Why do we need an option? Why can't we enable loading unconditionally? > > > > > > > If TSC scaling is not supported by KVM and CPU, unconditionally > > enabling this loading will not take effect which would be different > > from users' expectation. 'load-tsc-freq' is introduced to allow users > > to enable the loading of migrated TSC frequency if they do know the > > underlying KVM and CPU have TSC scaling support. > > > Sorry for the confusion, I changed my mind. The semantics of 'load-tsc-freq' is really confusing and we should not need it at all. Now, what I want to implement is to migrate the TSC frequency as much as possible. If it could not, QEMU does not abort the migration. > I don't get your argument about user expectations. We can't read the > user's mind, but let's enumerate all possible scenarios: > > * Host has TSC scaling, user expect TSC frequency to be set: > * We set it. The user is happy. Agree. > * Host has TSC scaling, user doesn't expect TSC frequency to be > set: > * We still set it. VM behaves better, guest doesn't see changing TSC > frequency. User didn't expect it but won't be unhappy. Agree. > * No TSC scaling, user expect TSC frequency to be set: > * We won't set it, user will be unhappy. But I believe we all agree > we shouldn't make QEMU abort migration by default on all hosts that > don't support TSC scaling. Agree and display warning messages. > * No TSC scaling, user doesn't expect TSC frequency to be set: > * We don't set it. User is happy. Agree. This is the current QEMU's behavior, so it's still acceptable. Thanks, Haozhong > > Could you clarify on which items you disagree above, exactly? > > -- > Eduardo > -- > To unsubscribe from this list: send the line "unsubscribe kvm" in > the body of a message to majordomo@vger.kernel.org > More majordomo info at http://vger.kernel.org/majordomo-info.html