Xen devel - Nov 2006 - xc_vcpu_setcontext problem with translated shadow page table domains

Hi,
I''m working on save/restore for (non hvm) domains with the
auto_translated_physmap feature enabled.  I''ve based my code roughly
off of a patch to provide save/restore support for HVM domains, but
I''m running into problems when I try to restore a domain.

My call to xc_vcpu_setcontext() is failing during restoration -- is
there anything unusual about context structs for these types of
domains?

In my save function I write to disk the value returned from
xc_vcpu_getcontext(), which I then read back in during my restore
function and pass to xc_vcpu_setcontext().  Can someone think of a
reason why this would fail?

thanks for any ideas,
-Tim

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

> I''m working on save/restore for (non hvm) domains with the
> auto_translated_physmap feature enabled.  I''ve based my code
roughly
> off of a patch to provide save/restore support for HVM domains, but
> I''m running into problems when I try to restore a domain.
> 
> My call to xc_vcpu_setcontext() is failing during restoration -- is
> there anything unusual about context structs for these types of
> domains?
> 
> In my save function I write to disk the value returned from
> xc_vcpu_getcontext(), which I then read back in during my restore
> function and pass to xc_vcpu_setcontext().  Can someone think of a
> reason why this would fail?
Are you getting the restore domain into the right shadow pagetable mode?


Otherwise things like the pagetable base will be invalid (you don''t
need
to canonical-ize it on save as its already in gpfn form).

Ian



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

On 11/20/06, Ian Pratt <m+Ian.Pratt@cl.cam.ac.uk>
wrote:
>
> > I''m working on save/restore for (non hvm) domains with the
> > auto_translated_physmap feature enabled.  I''ve based my code
roughly
> > off of a patch to provide save/restore support for HVM domains, but
> > I''m running into problems when I try to restore a domain.
> >
> > My call to xc_vcpu_setcontext() is failing during restoration -- is
> > there anything unusual about context structs for these types of
> > domains?
>
> Are you getting the restore domain into the right shadow pagetable mode?
>
I can see that when I restore the domain it is aware that the
"auto_translated_physmap" feature is being used, so I am assuming that
will result in the selection of the correct shadow page table mode.
I''ll try to look and see whether that is actually happening.
>
> Otherwise things like the pagetable base will be invalid (you
don''t need
> to canonical-ize it on save as its already in gpfn form).
>
> Ian
>
>
>
Right -- I''m just copying the page table/memory contents directly
without canonicalizing (a nice benefit of using shadows!).

Thanks
- Tim

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

On 11/20/06, Tim Wood <twwood@gmail.com> wrote:
> On 11/20/06, Ian Pratt <m+Ian.Pratt@cl.cam.ac.uk> wrote:
> >
> > > I''m working on save/restore for (non hvm) domains with
the
> > > auto_translated_physmap feature enabled.  I''ve based my
code roughly
> > > off of a patch to provide save/restore support for HVM domains,
but
> > > I''m running into problems when I try to restore a
domain.
> > >
> > > My call to xc_vcpu_setcontext() is failing during restoration --
is
> > > there anything unusual about context structs for these types of
> > > domains?
> >
> > Are you getting the restore domain into the right shadow pagetable
mode?
> >
>
> I can see that when I restore the domain it is aware that the
> "auto_translated_physmap" feature is being used, so I am assuming
that
> will result in the selection of the correct shadow page table mode.
> I''ll try to look and see whether that is actually happening.
You are right (as usual) -- the restored domains return false for
shadow_mode_translate() so they are not using shadow mode like they
should.  As a result the set_gdt function is dying since gmfn_to_mfn()
returns bad values.  Any pointers to where this mode is typically
enabled on domain startup?

The output from the restore function in libxc shows that when it reads
in the configuration file from the saved location it knows that the
auto_translated_physmap feature is enabled for the domain, but I guess
it is not acting on that to correctly enable shadow mode.

thanks
-Tim

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

> > I can see that when I restore the domain it is aware that the
> > "auto_translated_physmap" feature is being used, so I am
assuming
that
> > will result in the selection of the correct shadow page table mode.
> > I''ll try to look and see whether that is actually happening.
> 
> You are right (as usual) -- the restored domains return false for
> shadow_mode_translate() so they are not using shadow mode like they
> should.  As a result the set_gdt function is dying since gmfn_to_mfn()
> returns bad values.  Any pointers to where this mode is typically
> enabled on domain startup?
See the following code in xc_linux_build.c :

963         if ( xc_shadow_control(xc_handle, dom,
964
XEN_DOMCTL_SHADOW_OP_ENABLE_TRANSLATE,
965                                NULL, 0, NULL, 0, NULL) < 0 )
966         {
967             PERROR("Could not enable translation mode");
968             goto error_out;
969         }

 
Ian
> The output from the restore function in libxc shows that when it reads
> in the configuration file from the saved location it knows that the
> auto_translated_physmap feature is enabled for the domain, but I guess
> it is not acting on that to correctly enable shadow mode.
> 
> thanks
> -Tim
_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel