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

[Roger Pau Monné <roger.pau@xxxxxxxxxx>]

On Fri, Jan 31, 2020 at 09:26:50AM +0100, Jan Beulich wrote:
> 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.

AFAICT you will also have to implement the resume hook for
plt_xen_timer in order to reset last_value to 0 on resume.

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

Not sure time_resume() is suitable as-is, it pokes at IO ports for PIT
which are not implemented, and hence might need some massaging to work
on a PVH environment.

I'm not sure there's a lot more that needs resuming, the state of
emulated devices is preserved across suspend/resume, and the shim
itself only uses event channels, grant tables and the timer PV
interfaces, which are the ones that need resuming since state is not
preserved for PV interfaces.

Roger.

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