All of lore.kernel.org
 help / color / mirror / Atom feed
From: Kenji Wakamiya <wkenji@jp.fujitsu.com>
To: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>,
	Ian Campbell <Ian.Campbell@citrix.com>
Subject: Re: [PATCH] pvops: fix "xm save -c" issue
Date: Fri, 21 Jan 2011 14:35:09 +0900	[thread overview]
Message-ID: <4D391B0D.8010708@jp.fujitsu.com> (raw)
In-Reply-To: <20110110170141.GA29764@dumpdata.com>

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

  reply	other threads:[~2011-01-21  5:35 UTC|newest]

Thread overview: 12+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2010-12-14  5:31 [PATCH] pvops: fix "xm save -c" issue Kenji Wakamiya
2010-12-14 14:59 ` Konrad Rzeszutek Wilk
2010-12-15  4:18   ` Kenji Wakamiya
2010-12-15 15:40     ` Konrad Rzeszutek Wilk
2010-12-16  5:49       ` Kenji Wakamiya
2010-12-17  9:43         ` Ian Campbell
2011-01-10 17:01           ` Konrad Rzeszutek Wilk
2011-01-21  5:35             ` Kenji Wakamiya [this message]
2011-01-21  6:28               ` SUZUKI, Kazuhiro
2011-01-21  9:14                 ` Ian Campbell
2011-01-25  7:23                   ` SUZUKI, Kazuhiro
2011-01-25 16:32                     ` Ian Campbell

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=4D391B0D.8010708@jp.fujitsu.com \
    --to=wkenji@jp.fujitsu.com \
    --cc=Ian.Campbell@citrix.com \
    --cc=konrad.wilk@oracle.com \
    --cc=xen-devel@lists.xensource.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.