When KVM paravirtual clock isn't available (e.g., on Xen or on plain Qemu),
we used the HPET clock. Our HPET clock driver rolled back the clock
(clock::get()->time()) once every 42 seconds, causing strange things like
a scheduler assertion when the clock jumps back.

The problem is that we read just 32 bits out of the 64 bits of the HPET
counter. This means that we roll back the clock once every 2^32 ticks,
and with the 10ns tick (which seems to be case in Qemu), this means about
42 seconds.

Douglas Adams would have liked this bug ;-)

Fixed the code, and removed overly-optimistic comment which stated the
rollback should take years.

Added an assertion that the HPET really has a 64-bit counter; Intel's HPET
specification from 2004 already specify that a 64-bit counter is recommended,
and both Qemu and Xen do implement a 64-bit counter. If we had to deal
with a 32-bit counter, we would need to write a handler for the interrupt
that the HPET sends every time the counter wraps around.

Signed-off-by: Nadav Har'El <nyh@cloudius-systems.com>
Signed-off-by: Avi Kivity <avi@cloudius-systems.com>