Re: [Xen-devel] [PATCH] pvops: fix "xm save -c" issue

[Ian Campbell <Ian.Campbell@xxxxxxxxxxxxx>]

On Fri, 2011-01-21 at 06:28 +0000, SUZUKI, Kazuhiro wrote:
> Hi,
> 
> The following patch fixes 'xm save -c' issue.
> We defined 'PMSG_CANCEL' message for suspend cancel situation and
> suspend_cancel handler in pm_ops struct.
> If the suspend_cancel is defined, suspend_cancel() is called instead
> of resume().

Thanks. I like the general shape of this patch but the core pm
infrastructure change needs to be split out and sent upstream via the
power management maintainer. I think this is Rafael J. Wysocki
<rjw@xxxxxxx> and the linux-pm@xxxxxxxxxxxxxxxxxxxxxxxxxx list.

If you also split out the Xen conversion to dev_pm_ops, without the
suspend_cancel bit, then I think we can take that bit now and then you
can resend the bit which adds the suspend_cancel bits once the core
stuff is upstream.

Ian.

> 
> Thanks,
> KAZ
> 
> Signed-off-by: Kenji Wakamiya <wkenji@xxxxxxxxxxxxxx>
> Signed-off-by: Kazuhiro Suzuki <kaz@xxxxxxxxxxxxxx>
> 
> 
> From: Kenji Wakamiya <wkenji@xxxxxxxxxxxxxx>
> Subject: Re: [Xen-devel] [PATCH] pvops: fix "xm save -c" issue
> Date: Fri, 21 Jan 2011 14:35:09 +0900
> 
> > Hi Konrand, and sorry for very late response.
> > 
> > (2011/01/11 2:01), Konrad Rzeszutek Wilk wrote:
> >>> With this change how is the effect of dpm_suspend_start undone in the
> >>> suspend cancelled case?
> >>>
> >>> Currently we have
> >>>   dpm_suspend_start(PMSG_SUSPEND)
> >>>    xs_suspend
> >>>      dpm_suspend_noirq(PMSG_SUSPEND)
> >>>         SUSPEND
> >>>      dpm_resume_noirq(PMSG_RESUME)
> >>>    xs_resume or xs_supend_cancel
> >>>   dpm_resume_end(PMSG_RESUME)
> >>>
> >>> Which seems nicely nested and logical but by only calling dpm_resume_end
> >>> in the non-cancelled case we seem to be unbalancing things.
> >>>
> >>> Do we need some sort of dpm_resume_cancel, or some way of pushing the
> >>> cancelled flag down into the individual xenbus_device.resume handlers?
> >>>
> >>> Should we maybe simply be using a difference PMSG_XXX in the cancelled
> >>> case? Is this what one of PMSG_RESTORE or PMSG_RECOVER means?
> >>>
> >>> Looks like to propagate the PMSG_* to the actual device resume functions
> >>> we would need to provide a pm_ops for the struct bus xenbus_frontend
> >>> instead of relying on the legacy handlers. This is probably a
> >>> independently good idea anyway.
> >>
> >> ping?
> >>
> >> Kenji any ideas or patches to address Ian's comments?
> > 
> > My colleague made a patch which reflected Ian's comments, so I will ask 
> > him to post it. Please wait a little.
> > 
> > Thanks,
> > Kenji
> > 
> > 
> > _______________________________________________
> > Xen-devel mailing list
> > Xen-devel@xxxxxxxxxxxxxxxxxxx
> > http://lists.xensource.com/xen-devel



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