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@lists.xenproject.org https://lists.xenproject.org/mailman/listinfo/xen-devel
