From mboxrd@z Thu Jan 1 00:00:00 1970 From: Dan Magenheimer Subject: Re: [PATCH] svm: Do not intercept RDTCS(P) when TSC scaling is supported by hardware Date: Fri, 20 Apr 2012 08:02:16 -0700 (PDT) Message-ID: <699116fb-992a-4ce2-8071-9bb7d6e43645@default> References: <55bf11ebce87ceb73fb2.1334888477@wotan.osrc.amd.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Return-path: In-Reply-To: List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org To: Keir Fraser , Boris Ostrovsky , JBeulich@suse.com Cc: wei.huang2@amd.com, xen-devel@lists.xensource.com List-Id: xen-devel@lists.xenproject.org > From: Keir Fraser [mailto:keir.xen@gmail.com] > Subject: Re: [Xen-devel] [PATCH] svm: Do not intercept RDTCS(P) when TSC scaling is supported by > hardware > > On 20/04/2012 03:21, "Boris Ostrovsky" wrote: > > > # HG changeset patch > > # User Boris Ostrovsky > > # Date 1334875170 14400 > > # Node ID 55bf11ebce87ceb73fb2c372dcef170ec0bb4a18 > > # Parent 7c777cb8f705411b77c551f34ba88bdc09e38ab8 > > svm: Do not intercept RDTCS(P) when TSC scaling is supported by hardware > > > > When running in TSC_MODE_ALWAYS_EMULATE mode on processors that support > > TSC scaling we don't need to intercept RDTSC/RDTSCP instructions. > > > > Signed-off-by: Boris Ostrovsky > > Acked-by: Wei Huang > > Tested-by: Wei Huang > > Worth an ack/nack from Dan M I'd say. He'll probably have some comment about > possible cross-CPU TSC skew. Provided the hypervisor writes the "TSC-scale-register" with the same value when any vcpu for any guest is scheduled, I don't think there is any cross-CPU TSC skew. But my recollection is that I had a concern that, to work properly after migration, TSC scaling might need to implement: ((B + cur_tsc) * scale ) + A and AFAIK the feature only implements this for B==0. Without the rest of the implementation in the hypervisor and tools, it's hard to determine whether my concern is valid or not. Also, I don't recall the exact scaling process but was also concerned that a guest kernel or userland process approximating the passage of time by counting TSC cycles, they might just estimate the value once at boot (or application startup) and, due to the scaling, post-migration ticks/second might later change enough to be a problem. However, this is a generic problem with emulation as well, so the concern is really: Does the TSC scaling use the same multiplication precision as is available to emulation in the hypervisor? Dan