Re: proposal: stop using the xen_system_time timecounter in dom0

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

On Fri, Jun 21, 2024 at 12:33:57PM -0700, Greg A. Woods wrote:
> At Fri, 21 Jun 2024 09:27:18 +0200, Manuel Bouyer <bouyer%antioche.eu.org@localhost> wrote:
> Subject: Re: proposal:  stop using the xen_system_time timecounter in dom0
> > 
> > Yes, the TSC is not always accessible under Xen, I noticed this.
> > I think it depends on hardware.
> 
> I guess I need more printfs in x86/x86/tsc.c to see why.....
> 
> From what I can see so far there shouldn't be any difference between
> XEN3_DOM0 and GENERIC w.r.t. the TSC timecounter detection, evaluation,
> and registration, yet there is.
> 
> > > I was alluding to the somewhat complex frequency measuring and scaling
> > > code that goes unused in XEN3_DOMU so long as other assumptions about
> > > emulated RDTSC always being 1GHz, and indeed always being emulated,
> > > remain in place.
> > 
> > I don't understand what you're talking about. xen_clock.c already assumes
> > that xen_timecounter is running at 1Ghz
> > what «frequency measuring and scaling» are you talking about ?
> 
> So, yes xen_system_time presents a timecounter(9) that is running at a
> fixed 1GHz regardless of the underlying CPU hardware or CPU clock.
> 
> However the TSC source it is using to do so is _not_ always running at a
> fixed 1GHz else it would not work at all in any dom0.
> 
> In a domU the emulated RDTSC that xen_system_time is using is presenting
> a fixed fictional 1GHz clock and so no scaling is required.
> 
> However because dom0 also attaches xen_system_time as a timecounter, and
> does so maintaining the fixed 1GHz clock, it _must_ measure and then
> scale the raw un-emulated RDTSC it uses in order to present
> xen_system_time as a 1GHz timecounter.
> 
> See for example my most recent post in the timekeeping regression thread
> where I discuss a XEN_CLOCK_DEBUG printf and in particular the values of
> delta_tsc and delta_ns and their ratio.
> 
> In particular xen_tsc_to_ns_delta() would be unnecessary if used only in
> domU and only with emulated RDTSC (i.e. if supporting migration required
> users to force tsc_mode=emulate).

But actually we can't drop this code from the dom0; this is what provides
Xen an accurate time. See XENPF_settime

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