RE: [Xen-devel] rdtscP and xen (and maybe the app-tsc answer I've been looking for)

["Jan Beulich" <JBeulich@xxxxxxxxxx>]

>>> Dan Magenheimer <dan.magenheimer@xxxxxxxxxx> 21.09.09 16:04 >>>
>> >>> Dan Magenheimer <dan.magenheimer@xxxxxxxxxx> 18.09.09 22:27 >>>
>> >Guest app must have some capability of getting 64-bit
>> >pvclock parameters directly from Xen without OS changes,
>> >e.g. emulated userland wrmsr, userland hypercall,
>> >or userland mapped shared page.  (This will be done
>> >rarely so need not be fast! But it does create
>> >a new userland<->Xen ABI that must be kept compatible.)
>> 
>> Are you sure this will indeed be infrequent enough? On my supposedly
>> constant-TSC AMD box, I see Xen quite frequently apply small error
>> correction factors to keep TSC from running ahead of HPET/PMTIMER.
>
>I'd like to hear from Keir on this, but I'd
>guess that this would be either a bug or a
>remnant of or inaccuracy in an old algorithm.
>
>Also if you could provide more information, I'd
>like to see if I can reproduce it on my Intel
>constant_tsc machines.
 
Not sure what further detail you mean - all that it is you would want to
look for are cases where error_factor is non-zero in
local_time_calibration() (or local time getting warped forward in the
same function; but I can only say for sure that the former does happen
not infrequently in terms of the percentage of executions of
local_time_calibration() - of course, that function itself doesn't run
very frequently).

Jan


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