[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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



On 04/20/2012 10:02 AM, Dan Magenheimer wrote:
From: Keir Fraser [mailto:keir.xen@xxxxxxxxx]
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@xxxxxxx>  wrote:

# HG changeset patch
# User Boris Ostrovsky<boris.ostrovsky@xxxxxxx>
# 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@xxxxxxx>
Acked-by: Wei Huang<wei.huang2@xxxxxxx>
Tested-by: Wei Huang<wei.huang2@xxxxxxx>
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





_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxx
http://lists.xen.org/xen-devel


 


Rackspace

Lists.xenproject.org is hosted with RackSpace, monitoring our
servers 24x7x365 and backed by RackSpace's Fanatical Support®.