Xen project Mailing List

Re: [Xen-devel] pvops: Does PVOPS guest os support online "suspend/resume"

On Mon, Aug 12, 2013 at 10:19 AM, Gonglei (Arei) <arei.gonglei@xxxxxxxxxx> wrote:

> > Thanks for responding. We've tried kernel "3.5.0-17 generic" (ubuntu 12.10),
> the problem still exists.
>
> So you have not tried v3.10. v3.5 is ancient from the upstream perspective.
>

thank you, I didn't notice that, I would try 3.10 later.

3.5 may be ancient compared to 3.10 but from the suspend/resume support perspective,

I think things were fixed way back in 3.0 series.

yes, the purpose of using "-c" here is to do a "ONLINE" suspend/resume. such problem just occurs with ONLINE suspend/resume,
rather than OFFLINE suspend/resume. To be precisely, 2 examples are listed here below:
<1>
1) xl create dom1.cfg
2) xl save -c dom1 /opt/dom1.save
after this, the dom1 guest os has its io stucked. which means ONLINE suspend/resume has something wrong.
3) xl destroy dom1
4) xl restore /opt/dom1.save
the restored dom1 works fine, which means OFFLINE suspend/resume is OK.

I am a bit lost here. Didnt we fix suspend/resume issues in the 3.0 release window.

I tested it with both xm and xl save (with/without -c option). That was also when I fixed

some bugs in "xl save -c" code and introduced a minimal xl remus implementation (which is a continuous xl save -c).

And we had blkfront et. al at that time too.

Did the distros miss some kernel config (iirc it was HIBERNATE_CALLBACKS) ?

So, did something fundamental change between 3.0 to 3.5, causing the "regression" that

Gonglei is seeing ?

<2>
1) xl create dom1.cfg
2) xl save dom1 /opt/dom1.save
no "-c" here, it would destroy the guest dom1 automatically.
3) xl restore /opt/dom1.save
the restored dom1 works fine, which means OFFLINE suspend/resume is OK.

This one always worked.. even with stock 2.6 kernels.

shriram

_______________________________________________ Xen-devel mailing list Xen-devel@xxxxxxxxxxxxx http://lists.xen.org/xen-devel