Hello, I'm using qemu-system-aarch64 on OSX. While reading cntvct_el0, I've seen the ticks count go backwards. I dug into the qemu source a bit, and this register is eventually backed by a call to clock_gettime(CLOCK_MONOTONIC), which should not go backwards.
Before I started delving into debugging qemu, I wanted to verify that this wasn't an OS issue. I wrote a simple test that read CLOCK_MONOTONIC every 100ms, compared the values to make sure they always increased, and let it run overnight. Lo and behold, I saw time go backwards. I repeated the test with CLOCK_MONOTONIC_RAW, and I did not see time go backwards. When I ran this test on a Fedora PC, I never saw time go backwards. I'm going to pursue what I believe to be the underlying issue separately, but my qemu questions are these: - Has anybody else seen this register go backwards? I don't see this running qemu-system-aarch64 on a Fedora PC, but I'm a small sample size. - Would it make sense to use CLOCK_MONOTONIC_RAW (if available) instead of CLOCK_MONOTONIC in qemu? My issue aside, CLOCK_MONOTONIC_RAW feels closer to giving the guest direct access to a hardware clock. The code already checks to see if CLOCK_MONOTONIC is available, and, if not, it reverts to a simple gettimeofday(). It would be easy to add another check to init_get_clock() to enable this behavior. I'm testing this myself, but I wanted to see if there was upstream interest in this and/or if there were reasons to prefer the current way. Thanks, and best regards, Joe
