Re: proposal: stop using the xen_system_time timecounter in dom0

[Greg Troxel <gdt%lexort.com@localhost>]

"Greg A. Woods" <woods%planix.ca@localhost> writes:

> The bigger problem with that suggestion is that xen_system_time is
> currently implemented as if it were always the ideal timecounter choice
> (with a fixed quality of 10,000), whereas in reality in a dom0 it is
> equivalent to TSC, though with different, and possibly differently
> behaving, code.  On my hardware the real TSC timecounter gets a quality
> of -100 (and it's not even registered by a XEN3_DOM0 kernel, and I don't
> quite understand why not, at least not yet).
>
> Also nothing in the current documentation says anything about the
> limitations and underlying implementation of xen_system_time to even
> begin to hint as to why one might want to avoid it for a dom0.

I think the key question is that if there is a time implementation which
does not work in some circumstances, it should not be available in those
circumstances, quality level of not.

If I am following, the problem is that on some CPU implementations rdtsc
returns values that are from distinct counters on each CPU.  On such a
machine with a different hardware CPU bound to the logical xen cpu, even
being careful to read it from cpu0 doesn't work.  And it's not just poor
quality, it's really wrong.  Thus on those machines, it shouldn't be
exposed.

And on Manuel's systems, perhaps the hardware returns the same value
from all cpus, avoiding all of this.  There, I still don't understand
why using this emulation is better than just using rdtsc code.

Overall, I think we need to really understand and to withdraw interfaces
that produce bad results, not just downscore them.  the scoring should
be for less than great resoultion or other mild things, not brokenness.