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

[Kieran Mansley <kmansley@solarflare.com>]

On Wed, 2009-04-01 at 11:31 +0100, Keir Fraser wrote:
> On 01/04/2009 11:26, "Kieran Mansley" <kmansley@solarflare.com> wrote:
> 
> >> 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?
> > 
> > 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.
> 
> Could we avoid any of this logic executing if there are no net accelerators?

The watch handler will try to load an accelerator if the configuration
changes, so even if there were no accelerators before the suspend,
unless you can prevent the watch from firing, you could end up with one
trying to load between the suspend and resume.

If you got rid of the feature to load the requested accelerator
automatically when the configuration changes, then yes, that might be
possible, but I think I'd rather leave that in and use an extra lock and
some state to ignore the watch firing at bad times.  This would mean we
could leave the watch in place during the suspend/resume/cancel cycle
(refreshing on resume).  The suspend_cancel callback would still be
necessary, but it would just be acquiring a lock and modifying some
state rather than doing a xenbus watch operation.

It's not clear to me what the source of the long delay is, and whether
that change would solve it: the extra lock would be contended with the
watch handler's work queue, and so if the watch is the source of the
delay it's possible that we'd just contend in a different way and the
delay would still be there.  Brendan: can you explain the delay for me?

Kieran