I think this patch is indeed an answer to my main concern about the dom0
timecounter on older systems without TSC_INVARIANT.
I'm not yet able to test it yet either as my limited set of hardware is
still doing other experiments.
BTW, as it turns out it currently would not work to override
kern.timecounter.choice after boot in a dom0.
In the current implementation the xen_system_time timecounter is
critical to the periodic resetting and reading of the TODR, which is
actually how the Xen hypervisor's so-called "wall clock time" is kept in
sync with dom0 as adjusted by ntpd. I think that could be worked
around, but....
Maybe there should be a very strong warning to Xen users not to override
the kern.timecounter in the mean time, and perhaps eventually, if we
continue to use xen_system_time in dom0s then other choices should not
even be allowed?
At Sun, 23 Jun 2024 09:15:44 +0000, "Mathew, Cherry G." <c%bow.st@localhost> wrote:
Subject: Re: [patch] Re: proposal: stop using the xen_system_time timecounter in dom0
>
> I compile tested the below - but have no way to test it currently.
>
> diff -r 1376eff6ff1c sys/arch/xen/xen/xen_clock.c
> --- a/sys/arch/xen/xen/xen_clock.c Sun Jun 23 00:53:48 2024 +0000
> +++ b/sys/arch/xen/xen/xen_clock.c Sun Jun 23 09:14:27 2024 +0000
> @@ -929,6 +929,17 @@
> xen_resumeclocks(ci);
>
> #ifdef DOM0OPS
> +#if __XEN_INTERFACE_VERSION__ >= 0x00030201
> +
> + struct sched_pin_override pin_cpuid = {
> + .pcpu = curcpu()->ci_cpuid,
> + };
> +
> + _hypercall2(int, sched_op, SCHEDOP_pin_override, &pin_cpuid);
> +#else
> + _hypercall2(int, sched_op, SCHEDOP_pin_override, curcpu()->ci_cpuid);
> +#endif
> +
> /*
> * If this is a privileged dom0, start pushing the wall
> * clock time back to the Xen hypervisor.
--
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:
pgp0Q4WXQ410V.pgp
Description: OpenPGP Digital Signature