Re: time does not move forward in HVM guests

[Olaf Hering <olaf@aepfle.de>]

[-- Attachment #1.1: Type: text/plain, Size: 1331 bytes --]

On Wed, Jul 05, Jan Beulich wrote:

> > clock_getres(CLOCK_MONOTONIC) indicates a resolution of 1ns.
> But what's the implied meaning of resolution here? See below.

I have no ide what the returned value is supposed to promise.

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

It was weeks ago, and I have not seen it since then. I think it is fixed
in one way or another.

> > A workaround is booting the domU kernel with 'clocksource=tsc nohz=off 
> > highres=off'.
> What clocksource does the system use by default? HPET?

HPET would be really really slow. The default clocksource is "xen".

> 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.

If clocksource=xen relies on the hypervisor, perhaps the kernel should
be aware of it in some way. So far I have not checked where clock_getres
gets its data.


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

Yes, otherwise the kernel would complain, forgot the exact error
message.

Olaf

[-- Attachment #1.2: signature.asc --]
[-- Type: application/pgp-signature, Size: 195 bytes --]

[-- Attachment #2: Type: text/plain, Size: 127 bytes --]

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