[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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


  • To: Igor Druzhinin <igor.druzhinin@xxxxxxxxxx>, Jan Beulich <jbeulich@xxxxxxxx>
  • From: Roger Pau Monné <roger.pau@xxxxxxxxxx>
  • Date: Fri, 31 Jan 2020 10:25:52 +0100
  • Authentication-results: esa2.hc3370-68.iphmx.com; dkim=none (message not signed) header.i=none; spf=None smtp.pra=roger.pau@xxxxxxxxxx; spf=Pass smtp.mailfrom=roger.pau@xxxxxxxxxx; spf=None smtp.helo=postmaster@xxxxxxxxxxxxxxx
  • Cc: xen-devel <xen-devel@xxxxxxxxxxxxxxxxxxxx>, Andrew Cooper <Andrew.Cooper3@xxxxxxxxxx>
  • Delivery-date: Fri, 31 Jan 2020 09:26:21 +0000
  • Ironport-sdr: rz634cC9I3zJAiVLeAzH0uETbuW/fOXH3peeWsfa0/AjpH3MH0UUNwRVZadkhezMEyq7Q0UV3H k78eTHPgGVezr7xwCYzvcAGUtG8bhpXAs7FSSoxjv9n0AZ8AiYjzrkQo9+2nwdE85jOcZIixk1 kkRTuLoaNHHnvbyDEFfhR9ZV5jVGpgSFlhy9HeMaGdgQ38abrsc5uV23e9HDqyHyCNqJ4qXPeQ mQTItZEDSKOX+7WJUf8Y7EmXHpC3Kve+G3v6d+L2AZPtY2DGn1Si4LtENeDsaQ6hpAp9lsvU4p BjY=
  • List-id: Xen developer discussion <xen-devel.lists.xenproject.org>

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

 


Rackspace

Lists.xenproject.org is hosted with RackSpace, monitoring our
servers 24x7x365 and backed by RackSpace's Fanatical Support®.