|
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] Re: [Xen-devel] Xen clocksource and PV shim
On 31.01.2020 04:02, Igor Druzhinin wrote: > 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. What is "suspend" here? S3? If so, ... >> 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. ... why would time_resume() not be called? Oh, pv_shim_shutdown() uses PV mechanisms to do the suspend/resume. I wonder what else, besides time_resume(), is missing there. Jan _______________________________________________ Xen-devel mailing list Xen-devel@xxxxxxxxxxxxxxxxxxxx https://lists.xenproject.org/mailman/listinfo/xen-devel
|
 |
Lists.xenproject.org is hosted with RackSpace, monitoring our |