Re: RE: Guest TSC and Xen (Intel and AMD feedback please)

[Jeremy Fitzhardinge <jeremy@goop.org>]

Dan Magenheimer wrote:
> Hi Andy --
>
> Thanks for the reply.
>
> No, I don't think the TSC offset capabilities in VT are sufficient.
> If you are migrating from a TSC-synchronized SMP system and TSC
> was selected as the clocksource by the guest at boot *because* TSC
> is always synchronized, and then you migrate to a system where TSC
> is not synchronized, Xen can synchronize it once at migrate time
> but then the TSC's on the target system will immediately start to
> diverge.  So TSC might be a reasonable clocksource on the first
> system but not on the target system.  One could of course use
> CPUID to disallow a TSC-unsynchronized host as a suitable target
> for a TSC-synchronized-assumed guest, but that seems overly restrictive,
> especially if TSC wasn't selected as the clocksource for the guest
> and/or the guest (and its apps) isn't particularly time-sensitive.
>   

Linux (as in, relatively modern kernels, at least) will downgrade the 
tsc if it starts misbehaving.  This can happen, for example, if the tsc 
seems fine on initial inspection, but then starts misbehaving when the 
cpu frequency changes.

On the other hand, if its a modern kernel you may as well use a pv linux 
kernel and get a proper pv clocksource.

This is an area in which kernel behaviour has been changing a lot over 
the last few years, so its hard to guess what any given kernel version 
(+hacked by vendor) will do in this case...

    J