At Fri, 21 Jun 2024 22:30:10 +0200, Manuel Bouyer <bouyer%antioche.eu.org@localhost> wrote:
Subject: Re: proposal: stop using the xen_system_time timecounter in dom0
>
> On Fri, Jun 21, 2024 at 01:17:43PM -0700, Greg A. Woods wrote:
> >
> > I.e. xen_rtc_set() could call nanotime(9) instead of xen_global_systime_ns().
>
> I'm not sure system_time can be set to an arbitrary value like nanotime(),
> this would have to be checked.
Maybe it should be nanouptime() instead..... (neither are "arbitrary")
The description of struct xenpf_settime64 for XENPF_settime says:
* Set clock such that it would read <secs,nsecs> after 00:00:00 UTC,
* 1 January, 1970 if the current system time was <system_time>.
Which doesn't really make total sense to me.
xen_set_rtc() provides all the values, using NetBSD's current real time
to set <secs,nsecs>, and then passing the current TSC-as-nanoseconds
value in <system_time>.
This (eventually) calls Xen's do_settime() which subtracts the given
<system_time> from the given <secs,nsecs> to (re)set Xen's "wall clock"
time -- so Xen's "wall clock" time is actually it's boot time (which
would also imply that adjustments to NetBSD's clock will effectively
reset Xen's idea of when it was booted).
NetBSD's xen_wall_clock() does imply I have understood correctly since
it takes Xen's "wall clock" time and adds the current "Xen system time"
in nanoseconds, which is taken from the vcpu_time_info, which is set by
Xen from the TSC, to get a current real time since the Unix epoch back
into a struct timespec(3).
It's all kinda circular.
Does this still match what the original "Xen and the Art of
Virtualization" paper says? Which is:
"'real time' is expressed in nanoseconds passed since machine boot
and is maintained to the accuracy of the processor's cycle counter"
so presumably this is from TSC on Intel machines, starting at zero at
boot time; and it then goes on to say:
"wall clock time is specified as an offset to be added to the
current real time"
which to me implies Xen's "wall-clock" time is indeed actually the
static boot time (unless TSC wraps, or do_settimd() adjusts it!).
The Xen terminology seems upside down and inside out to me!
Anyway if I have understood all of that closely enough then indeed
nanouptime() would be correct.
I have not yet looked in on what other systems do....
I would love to see the original NetBSD work done at cl.cam.ac.uk.
--
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:
pgplwFu7n7Tdw.pgp
Description: OpenPGP Digital Signature