Re: proposal: stop using the xen_system_time timecounter in dom0

[Manuel Bouyer <bouyer%antioche.eu.org@localhost>]

On Fri, Jun 21, 2024 at 03:12:04PM -0400, Greg Troxel wrote:
> "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.

We need to see what other OSes are doing in this area.
This code is not just about NetBSD's timecounter, in dom0 it's supposed
to adjust the Xen clock so that it's accurate for others.

-- 
Manuel Bouyer <bouyer%antioche.eu.org@localhost>
     NetBSD: 26 ans d'experience feront toujours la difference
--