[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] Re: [Xen-devel] [PATCH] Skip vcpu_hotplug for VCPU 0 in smp_resume
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
|
![]() |
Lists.xenproject.org is hosted with RackSpace, monitoring our |