WARNING - OLD ARCHIVES

This is an archived copy of the Xen.org mailing list, which we have preserved to ensure that existing links to archives are not broken. The live archive, which contains the latest emails, can be found at http://lists.xen.org/
   
 
 
Xen 
 
Home Products Support Community News
 
   
 

xen-devel

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

To: Konrad Rzeszutek Wilk <konrad.wilk@xxxxxxxxxx>
Subject: Re: [Xen-devel] [PATCH] pvops: fix "xm save -c" issue
From: Kenji Wakamiya <wkenji@xxxxxxxxxxxxxx>
Date: Fri, 21 Jan 2011 14:35:09 +0900
Cc: "xen-devel@xxxxxxxxxxxxxxxxxxx" <xen-devel@xxxxxxxxxxxxxxxxxxx>, Ian Campbell <Ian.Campbell@xxxxxxxxxx>
Delivery-date: Thu, 20 Jan 2011 21:36:15 -0800
Envelope-to: www-data@xxxxxxxxxxxxxxxxxxx
In-reply-to: <20110110170141.GA29764@xxxxxxxxxxxx>
List-help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-id: Xen developer discussion <xen-devel.lists.xensource.com>
List-post: <mailto:xen-devel@lists.xensource.com>
List-subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
List-unsubscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
References: <4D070138.7090708@xxxxxxxxxxxxxx> <20101214145925.GA5769@xxxxxxxxxxxx> <4D08417E.7060104@xxxxxxxxxxxxxx> <20101215154021.GB28984@xxxxxxxxxxxx> <4D09A882.5070504@xxxxxxxxxxxxxx> <1292578996.32368.11510.camel@xxxxxxxxxxxxxxxxxxxxxx> <20110110170141.GA29764@xxxxxxxxxxxx>
Sender: xen-devel-bounces@xxxxxxxxxxxxxxxxxxx
User-agent: Mozilla/5.0 (Windows; U; Windows NT 6.1; ja; rv:1.9.2.13) Gecko/20101207 Lightning/1.0b2 Thunderbird/3.1.7
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