From mboxrd@z Thu Jan 1 00:00:00 1970 From: Dan Magenheimer Subject: Re: [PATCH] xen: always set the sched clock as unstable Date: Mon, 16 Apr 2012 09:20:26 -0700 (PDT) Message-ID: References: <1334341255-11153-1-git-send-email-david.vrabel@citrix.com> <4F8C1F6D020000780007E11A@nat28.tlf.novell.com> <4F8C33E0.2080007@citrix.com> <20120416151759.GI1903@phenom.dumpdata.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Return-path: In-Reply-To: <20120416151759.GI1903@phenom.dumpdata.com> List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org To: Konrad Wilk , David Vrabel Cc: "Tim (Xen.org)" , linux-kernel@vger.kernel.org, xen-devel , Jan Beulich , Sheng Yang , Thomas Gleixner List-Id: xen-devel@lists.xenproject.org > From: Konrad Rzeszutek Wilk > Subject: Re: [Xen-devel] [PATCH] xen: always set the sched clock as unstable > > On Mon, Apr 16, 2012 at 03:59:44PM +0100, David Vrabel wrote: > > On 16/04/12 12:32, Jan Beulich wrote: > > >>>> On 13.04.12 at 20:20, David Vrabel wrote: > > >> From: David Vrabel > > >> > > >> The sched clock was considered stable based on the capabilities of the > > >> underlying hardware. This does not make sense for Xen PV guests as: > > In regards to PV dom0 is this still the case? Asking b/c your > patch will make dom0 be in the same category. > > > >> a) the hardware TSC is not used directly as the clock source; and b) > > >> guests may migrate to hosts with different hardware capabilities. > > >> > > >> It is not clear to me whether the Xen clock source is supposed to be > > >> stable and whether it should be stable across migration. For a clock Xen is -- and has always been -- responsible for emulating sufficient clock hardware devices and presenting them to the guest AND ensuring that this emulation works properly across migration/save/restore (which is required because these transitions may be completely transparent to the guest). Prior to Xen 4.0, TSC was not considered to be a clocksource worthy of emulating and was passed through to PV guests unchanged (and not fully handled for HVM either IIRC). At Xen 4.0+, it is handled properly. > I thought it was dependent on XEN_DOMCTL_settscinfo: > - whether it gets emulated, or the guest can do rdtsc or pvrdtsc? > > Which I think is determined by some 'timer=X' option in the guest config? I think you may be thinking of tsc_mode. See docs/misc/tscmode.txt in the Xen source. The default should work correctly.