Re: [Xen-devel] Xen clocksource and PV shim

[Igor Druzhinin <igor.druzhinin@xxxxxxxxxx>]

On 30/01/2020 23:14, Igor Druzhinin wrote:
> I was debugging constant freezes of PV shim on AMD hardware
> after going out of a long suspend. As it turned out the root cause
> of this is platform time jumping forward to the amount of time
> spent in suspended state. On Intel this issue is papered over
> by CONSTANT_TSC being set which avoids CPU time sync with
> platform time.
> 
> Upon further examination it appears that jumping is baked
> into the implementation of L0 Xen and there is no seemingly
> straight forward way to extract stable continuous rate out
> of what we have.
> 
> I expect this is a known issue with Xen PV clock as I found
> this almost immediately: https://wiki.debian.org/Xen/Clocksource
> Currently I don't understand how in that case Xen clock source
> could be suitable as a platform timer for nested Xen.
> 
> Is my understanding of the situation correct? Could it be
> fixed in L0 Xen or it's already backed into the ABI? Should
> we keep Xen platform timer in the source code then? Does using
> alternative clock source for PV shim make sense?

... Ok, I seem to get lost in the weeds of timekeeping code -
platform timer infrastructure is already prepared for this sort
of scenario while exiting S3. I just need to call resume_platform_timer()
from hypervisor_resume() or something similar. Patch will follow.

Although I'm still puzzled why Xen PV clock provides such an
unintuitive data to the guest.

Igor

_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxxxxxxxxx
https://lists.xenproject.org/mailman/listinfo/xen-devel