Hi, I''m working off of the 3.1 branch. I am having problems performing an "xm save -c" on an HVM domain. The checkpoint works fine, but the HVM domain is then left in a corrupt state. I know that Brendan Cully had submitted patches that would check to see if the domain was resumable first. Did these patches make it upstream? More basically, I don''t actually understand what deems a domain resumable or not....? Thanks, Mike _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel
xc_domain_resume_any() should be doing just DOMCTL_resumedomain if called on an HVM guest, rather than exiting with an error. Should be easy to fix. -- Keir On 12/9/08 03:29, "Mike Sun" <msun@gatech.edu> wrote:> Hi, > > I''m working off of the 3.1 branch. I am having problems performing an > "xm save -c" on an HVM domain. The checkpoint works fine, but the HVM > domain is then left in a corrupt state. I know that Brendan Cully had > submitted patches that would check to see if the domain was resumable > first. Did these patches make it upstream? More basically, I don''t > actually understand what deems a domain resumable or not....? > > Thanks, > Mike > > _______________________________________________ > 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
Actually it seems to work okay for me with or without PV drivers. xc_domain_resume() was long ago (pre-3.1) fixed to support any HVM guest. -- Keir On 12/9/08 07:10, "Keir Fraser" <keir.fraser@eu.citrix.com> wrote:> xc_domain_resume_any() should be doing just DOMCTL_resumedomain if called on > an HVM guest, rather than exiting with an error. Should be easy to fix. > > -- Keir > > On 12/9/08 03:29, "Mike Sun" <msun@gatech.edu> wrote: > >> Hi, >> >> I''m working off of the 3.1 branch. I am having problems performing an >> "xm save -c" on an HVM domain. The checkpoint works fine, but the HVM >> domain is then left in a corrupt state. I know that Brendan Cully had >> submitted patches that would check to see if the domain was resumable >> first. Did these patches make it upstream? More basically, I don''t >> actually understand what deems a domain resumable or not....? >> >> Thanks, >> Mike >> >> _______________________________________________ >> 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
Sorry if this is a stupid question, but are you saying that all HVM guests are now resumable and there no longer needs to be any check for that as was done by Brendan Cully''s earlier patch requests? If that''s the case, there''s something going on for me. I''ve tried to different HVM guests (a Debian installation and a Damn Small Linux Live CD) and after checkpointing, the guests seem to get lodged in a strange state. I can no longer access the guest''s console via VNC and the state is reported by xend as "------". Any ideas? Thanks! Mike On Fri, Sep 12, 2008 at 6:54 AM, Keir Fraser <keir.fraser@eu.citrix.com> wrote:> Actually it seems to work okay for me with or without PV drivers. > xc_domain_resume() was long ago (pre-3.1) fixed to support any HVM guest. > > -- Keir > > On 12/9/08 07:10, "Keir Fraser" <keir.fraser@eu.citrix.com> wrote: > >> xc_domain_resume_any() should be doing just DOMCTL_resumedomain if called on >> an HVM guest, rather than exiting with an error. Should be easy to fix. >> >> -- Keir >> >> On 12/9/08 03:29, "Mike Sun" <msun@gatech.edu> wrote: >> >>> Hi, >>> >>> I''m working off of the 3.1 branch. I am having problems performing an >>> "xm save -c" on an HVM domain. The checkpoint works fine, but the HVM >>> domain is then left in a corrupt state. I know that Brendan Cully had >>> submitted patches that would check to see if the domain was resumable >>> first. Did these patches make it upstream? More basically, I don''t >>> actually understand what deems a domain resumable or not....? >>> >>> Thanks, >>> Mike >>> >>> _______________________________________________ >>> 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 12/9/08 16:33, "Mike Sun" <msun@gatech.edu> wrote:> Sorry if this is a stupid question, but are you saying that all HVM > guests are now resumable and there no longer needs to be any check for > that as was done by Brendan Cully''s earlier patch requests?Correct. All HVM PV drivers must support suspend cancellation (i.e., resume). And without PV drivers, resume is as simple as just continuing execution of the guest from where it left off!> If that''s the case, there''s something going on for me. I''ve tried to > different HVM guests (a Debian installation and a Damn Small Linux > Live CD) and after checkpointing, the guests seem to get lodged in a > strange state. I can no longer access the guest''s console via VNC and > the state is reported by xend as "------". Any ideas?A weird state. My guess is your qemu-dm is not resumable. It used to consider suspend to be a one-way trip, and kill itself. That''s been fixed quite a long while, but did it work back in 3.1.x? I''m not sure. Anyway, qemu-dm is where I suggest you investigate first. The guest is most likely hanging waiting for work to be done by an unresponsive (or non-existent) qemu_dm process. -- Keir _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel
On Fri, Sep 12, 2008 at 04:42:22PM +0100, Keir Fraser wrote:> On 12/9/08 16:33, "Mike Sun" <msun@gatech.edu> wrote: > > > Sorry if this is a stupid question, but are you saying that all HVM > > guests are now resumable and there no longer needs to be any check for > > that as was done by Brendan Cully''s earlier patch requests? > > Correct. All HVM PV drivers must support suspend cancellation (i.e., > resume). And without PV drivers, resume is as simple as just continuing > execution of the guest from where it left off!Uh, when was this requirement introduced? regards john _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel
On 13/9/08 03:52, "John Levon" <levon@movementarian.org> wrote:> On Fri, Sep 12, 2008 at 04:42:22PM +0100, Keir Fraser wrote: > >> On 12/9/08 16:33, "Mike Sun" <msun@gatech.edu> wrote: >> >>> Sorry if this is a stupid question, but are you saying that all HVM >>> guests are now resumable and there no longer needs to be any check for >>> that as was done by Brendan Cully''s earlier patch requests? >> >> Correct. All HVM PV drivers must support suspend cancellation (i.e., >> resume). And without PV drivers, resume is as simple as just continuing >> execution of the guest from where it left off! > > Uh, when was this requirement introduced?Since guest resume was supported by hypervisor and tools. We''ve never supported resume of HVM guests with ''uncooperative'' PV drivers installed. -- Keir _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel
Thanks Keir. It is the qemu-dm. Hmm, not my dilemma is whether it''d be a fairly easy thing to incorporate the newer qemu-dm into a 3.1.x branch... I''ve made some major changes to the shadow page table code for my work and would rather not try and merge them into 3.2.x if I don''t have to at this point. Mike On Sat, Sep 13, 2008 at 3:09 AM, Keir Fraser <keir.fraser@eu.citrix.com> wrote:> On 13/9/08 03:52, "John Levon" <levon@movementarian.org> wrote: > >> On Fri, Sep 12, 2008 at 04:42:22PM +0100, Keir Fraser wrote: >> >>> On 12/9/08 16:33, "Mike Sun" <msun@gatech.edu> wrote: >>> >>>> Sorry if this is a stupid question, but are you saying that all HVM >>>> guests are now resumable and there no longer needs to be any check for >>>> that as was done by Brendan Cully''s earlier patch requests? >>> >>> Correct. All HVM PV drivers must support suspend cancellation (i.e., >>> resume). And without PV drivers, resume is as simple as just continuing >>> execution of the guest from where it left off! >> >> Uh, when was this requirement introduced? > > Since guest resume was supported by hypervisor and tools. We''ve never > supported resume of HVM guests with ''uncooperative'' PV drivers installed. > > -- Keir > > >_______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel
qemu-dm should be quite portable. -- Keir On 16/9/08 20:30, "Mike Sun" <msun@gatech.edu> wrote:> Thanks Keir. It is the qemu-dm. Hmm, not my dilemma is whether it''d > be a fairly easy thing to incorporate the newer qemu-dm into a 3.1.x > branch... I''ve made some major changes to the shadow page table code > for my work and would rather not try and merge them into 3.2.x if I > don''t have to at this point. > > Mike > > On Sat, Sep 13, 2008 at 3:09 AM, Keir Fraser <keir.fraser@eu.citrix.com> > wrote: >> On 13/9/08 03:52, "John Levon" <levon@movementarian.org> wrote: >> >>> On Fri, Sep 12, 2008 at 04:42:22PM +0100, Keir Fraser wrote: >>> >>>> On 12/9/08 16:33, "Mike Sun" <msun@gatech.edu> wrote: >>>> >>>>> Sorry if this is a stupid question, but are you saying that all HVM >>>>> guests are now resumable and there no longer needs to be any check for >>>>> that as was done by Brendan Cully''s earlier patch requests? >>>> >>>> Correct. All HVM PV drivers must support suspend cancellation (i.e., >>>> resume). And without PV drivers, resume is as simple as just continuing >>>> execution of the guest from where it left off! >>> >>> Uh, when was this requirement introduced? >> >> Since guest resume was supported by hypervisor and tools. We''ve never >> supported resume of HVM guests with ''uncooperative'' PV drivers installed. >> >> -- Keir >> >> >>_______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel
Hmm... I attempted to replace the tools/ioemu source in 3.1.4 with
that from 3.2.1... and find this call in cirrus_vga.c is not supported
in 3.1.x:
(void)xc_domain_pin_memory_cacheattr(
xc_handle, domid,
begin >> TARGET_PAGE_BITS,
end >> TARGET_PAGE_BITS,
XEN_DOMCTL_MEM_CACHEATTR_WB);
I looked into patching 3.1.x with the code necessary to support that
function call, but found myself down a long list of dependencies that
required updating things like mtrr and mm.c which seemed a bit
dangerous.
I figured I''d just remove that memory cache pin call in cirrus_vga.c
and see how that went. (The only other slight change I had to make
was to remove the z position stuff from xenfb.c). Everything build,
but I can''t create HVM domains without them getting wedged in a
"weird" state (i.e. -----), so it looks like qemu-dm is bugging out.
Any ideas on how I can port the 0.90 version of QEMU in Xen 3.2.x into
Xen 3.1.x easily?
Thanks,
Mike
On Tue, Sep 16, 2008 at 5:05 PM, Keir Fraser <keir.fraser@eu.citrix.com>
wrote:> qemu-dm should be quite portable.
>
> -- Keir
>
> On 16/9/08 20:30, "Mike Sun" <msun@gatech.edu> wrote:
>
>> Thanks Keir. It is the qemu-dm. Hmm, not my dilemma is whether
it''d
>> be a fairly easy thing to incorporate the newer qemu-dm into a 3.1.x
>> branch... I''ve made some major changes to the shadow page
table code
>> for my work and would rather not try and merge them into 3.2.x if I
>> don''t have to at this point.
>>
>> Mike
>>
>> On Sat, Sep 13, 2008 at 3:09 AM, Keir Fraser
<keir.fraser@eu.citrix.com>
>> wrote:
>>> On 13/9/08 03:52, "John Levon"
<levon@movementarian.org> wrote:
>>>
>>>> On Fri, Sep 12, 2008 at 04:42:22PM +0100, Keir Fraser wrote:
>>>>
>>>>> On 12/9/08 16:33, "Mike Sun"
<msun@gatech.edu> wrote:
>>>>>
>>>>>> Sorry if this is a stupid question, but are you saying
that all HVM
>>>>>> guests are now resumable and there no longer needs to
be any check for
>>>>>> that as was done by Brendan Cully''s earlier
patch requests?
>>>>>
>>>>> Correct. All HVM PV drivers must support suspend
cancellation (i.e.,
>>>>> resume). And without PV drivers, resume is as simple as
just continuing
>>>>> execution of the guest from where it left off!
>>>>
>>>> Uh, when was this requirement introduced?
>>>
>>> Since guest resume was supported by hypervisor and tools.
We''ve never
>>> supported resume of HVM guests with
''uncooperative'' PV drivers installed.
>>>
>>> -- Keir
>>>
>>>
>>>
>
>
>
_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel
On 19/9/08 00:12, "Mike Sun" <msun@gatech.edu> wrote:> Hmm... I attempted to replace the tools/ioemu source in 3.1.4 with > that from 3.2.1... and find this call in cirrus_vga.c is not supported > in 3.1.x: > > (void)xc_domain_pin_memory_cacheattr( > xc_handle, domid, > begin >> TARGET_PAGE_BITS, > end >> TARGET_PAGE_BITS, > XEN_DOMCTL_MEM_CACHEATTR_WB); > > I looked into patching 3.1.x with the code necessary to support that > function call, but found myself down a long list of dependencies that > required updating things like mtrr and mm.c which seemed a bit > dangerous.You don''t need that call. It''s related to real device passthrough (e.g., Intel VT-d).> I figured I''d just remove that memory cache pin call in cirrus_vga.c > and see how that went. (The only other slight change I had to make > was to remove the z position stuff from xenfb.c). Everything build, > but I can''t create HVM domains without them getting wedged in a > "weird" state (i.e. -----), so it looks like qemu-dm is bugging out. > > Any ideas on how I can port the 0.90 version of QEMU in Xen 3.2.x into > Xen 3.1.x easily?Mmm not really. Actually I''m surprised it built at all without further changes to the source code. Perhaps you''d be better cherry-picking 3.2.x patches to backport to the 3.1.x qemu. Changesets 15639 and 15641 would be obvious candidates. -- Keir _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel