Re: [PATCH] svm: Do not intercept RDTCS(P) when TSC scaling is supported by hardware

From: Wei Huang <wei.huang2@amd.com>
To: Dan Magenheimer <dan.magenheimer@oracle.com>
Cc: Boris Ostrovsky <boris.ostrovsky@amd.com>,
	Keir Fraser <keir.xen@gmail.com>,
	xen-devel@lists.xensource.com, JBeulich@suse.com
Subject: Re: [PATCH] svm: Do not intercept RDTCS(P) when TSC scaling is supported by hardware
Date: Fri, 20 Apr 2012 11:20:34 -0500	[thread overview]
Message-ID: <4F918CD2.7080307@amd.com> (raw)
In-Reply-To: <699116fb-992a-4ce2-8071-9bb7d6e43645@default>

On 04/20/2012 10:02 AM, Dan Magenheimer wrote:
>> 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"<boris.ostrovsky@amd.com>  wrote:
>>
>>> # HG changeset patch
>>> # User Boris Ostrovsky<boris.ostrovsky@amd.com>
>>> # 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<boris.ostrovsky@amd.com>
>>> Acked-by: Wei Huang<wei.huang2@amd.com>
>>> Tested-by: Wei Huang<wei.huang2@amd.com>
>> 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
Hi Dan,

Thanks for your review. I tried to interpret this formula as the following:

cur_tsc: Guest TSC before migration
B: time elapsed (overhead) during migration
scale: ratio of guest frequency/target host frequency
A: target host TSC

> 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.
If my interpretation above is correct, doesn't emulated TSC have the 
same problem of B == 0?
> 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?
Hardware TSC scaling uses 8.32 format: 8 bits for integer part and 32 
bits for fraction. Is it enough for the precision from your experience? 
The details of TSC scaling spec can be found on page 554 of 
http://support.amd.com/us/Processor_TechDocs/24593_APM_v2.pdf.
> Dan
>
>