From mboxrd@z Thu Jan 1 00:00:00 1970 From: Marcelo Tosatti Subject: Re: [libvirt] TSC scaling interface to management Date: Fri, 28 Sep 2012 22:07:16 -0300 Message-ID: <20120929010716.GC15943@amt.cnet> References: <20120912153939.GA19144@amt.cnet> <20120925100858.GA5869@redhat.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Cc: libvir-list@redhat.com, kvm To: "Daniel P. Berrange" , Karen Noel Return-path: Received: from mx1.redhat.com ([209.132.183.28]:33141 "EHLO mx1.redhat.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1030298Ab2I2BUj (ORCPT ); Fri, 28 Sep 2012 21:20:39 -0400 Received: from int-mx01.intmail.prod.int.phx2.redhat.com (int-mx01.intmail.prod.int.phx2.redhat.com [10.5.11.11]) by mx1.redhat.com (8.14.4/8.14.4) with ESMTP id q8T1Kcke018121 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK) for ; Fri, 28 Sep 2012 21:20:39 -0400 Content-Disposition: inline In-Reply-To: <20120925100858.GA5869@redhat.com> Sender: kvm-owner@vger.kernel.org List-ID: On Tue, Sep 25, 2012 at 11:08:58AM +0100, Daniel P. Berrange wrote: > On Wed, Sep 12, 2012 at 12:39:39PM -0300, Marcelo Tosatti wrote: > > > > > > HW TSC scaling is a feature of AMD processors that allows a > > multiplier to be specified to the TSC frequency exposed to the guest. > > > > KVM also contains provision to trap TSC ("KVM: Infrastructure for > > software and hardware based TSC rate scaling" cc578287e3224d0da) > > or advance TSC frequency. > > > > This is useful when migrating to a host with different frequency and > > the guest is possibly using direct RDTSC instructions for purposes > > other than measuring cycles (that is, it previously calculated > > cycles-per-second, and uses that information which is stale after > > migration). > > > > "qemu-x86: Set tsc_khz in kvm when supported" (e7429073ed1a76518) > > added support for tsc_khz= option in QEMU. > > > > I am proposing the following changes so that management applications > > can work with this: > > > > 1) New option for tsc_khz, which is tsc_khz=host (QEMU command line > > option). Host means that QEMU is responsible for retrieving the > > TSC frequency of the host processor and use that. > > Management application does not have to deal with the burden. > > FYI, libvirt already has support for expressing a number of different > TSC related config options, for support of Xen and VMWare's capabilities > in this area. What we currently allow for is > > > > In this context the frequency attribute provides the HZ value to > provide to the guest. > > - auto == Emulate if TSC is unstable, else allow native TSC access > - native == Always allow native TSC access > - emulate = Always emulate TSC > - smpsafe == Always emulate TSC, and interlock SMP These options can be mapped into KVM if necessary (they can map to tsc_khz=XXX or to the module options (unfortunately not per-guest ATM)). > > Therefore it appears that this "tsc_khz=auto" option can be specified > > only if the user specifies so (it can be a per-guest flag hidden > > in the management configuration/manual). > > > > Sending this email to gather suggestions (or objections) > > to this interface. > > > Daniel > -- > |: http://berrange.com -o- http://www.flickr.com/photos/dberrange/ :| > |: http://libvirt.org -o- http://virt-manager.org :| > |: http://autobuild.org -o- http://search.cpan.org/~danberr/ :| > |: http://entangle-photo.org -o- http://live.gnome.org/gtk-vnc :| Karen had the suggestion to remove the burden of choice from the user, which we can achieve by knowing whether or not the guest is using a paravirtual clock. The problem is that opens a can of races: Did migration happen before or after guest boot process enabled the paravirtual clock etc. I suppose leaving the option to the user is fine: if you run an obscure operating system, which does not support paravirtual clock, then it must be dealt with specialy (its in the manual, no big deal).