Re: timekeeping regression?

["Mathew, Cherry G.*" <c%bow.st@localhost>]

>>>>> Greg A Woods <woods%planix.ca@localhost> writes:

    >> >>>>> Greg A Woods <woods%planix.ca@localhost> writes:
    >> 
    >> > Since I'm typing this mail on a VM of the "bad" (not-pinned) >
    >> machine I'll reboot it after it is sent.

    > So since that reboot the dom0 and domUs on that machine where I
    > re-instated "dom0_vcpus_pin=true" have had stable clocks keeping
    > time within a few milliseconds.  Normally by now there's been
    > quite a lot of activity on at least one of the VMs and both the
    > dom0 and domU clocks are starting to drift way off.  (Currently
    > I've got them all syncing to the other local machine that is
    > running at stratum 3 with multiple remote sources.)

This seems to strengthen my suspicion that our dom0/Xen interaction is a
bit under specified - for eg: dom0 is able to directly access privileged
hardware state such as apic registers, and ownership state isn't
necessarily clear (last I checked, which was a while ago) - so if our
dom0 is assuming a "native" path to reading system clock state, and
there is an existing Xen mechanism to maintain and export canonical
clock state, that's the obvious fix to this problem.


I'll look into this within the next few weeks.


    > BTW, I found the following rather interesting paper, especially
    > for its background information and discussion of xenclocksource
    > during my searches for information about all of this:

    > 	https://www.synclab.org/pubs/radclock_2010_OSDI.pdf

    > There are some more related documents here:

    > 	https://www.synclab.org/docs

    > That radclock thing also looks quite interesting too, and I see
    > there are patches for FreeBSD as well....

Thank you for sharing this - I hadn't come across it before. I'll add it
to my reading list for my tickless project.

For the above question though (barring the live-migration usecase
mentioned in the paper) - I think we can stick with the existing
mechanisms that work with native, non-virtualised code.


-- 
MatC/(~cherry)