Re: [Xen-devel] time does not move forward in HVM guests

["Jan Beulich" <JBeulich@xxxxxxxx>]

>>> On 04.07.17 at 18:34, <olaf@xxxxxxxxx> wrote:
> In my testing with sysbench in a HVM domU running a linux-4.4 based
> pvops kernel on a xen-4.7 based dom0 the time does not move forward
> properly:
> 
> There (URL below) is basically code like this:
>   clock_gettime(CLOCK_MONOTONIC, a)
>   do_work
>   clock_gettime(CLOCK_MONOTONIC, b)
>   diff_time(a,b)
> 
> All 'do_work' does is writing zeros to a block of memory.
> clock_getres(CLOCK_MONOTONIC) indicates a resolution of 1ns.

But what's the implied meaning of resolution here? See below.

> If 'do_work' takes like 100ns or less: a==b. I think this is something
> that should not happen. In case of vcpu overcommit this happens also
> when 'do_work' takes around 800ns. At some point I have also seen cases
> of time going backward. I can not reproduce this anymore, might have
> been bugs in my code or the domU.cfg changed.

Or did you perhaps test with an older version, where the time
handling backports from master hadn't been there yet?

> A workaround is booting the domU kernel with 'clocksource=tsc nohz=off 
> highres=off'.

What clocksource does the system use by default? HPET?
According to what the hypervisor tells the guest, vHPET
resolution is 16ns. That still wouldn't explain a steady value
over a period of 100ns, but it's at least a hint that what the
kernel tells you may not be what underlying (virtual)
hardware reports.

Additionally - are all three options indeed required to work
around this, i.e. no pair out of the three is enough?

Jan


_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxx
https://lists.xen.org/xen-devel