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

RE: [Xen-devel] [PATCH][REPOST] Additional states for Xenbus:Suspend/Resume

  • To: "Stefan Berger" <stefanb@xxxxxxxxxx>, <xen-devel@xxxxxxxxxxxxxxxxxxx>
  • From: "Ian Pratt" <m+Ian.Pratt@xxxxxxxxxxxx>
  • Date: Tue, 24 Jan 2006 18:05:33 -0000
  • Delivery-date: Tue, 24 Jan 2006 18:14:10 +0000
  • List-id: Xen developer discussion <xen-devel.lists.xensource.com>
  • Thread-index: AcYdgKmvG1cL966+S5OcAsXd4eXeyADj18uw
  • Thread-topic: [Xen-devel] [PATCH][REPOST] Additional states for Xenbus:Suspend/Resume

> I have previously posted a version of this patch. The problem 
> that I have encountered with driver backends was that they 
> were unaware of the reason why a frontend was disappearing or 
> why it was created. The following patch allows the backend to 
> see whether a frontend is going into suspend mode and 
> disappearing vs. disappearing due to domain destruction or 
> being created due to a resume vs a domain creation. I have 
> separated out the code that actually uses this awareness in 
> the TPM driver for another patch. Backend drivers can now be 
> written such that it allows hotplug scripts to react 
> differently depending on this reason.

Its not clear that having an explicit suspend state is a good thing: The
recovery mechanism that kicks in upon restore is also used for
recovering from backend restarts, which can happen at any time in any
state (as a result of a crash). Having an explicit suspend notification
may actually send the wrong message to driver writers. Further, you
don't want to be doing things like running hotplug scripts during a time
critical operation like the final suspend/resume commit stage.


Xen-devel mailing list



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