At Tue, 19 Mar 2024 04:03:41 +0000, "Mathew, Cherry G.*" <c%bow.st@localhost> wrote: Subject: Re: timekeeping regression? > > > I had a cursory look at the xen time stuff - the per-cpu tick-count > seems to come from an rdtsc (hardware counter), I may be misunderstanding some important concepts here, but I don't think it's that simple (if I understand what you mean by "tick count" here). If I understand correctly the tick counter in Xen parlance is what they call the "Platform Timer" -- i.e. the timer (tick counter) from which all the other timers it uses are driven/derived. In x86/amd64 platforms that can be the CPU TSC register via RDTSC, but if, and only if, the CPU(s) have a reliable TSC, i.e. CONSTANT_TSC. On my systems the platform timer is always reported as HPET. > while the "wall clock" > seems to come from the hypervisor (via shared mem). If by "hypervisor" you mean the dom0? As I understand it the dom0 periodically updates the Xen kernel's wall clock time (via a hypercall). (at least when the dom0 is NetBSD) But what I wanted to understand is why Xen ever needs to know about wall clock time, and, most importantly if ever it uses its own tick counter to update its own idea of wall clock time, or worse what happens if the dom0 updates it with a skewed wall clock time because dom0 can't keep time properly. I suspect the Xen kernel wants to have wall clock time so that it can emulate RTC hardware, and/or tell PV guests directly via a hypercall what the current wall clock time is when they are first booted. I think the "xen_system_time" should be a timecounter derived from the Xen platform timer. -- 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:
pgpmTaqidoM6Z.pgp
Description: OpenPGP Digital Signature