From: Ian Campbell <Ian.Campbell@citrix.com>
To: Shriram Rajagopalan <rshriram@cs.ubc.ca>
Cc: "brendan@cs.ubc.ca" <brendan@cs.ubc.ca>,
"xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>,
Ian Jackson <Ian.Jackson@eu.citrix.com>,
Stefano Stabellini <Stefano.Stabellini@eu.citrix.com>
Subject: Re: [PATCH 4 of 6 V3] libxl: support suspend_cancel in domain_resume
Date: Thu, 9 Feb 2012 19:56:12 +0000 [thread overview]
Message-ID: <1328817372.13189.93.camel@dagon.hellion.org.uk> (raw)
In-Reply-To: <A131904C-EB20-43F7-B31F-0916E9FFF91D@cs.ubc.ca>
On Thu, 2012-02-09 at 18:21 +0000, Shriram Rajagopalan wrote:
> On 2012-02-09, at 1:16 AM, Ian Campbell <Ian.Campbell@citrix.com> wrote:
>
> > On Fri, 2012-02-03 at 06:50 +0000, rshriram@cs.ubc.ca wrote:
> >> #
> >
> > Previously this code would have been equivalent to passing 0 not 1. It
> > may be ok to change this but it should be separate.
>
> > However I'm a bit
> > dubious about changing it without adding some code to detect if the
> > guest supports it.
>
> It requires writing the suspend-cancel entry to xenstore on domain creation (if xen says that the guest supports it)
>
> And then read this field once during initialization in checkpoint/Remus code.
>
> I haven't properly investigated the domain create code path. Any pointers on where I should start ?
>
> > (I know libxl_domain_resume is currently broken for
> > the non-cooperative suspend
>
> It's broken in such a way that neither domain checkpoint or Remus work.
> I ll take up your comment on the previous version of the patch:
> Add a new public (or internal) API
> libxl_domain_suspend_cancel
>
> and make the checkpoint and Remus related code call this instead of the domain_resume.
I don't think there is any need for that unless you think that is
actually a better API in its own right. Otherwise please just leave the
semantics of the existing calls to libxl_domain_resume alone when you
add the flag (i.e. pass 0 as the co-operative flag at all existing call
sites, retaining the existing behaviour). Other than that your patch was
fine.
Changing existing places to use co-operative resume without also
validating that the guest supports it is wrong in the normal migration
case and also masks a real bug in libxl_domain_resume which needs to be
fixed (it's on my TODO list) not papered over by assuming that all
guests know about cooperative resume.
If you need to make that argument conditional on Remus in subsequent
patches then that is fine since Remus implies, at least to some degree,
support for co-operative resume.
Ian.
>
> Later, after adding the suspend-cancel xenstore entry creation patch, I can switch the code to using the above function with the cooperative flag.
>
> > case but we shouldn't paper over that)
> >
> > Ian.
> >
> >
next prev parent reply other threads:[~2012-02-09 19:56 UTC|newest]
Thread overview: 22+ messages / expand[flat|nested] mbox.gz Atom feed top
2012-02-03 6:49 [PATCH 0 of 6 V3] libxl: refactor suspend/resume code rshriram
2012-02-03 6:49 ` [PATCH 1 of 6 V3] libxl: helper function to send commands to traditional qemu rshriram
2012-02-03 6:49 ` [PATCH 2 of 6 V3] libxl: bugfix: create_domain() return to caller if !daemonize rshriram
2012-02-03 6:49 ` [PATCH 3 of 6 V3] libxl: QMP stop/resume & refactor QEMU suspend/resume/save rshriram
2012-02-09 9:13 ` Ian Campbell
2012-02-03 6:50 ` [PATCH 4 of 6 V3] libxl: support suspend_cancel in domain_resume rshriram
2012-02-09 9:16 ` Ian Campbell
2012-02-09 9:20 ` Ian Campbell
2012-02-09 18:21 ` Shriram Rajagopalan
2012-02-09 19:56 ` Ian Campbell [this message]
2012-02-10 1:31 ` [PATCH 4 of 6 V4] " rshriram
2012-02-10 9:00 ` Ian Campbell
2012-02-20 19:00 ` Ian Jackson
2012-02-20 20:02 ` Shriram Rajagopalan
2012-02-20 22:26 ` Shriram Rajagopalan
2012-02-21 10:13 ` Stefano Stabellini
2012-02-21 10:12 ` Stefano Stabellini
2012-02-21 12:21 ` Ian Jackson
2012-02-03 6:50 ` [PATCH 5 of 6 V3] libxl: refactor migrate_domain and generalize migrate_receive rshriram
2012-02-09 9:17 ` Ian Campbell
2012-02-03 6:50 ` [PATCH 6 of 6 V3] libxl: resume instead of unpause on xl save -c rshriram
2012-02-09 9:18 ` 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=1328817372.13189.93.camel@dagon.hellion.org.uk \
--to=ian.campbell@citrix.com \
--cc=Ian.Jackson@eu.citrix.com \
--cc=Stefano.Stabellini@eu.citrix.com \
--cc=brendan@cs.ubc.ca \
--cc=rshriram@cs.ubc.ca \
--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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).