At Thu, 20 Jun 2024 23:06:57 +0200, Manuel Bouyer <bouyer%antioche.eu.org@localhost> wrote: Subject: Re: proposal: stop using the xen_system_time timecounter in dom0 > > On Thu, Jun 20, 2024 at 01:53:34PM -0700, Greg A. Woods wrote: > > Workarounds such as pinning dom0's vCPUs, or assigning only one vCPU, > > are just that, poor workarounds (and possibly not even 100% reliable). I should have added "or override the system's choice of timecounter" to that list of poor workarounds. which would hopefully answer the following: > Why can't you just set kern.timecounter.hardware to something else > if xen_system_time isn't working for you ? 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. In fact the string "xen_system_time" appears only once in the whole source tree; code, documentation, and everything. BTW, I think now I know a bit more about it I would have called it "xen_TSC". :-) > > I think, if I'm not missing something else important, that this _could_ > > also allow for significant simplification of the code in xen_clock.c. > > The only dom0-specific code I see here is related to timepush and this > can't be removed 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. However for full support of migrating domUs then the scaling code must remain, and the frequency must be re-calibrated after every migration. Possibly something needs to be done to reset the system timecounter choice automatically after migration as well. Or we just tell people NetBSD domUs must always run with tsc_mode=emulate and then all that measuring and then scaling code can be removed as TSC will be guaranteed to be 1GHz. -- Greg A. Woods <gwoods%acm.org@localhost> Kelowna, BC +1 250 762-7675 RoboHack <woods%robohack.ca@localhost> Planix, Inc. <woods%planix.com@localhost> Avoncote Farms <woods%avoncote.ca@localhost>
Attachment:
pgps643xGVPco.pgp
Description: OpenPGP Digital Signature