RE: [xen-devel] System time monotonicity

["Ian Pratt" <Ian.Pratt@xxxxxxxxxxxxx>]

> > The issue comes with cpus running on different frequency, like
driven
> > by multiple crystals or on-demand frequency change which affects TSC
> > too. HVM guest can be configured to avoid migrating among cpus with
> > different TSC freq, like limiting its cpu affinity to cpus on same
> > system bus.
> 
> These are the cases I am worried about.  The linux kernel seems to
have
> a number of cases that mark TSC as unstable, but Xen does not, nor (I
> think) does Xen expose this information anywhere.  So it seems SMP
> guests need to be pinned to physical CPUs that are measured to have
> sync'ed TSC's to guarantee that the (virtual) platform timer is
> monotonic.

Xen itself copes fine with CPUs running from entirely independent clock
sources. It calibrates the TSCs frequency against a global clock (e.g.
the hpet).

> > Or you have to configure HVM guest to not trust TSC...
> 
> Yes, that's what I'm thinking... like Linux, Xen could/should build
> virtual platform timers on a physical clocksource other than tsc if
all
> of the potential vcpu->pcpu mappings are not on sync'd-TSC-pcpus.

Although Xen is fine, guests can get confused if they're relying on the
TSC. Fortunately, Windows doesn't rely on the TSC, and most folk run
Linux PV which also works fine.

If you want to make Linux work HVM on such a system you need to either
convince it to not to use the TSC, or arrange for TSC reads to trap to
Xen and then compute the result based on Xen's time base. If you're
doing the latter, better hope that TSC reads aren't called frequently...


Ian






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