Hi, I''m investigating the issue of "xm save -c" in case of PV guests. Then, I tried to prevent calling dpm_resume_end() when suspend was canceled. It seems to work fine about blk and net. How about this? Thanks, Signed-off-by: Kenji Wakamiya <wkenji@jp.fujitsu.com> Signed-off-by: Kazuhiro Suzuki <kaz@jp.fujitsu.com> -- Kenji Wakamiya _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel
Konrad Rzeszutek Wilk
2010-Dec-14 14:59 UTC
Re: [Xen-devel] [PATCH] pvops: fix "xm save -c" issue
On Tue, Dec 14, 2010 at 02:31:36PM +0900, Kenji Wakamiya wrote:> Hi, > > I''m investigating the issue of "xm save -c" in case of PV guests. > Then, I tried to prevent calling dpm_resume_end() when suspend was > canceled. It seems to work fine about blk and net. > How about this?Could you give more details of what the failure is?> > Thanks, > > Signed-off-by: Kenji Wakamiya <wkenji@jp.fujitsu.com> > Signed-off-by: Kazuhiro Suzuki <kaz@jp.fujitsu.com> > -- > Kenji Wakamiya >> diff --git a/drivers/xen/manage.c b/drivers/xen/manage.c > index 0b50906..3dcc270 100644 > --- a/drivers/xen/manage.c > +++ b/drivers/xen/manage.c > @@ -148,11 +148,10 @@ out_resume: > if (!cancelled) { > xen_arch_resume(); > xs_resume(); > + dpm_resume_end(PMSG_RESUME); > } else > xs_suspend_cancel(); > > - dpm_resume_end(PMSG_RESUME); > - > /* Make sure timer events get retriggered on all CPUs */ > clock_was_set(); >> _______________________________________________ > Xen-devel mailing list > Xen-devel@lists.xensource.com > http://lists.xensource.com/xen-devel_______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel
Kenji Wakamiya
2010-Dec-15 04:18 UTC
Re: [Xen-devel] [PATCH] pvops: fix "xm save -c" issue
Hi Konrad, thank you for your response, Konrad Rzeszutek Wilk wrote:> On Tue, Dec 14, 2010 at 02:31:36PM +0900, Kenji Wakamiya wrote: >> Hi, >> >> I''m investigating the issue of "xm save -c" in case of PV guests. >> Then, I tried to prevent calling dpm_resume_end() when suspend was >> canceled. It seems to work fine about blk and net. >> How about this? > > > Could you give more details of what the failure is?"xm save -c" saves domain state to storage and leaves it running after creating snapshot. When this command is executed for a pvops guest (xen/stable-2.6.32.x), the guest will hang up after accessing to devices. When the guest is unapused, stop_machine() in manage.c returns as the suspend is cancelled. In that case, I think dpm_resume_end() should not be called after stop_machine(). I tested vbd and net, the guest did not hang. But I''m not sure if this is a right way... Thanks,>> Thanks, >> >> Signed-off-by: Kenji Wakamiya <wkenji@jp.fujitsu.com> >> Signed-off-by: Kazuhiro Suzuki <kaz@jp.fujitsu.com> >> -- >> Kenji Wakamiya >> > >> diff --git a/drivers/xen/manage.c b/drivers/xen/manage.c >> index 0b50906..3dcc270 100644 >> --- a/drivers/xen/manage.c >> +++ b/drivers/xen/manage.c >> @@ -148,11 +148,10 @@ out_resume: >> if (!cancelled) { >> xen_arch_resume(); >> xs_resume(); >> + dpm_resume_end(PMSG_RESUME); >> } else >> xs_suspend_cancel(); >> >> - dpm_resume_end(PMSG_RESUME); >> - >> /* Make sure timer events get retriggered on all CPUs */ >> clock_was_set(); >> > >> _______________________________________________ >> Xen-devel mailing list >> Xen-devel@lists.xensource.com >> http://lists.xensource.com/xen-devel >_______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel
Konrad Rzeszutek Wilk
2010-Dec-15 15:40 UTC
Re: [Xen-devel] [PATCH] pvops: fix "xm save -c" issue
On Wed, Dec 15, 2010 at 01:18:06PM +0900, Kenji Wakamiya wrote:> Hi Konrad, thank you for your response, > > Konrad Rzeszutek Wilk wrote: > >On Tue, Dec 14, 2010 at 02:31:36PM +0900, Kenji Wakamiya wrote: > >>Hi, > >> > >>I''m investigating the issue of "xm save -c" in case of PV guests. > >>Then, I tried to prevent calling dpm_resume_end() when suspend was > >>canceled. It seems to work fine about blk and net. > >>How about this? > > > > > >Could you give more details of what the failure is? > > "xm save -c" saves domain state to storage and leaves it running after > creating snapshot. When this command is executed for a pvops > guest (xen/stable-2.6.32.x), the guest will hang up after accessing to > devices. > > When the guest is unapused, stop_machine() in manage.c returns as the > suspend is cancelled. In that case, I think dpm_resume_end() should > not be called after stop_machine(). > > I tested vbd and net, the guest did not hang.OK. Does ''xm save'' (so no -c) and then resume work with this patch (I would think so, but I am curious whether you tested this).> But I''m not sure if this is a right way...Looks OK to me, just want to make sure that the normal ''xm save'' still works after this. _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel
Kenji Wakamiya
2010-Dec-16 05:49 UTC
Re: [Xen-devel] [PATCH] pvops: fix "xm save -c" issue
Hi Konrad, Konrad Rzeszutek Wilk wrote:>> When the guest is unapused, stop_machine() in manage.c returns as the >> suspend is cancelled. In that case, I think dpm_resume_end() should >> not be called after stop_machine(). >> >> I tested vbd and net, the guest did not hang. > > OK. Does ''xm save'' (so no -c) and then resume work with this patch > (I would think so, but I am curious whether you tested this). > >> But I''m not sure if this is a right way... > > Looks OK to me, just want to make sure that the normal ''xm save'' still > works after this.I tested normal ''xm save'' with this patch, and made sure it works well. When normal save/restore is performed, the domain is suspended without cancel, unlike ''save -c''. So, dpm_resume_end() is called. This scenario haven''t changed even after applying this patch. Thanks, -- Kenji Wakamiya _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel
On Thu, 2010-12-16 at 05:49 +0000, Kenji Wakamiya wrote:> Hi Konrad, > > Konrad Rzeszutek Wilk wrote: > >> When the guest is unapused, stop_machine() in manage.c returns as the > >> suspend is cancelled. In that case, I think dpm_resume_end() should > >> not be called after stop_machine(). > >> > >> I tested vbd and net, the guest did not hang. > > > > OK. Does ''xm save'' (so no -c) and then resume work with this patch > > (I would think so, but I am curious whether you tested this). > > > >> But I''m not sure if this is a right way... > > > > Looks OK to me, just want to make sure that the normal ''xm save'' still > > works after this. > > I tested normal ''xm save'' with this patch, and made sure it works well. > > When normal save/restore is performed, the domain is suspended without > cancel, unlike ''save -c''. So, dpm_resume_end() is called. This > scenario haven''t changed even after applying this patch.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. Ian. _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel
Konrad Rzeszutek Wilk
2011-Jan-10 17:01 UTC
Re: [Xen-devel] [PATCH] pvops: fix "xm save -c" issue
On Fri, Dec 17, 2010 at 09:43:16AM +0000, Ian Campbell wrote:> On Thu, 2010-12-16 at 05:49 +0000, Kenji Wakamiya wrote: > > Hi Konrad, > > > > Konrad Rzeszutek Wilk wrote: > > >> When the guest is unapused, stop_machine() in manage.c returns as the > > >> suspend is cancelled. In that case, I think dpm_resume_end() should > > >> not be called after stop_machine(). > > >> > > >> I tested vbd and net, the guest did not hang. > > > > > > OK. Does ''xm save'' (so no -c) and then resume work with this patch > > > (I would think so, but I am curious whether you tested this). > > > > > >> But I''m not sure if this is a right way... > > > > > > Looks OK to me, just want to make sure that the normal ''xm save'' still > > > works after this. > > > > I tested normal ''xm save'' with this patch, and made sure it works well. > > > > When normal save/restore is performed, the domain is suspended without > > cancel, unlike ''save -c''. So, dpm_resume_end() is called. This > > scenario haven''t changed even after applying this patch. > > 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? _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel
Kenji Wakamiya
2011-Jan-21 05:35 UTC
Re: [Xen-devel] [PATCH] pvops: fix "xm save -c" issue
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@lists.xensource.com http://lists.xensource.com/xen-devel
SUZUKI, Kazuhiro
2011-Jan-21 06:28 UTC
Re: [Xen-devel] [PATCH] pvops: fix "xm save -c" issue
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, KAZ Signed-off-by: Kenji Wakamiya <wkenji@jp.fujitsu.com> Signed-off-by: Kazuhiro Suzuki <kaz@jp.fujitsu.com> From: Kenji Wakamiya <wkenji@jp.fujitsu.com> 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@lists.xensource.com > http://lists.xensource.com/xen-devel_______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel
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@sisk.pl> and the linux-pm@lists.linux-foundation.org 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@jp.fujitsu.com> > Signed-off-by: Kazuhiro Suzuki <kaz@jp.fujitsu.com> > > > From: Kenji Wakamiya <wkenji@jp.fujitsu.com> > 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@lists.xensource.com > > http://lists.xensource.com/xen-devel_______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel
SUZUKI, Kazuhiro
2011-Jan-25 07:23 UTC
Re: [Xen-devel] [PATCH] pvops: fix "xm save -c" issue
Hi Ian, I split the patch into pm infrastructure part and xen part. Actually, I''ve never post to linux community, so I''m not sure what to do. Thanks, KAZ Signed-off-by: Kenji Wakamiya <wkenji@jp.fujitsu.com> Signed-off-by: Kazuhiro Suzuki <kaz@jp.fujitsu.com> From: Ian Campbell <Ian.Campbell@eu.citrix.com> Subject: Re: [Xen-devel] [PATCH] pvops: fix "xm save -c" issue Date: Fri, 21 Jan 2011 09:14:30 +0000> 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@sisk.pl> and the linux-pm@lists.linux-foundation.org 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@jp.fujitsu.com> >> Signed-off-by: Kazuhiro Suzuki <kaz@jp.fujitsu.com> >> >> >> From: Kenji Wakamiya <wkenji@jp.fujitsu.com> >> 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@lists.xensource.com >> > http://lists.xensource.com/xen-devel > >_______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel
On Tue, 2011-01-25 at 07:23 +0000, SUZUKI, Kazuhiro wrote:> Hi Ian, > > I split the patch into pm infrastructure part and xen part. > Actually, I''ve never post to linux community, so I''m not sure what to > do.Documentation/SubmittingPatches in the Linux source tree has some good guidance. In general you need to post your patches inline (not as attachments which is a difference from the Xen maintainer''s policy) with a changelog message, in this case explaining the need for the new event type and explaining the use cases etc, and a signed-off-by. You should send to the subsystem maintainer and the relevant mailing list, the MAINTAINERS file in the Linux source would help figure out who they are but in this case I think it is Rafael J. Wysocki <rjw@sisk.pl> and the linux-pm@lists.linux-foundation.org list. You should cc xen-devel as well. It will be interesting to see what upstream make of the use case. I suspect there might be some common ground with the ability to abort a hibernation attempt on native for example. Ian.> > Thanks, > KAZ > > Signed-off-by: Kenji Wakamiya <wkenji@jp.fujitsu.com> > Signed-off-by: Kazuhiro Suzuki <kaz@jp.fujitsu.com> > > > From: Ian Campbell <Ian.Campbell@eu.citrix.com> > Subject: Re: [Xen-devel] [PATCH] pvops: fix "xm save -c" issue > Date: Fri, 21 Jan 2011 09:14:30 +0000 > > > 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@sisk.pl> and the linux-pm@lists.linux-foundation.org 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@jp.fujitsu.com> > >> Signed-off-by: Kazuhiro Suzuki <kaz@jp.fujitsu.com> > >> > >> > >> From: Kenji Wakamiya <wkenji@jp.fujitsu.com> > >> 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@lists.xensource.com > >> > http://lists.xensource.com/xen-devel > > > >_______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel