RE: [Xen-devel] [RFC] Physical hot-add cpus and TSC

[Dan Magenheimer <dan.magenheimer@xxxxxxxxxx>]

> From: Keir Fraser [mailto:keir.fraser@xxxxxxxxxxxxx]
> Subject: Re: [Xen-devel] [RFC] Physical hot-add cpus and TSC
> 
> On 26/05/2010 17:44, "Dan Magenheimer" <dan.magenheimer@xxxxxxxxxx>
> wrote:
> 
> >> True at the moment, but can we not just whack the TSC of the newly
> >> added CPU  on the head when it is brought online, to match the
> >> boot CPU?
> >
> > Possibly... but the code for whacking the TSC of a CPU after
> > C3-state results in a TSC value that is poorly-aligned with other
> > running TSCs.  If there is a better way for "whacking" that
> > results in a nearly-perfectly-aligned TSC (that would pass
> > a "tsc warp test"), that is an option.
> 
> But what we do in 4.0 is whack all the TSCs at boot time... How is this
> any different?

I don't think we do that anymore, at least not when the
underlying machine is deemed to have a stable TSC
(Invariant TSC or constant/nonstop TSC with max_cstate<3).

> From: Ian Pratt [mailto:Ian.Pratt@xxxxxxxxxxxxx]
> Subject: RE: [Xen-devel] [RFC] Physical hot-add cpus and TSC
> 
> > Possibly... but the code for whacking the TSC of a CPU after
> > C3-state results in a TSC value that is poorly-aligned with other
> > running TSCs.  If there is a better way for "whacking" that
> > results in a nearly-perfectly-aligned TSC (that would pass
> > a "tsc warp test"), that is an option.
> 
> It ought to be possible to enhance the "whacking" code to set the TSC
> based on the topologically nearest live CPU and then sanity-check
> against all others, repeating a few times to protect against SMIs etc.

Well obviously firmware can do it pre-boot, but I don't know
what the impact of the mechanism is on running cpu's.  I'd assume
that at least all guest activity would have to be stopped for
some not-so-short period (~10-100msec?)

_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxxxxxxxx
http://lists.xensource.com/xen-devel