Xen devel - Nov 2006 - Does Xen in 64 bit mode support shadow page table mode?

Folks --

I''m trying to experiment with running a 64 bit paravirtualized guest  
in shadow page table mode, and I''m getting an error while pinning the  
page table.

The call to pin the pages is in xc_linux_build.c:

static int setup_guest(int xc_handle, ...

#if defined(__x86_64__)
     /*
      * Pin down l4tab addr as page dir page - causes hypervisor to   
provide
      * correct protection for the page
      */
     if ( pin_table(xc_handle, MMUEXT_PIN_L4_TABLE,
                    xen_cr3_to_pfn(ctxt->ctrlreg[3]), dom) )
         goto error_out;
#endif

...

And Xen coughs up:

(XEN) (file=/home/sai/xen-unstable/xen/include/asm/mm.h, line=266)  
Error pfn 50d: rd=ffff830000fdf080, od=0000000000000000,  
caf=00000000, taf=0000000000000000
(XEN) DOM0: (file=mm.c, line=483) Could not get page ref for pfn 50d
(XEN) DOM0: (file=mm.c, line=2052) Error while pinning mfn 50d

My Xen version is:

  Xen version 3.0-unstable (root@lab.netapp.com) (gcc version 4.0.3  
(Ubuntu 4.0.3-1ubuntu5)) Thu Nov  2 10:37:27 P
ST 2006
Latest ChangeSet: Sun Sep 10 17:55:03 2006 +0100 11440:bfd00b317815

(XEN) Command line: /xen-3.gz dom0_mem=716800 com1=9600,8n1 cdb=com1  
console=com1
(XEN) Physical RAM map:

My debugging session looks like:

Breakpoint 9, setup_guest (xc_handle=8, dom=20, image=0x806150  
"\177ELF\002\001\001", image_size=19277,
     initrd=0x42801700, nr_pages=2560, pvsi=0x0, pvke=0x0, pvss=0x0,  
ctxt=0x42800130, cmdline=0x2b653d609054 "",
     shared_info_frame=4052, flags=0, store_evtchn=0,  
store_mfn=0x428017a8, console_evtchn=0,
     console_mfn=0x428017a0, required_features=0x42800110) at  
xc_linux_build.c:921
921         if ( pin_table(xc_handle, MMUEXT_PIN_L4_TABLE,
(gdb) p xc_handle
$39 = 8
(gdb) l
916     #if defined(__x86_64__)
917         /*
918          * Pin down l4tab addr as page dir page - causes  
hypervisor to  provide
919          * correct protection for the page
920          */
921         if ( pin_table(xc_handle, MMUEXT_PIN_L4_TABLE,
922                        xen_cr3_to_pfn(ctxt->ctrlreg[3]), dom) )
923             goto error_out;
924     #endif
925
(gdb) p/x ctxt->ctrlreg
$40 = {0x0, 0x0, 0x0, 0x50d000, 0x0, 0x0, 0x0, 0x0}
(gdb) p/x dsi
$41 = {v_start = 0x0, v_end = 0x503c88, v_kernstart = 0x400000,  
v_kernend = 0x503c88, v_kernentry = 0x4000e8,
   elf_paddr_offset = 0x0, pae_kernel = 0x0, load_symtab = 0x0,  
symtab_addr = 0x0, symtab_len = 0x0,
   __elfnote_section = 0x0, __elfnote_section_end = 0x0,  
__xen_guest_string = 0x80a3be}
(gdb) p dsi.__xen_guest_string
$42 = 0x80a3be "LOADER=generic,GUEST_OS=your-favorite- 
os,GUEST_VER=0.1,XEN_VER=xen-3.0,BSD_SYMTAB,FEATURES=! 
writable_page_tables|!auto_translated_physmap,PAE=no"
(gdb) l xen_cr3_to_pfn
Function "xen_cr3_to_pfn" not defined.
(gdb) s
pin_table (xc_handle=8, type=3, mfn=1293, dom=20) at xg_private.c:127
127         op.cmd = type;
(gdb)

I''m a little concerned about v_start being 0.  I don''t know
how to
influence that in the link stage.  But, it should work as it stands,  
I would imagine.

Anything obvious jump out at any of you?

-- Randy

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

Randy Thelen wrote:
> Folks --
>
> I''m trying to experiment with running a 64 bit paravirtualized  
> guest in shadow page table mode, and I''m getting an error while  
> pinning the page table.
>
> The call to pin the pages is in xc_linux_build.c:
>
> static int setup_guest(int xc_handle, ...
>
> #if defined(__x86_64__)
>     /*
>      * Pin down l4tab addr as page dir page - causes hypervisor to   
> provide
>      * correct protection for the page
>      */
>     if ( pin_table(xc_handle, MMUEXT_PIN_L4_TABLE,
>                    xen_cr3_to_pfn(ctxt->ctrlreg[3]), dom) )
>         goto error_out;
> #endif
Incidentally, if I comment out this line from my start.S file:

//      .ascii ",FEATURES=!writable_page_tables|! 
auto_translated_physmap"

Then the pin_table() call, above, works just fine and the guest  
domain is created.

Does that help narrow down the problem?

-- Randy

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

On 13/11/06 9:12 pm, "Randy Thelen" <rthelen@netapp.com> wrote:
> I''m trying to experiment with running a 64 bit paravirtualized
guest
> in shadow page table mode, and I''m getting an error while pinning
the
> page table.
> 
> The call to pin the pages is in xc_linux_build.c:
If building an auto-translated guest, Xen expects the pin request to specify
a guest pseudo-physical address.

The bug went away when you removed the auto-translation feature from the
guest kernel header because that will have overridden your request for
auto-translate mode (most likely) and you''re not running on shadow
pagetables at all.

 -- Keir



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

On 13/11/06 9:12 pm, "Randy Thelen" <rthelen@netapp.com> wrote:
> I''m trying to experiment with running a 64 bit paravirtualized
guest
> in shadow page table mode, and I''m getting an error while pinning
the
> page table.
>
> The call to pin the pages is in xc_linux_build.c:
On Nov 14, 2006, at 12:20 AM, Keir Fraser wrote:
> If building an auto-translated guest, Xen expects the pin request  
> to specify
> a guest pseudo-physical address.
>
> The bug went away when you removed the auto-translation feature  
> from the
> guest kernel header because that will have overridden your request for
> auto-translate mode (most likely) and you''re not running on shadow
> pagetables at all.
Do you think this problem is caused by the bad dsi.v_start that I''ve  
got for my kernel image?

That doesn''t make a lot of sense to me because the pfn()
shouldn''t
care about the virtual addresses of my kernel.

-- Randy

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

On 14/11/06 08:46, "Randy Thelen" <rthelen@netapp.com> wrote:
> Do you think this problem is caused by the bad dsi.v_start that
I''ve
> got for my kernel image?
> 
> That doesn''t make a lot of sense to me because the pfn()
shouldn''t
> care about the virtual addresses of my kernel.
If there''s a v_start problem it is quite separate. I am only talking
about
the failure of the L4 pin request. This is occurring because you should pass
the PFN not the MFN.

 -- Keir



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

Keir Fraser wrote:
> If there''s a v_start problem it is quite separate. I am only  
> talking about
> the failure of the L4 pin request. This is occurring because you  
> should pass
> the PFN not the MFN.
Damn.  The problem occurs in Xend, not my code.  This implies there''s  
a bug in the libxc code, which is where the actual pin call is issued.

-- Randy

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

On 14/11/06 09:59, "Randy Thelen" <rthelen@netapp.com> wrote:
>> If there''s a v_start problem it is quite separate. I am only
>> talking about
>> the failure of the L4 pin request. This is occurring because you
>> should pass
>> the PFN not the MFN.
> 
> Damn.  The problem occurs in Xend, not my code.  This implies
there''s
> a bug in the libxc code, which is where the actual pin call is issued.
Auto-translate is really not supported that well on x86. So far noone''s
used
it for anything apart from research projects.

 -- Keir



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