Re: [Xen-devel] [PATCH] Skip vcpu_hotplug for VCPU 0 in smp_resume

[Kieran Mansley <kmansley@xxxxxxxxxxxxxx>]

On Tue, 2009-03-31 at 13:04 -0700, Brendan Cully wrote:
> On Tuesday, 31 March 2009 at 18:35, Keir Fraser wrote:
> > On 31/03/2009 18:24, "Brendan Cully" <brendan@xxxxxxxxx> wrote:
> > 
> > > The other is in the netfront accelerator. It tears down a xenstore
> > > watch on the accelerator path at every suspend, and adds the watch
> > > back on resume. As with any xenstore interaction, this can
> > > occasionally take a very long time. I'm going from faulty memory here,
> > > but I didn't think it was necessary to tear down and restore watches
> > > across suspend. Would it make sense to move the watch remove and add
> > > into the resume hook (taking it completely out of suspend and
> > > suspend_cancel)?
> > 
> > They have to be renewed on full resume, but of course they do not get reset
> > across a cancelled suspend. Kieran may be able to advise on changing the net
> > accel code.
> 
> Could it be as simple as this? I can't remember what happens if
> unregister_xenbus_watch is called after the xenbus connection has been
> reset. Should we just free the guest structures without interacting
> with xenstore at the start of the resume method?

I don't think that will work.  We need to remove the watch before the
suspend to ensure that the code that handles the watch will not be
activated during the migration.

The code that handles the watch may attempt to access hardware directly,
and during a migration this hardware might not be there any more.  The
approach the acceleration code takes is therefore to tear down the
accelerator's direct hardware access completely before the suspend, and
only reinstate it after the resume completes (on potentially new
hardware) or after the suspend is cancelled.

It may be possible to synchronise the watch handler with the
suspend/resume/cancel cycle without removing the watch, but that starts
to get complicated.

Kieran


_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxxxxxxxx
http://lists.xensource.com/xen-devel