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

[Ian Campbell <Ian.Campbell@xxxxxxxxxx>]

On Wed, 2009-04-01 at 06:26 -0400, Kieran Mansley wrote:
> 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.

It's worth bearing in mind for if/when you port this stuff to a newer
pvops kernel that it tries to make much greater use of the Linux device
model callbacks rather than using xenbus specific suspend/resume
methods. The Linux device model doesn't have a suspend cancelled
callback in it, AFAIK.

Ian.



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