Re: Walking an HVM's shadow page tables and other memory management questions.

[Keir Fraser <keir@xensource.com>]

[-- Attachment #1.1: Type: text/plain, Size: 5048 bytes --]

You are barking up the wrong tree by attempting to poke the mapping into a
guest pte. After all, what would you poke? Guest PTEs address the
guest-pseudo-physical space, in which the foreign page is not present.

You actually want to follow ia64¹s lead here. When running in
Œauto-translate¹ mode (i.e., on shadow page tables) then the guest address
for a host mapping should not be interpreted as a virtual address but
instead as a pseudo-physical address.

So you will be mapping a grant reference into the pseudo-physical space and
then a guest PTE can map the appropriate pseudo-physical frame number in the
usual way. The slightly tricky bit is working out how to encode a
grant-mapping in the p2m table. My advice would be to use a page-not-present
encoding (p2m table entries are the same format as page-table entries) as
this then lets you define special encodings of your choice with most of the
remaining bits.

Tim Deegan may be able to give more advice.

 -- Keir

On 2/7/07 21:25, "Roger Cruz" <rcruz@marathontechnologies.com> wrote:

> Hello,
>  
> I¹m new to Xen and especially to the hypervisor code.  I¹m working off a
> 3.0.4.1 base and have the following questions regarding the memory management
> code for an x86, 32-bit platform (capable of supporting PAE).  I¹m doing some
> research into providing grant table hypercall support from a Windows 2003 HVM.
> I have made all the necessary changes to allow the hypercall to make it into
> the hypervisor and execute the correct grant table ops.
>  
> I¹m now testing the GNTTABOP_map_grant_ref with the GNTMAP_host_map and it
> correctly obtains the MFN from the grantor domain.  It then attempts to take
> the HVM host VA address (a windows kernel VA from the non-paged pool) and walk
> the guest¹s page table to obtain the PFN.  I am building the hypervisor by
> simply typing ³make xen² without any other configuration changes from a
> default source installation.
>  
> The first problem I encountered is that it appears the code assumes the guest
> to be in PAE mode.  In particular, guest_walk_tables() in
> xen/arch/x86/mm/shadow/multi.c, line 252 has this code snippet:
>  
> #else /* PAE only... */
>     /* Get l3e from the cache of the guest's top level table */
>     gw->l3e = (guest_l3e_t *)&v->arch.shadow.gl3e[guest_l3_table_offset(va)];
> #endif /* PAE or 64... */
>  
> Which accesses the L3 entries fro the shadow page tables.  When I instrument
> this code, I get l3e to be 0 as shown below (the line #s won¹t match because
> of the instrumentation).
>  
> (XEN) multi.c:236:d1 guest_walk_tables: va: 0x81699000.
> (XEN) multi.c:257:d1 guest_walk_tables: get l3e from cache: 0xff1a6ed0.
> (XEN) multi.c:263:d1 guest_walk_tables: l3e not present: 0x0.
> (XEN) multi.c:574:d1 sh_guest_map_l1e: va:81699000
>  
> If I add the /PAE switch to the boot.ini file, then I can get past this
> problem.  Hence my statement that it appears the hypervisor is assuming guests
> are running with at least PAE mode enable, which may not be the case.  Could
> someone please guide me here?
>  
> The 2nd problem I encountered also has to do with walking the shadow page
> tables to obtain the MFN of the underlying Windows VA address.
> sh_guest_map_l1e(), Line 520 in the same file, has this code executed after it
> walks the guest page tables to obtain the walk_t gw variable.
>  
>     if ( gw.l2e &&
>         (guest_l2e_get_flags(*gw.l2e) & _PAGE_PRESENT) &&
>         !(guest_supports_superpages(v) && (guest_l2e_get_flags(*gw.l2e) &
> _PAGE_PSE)) )
>  
>  
> (XEN) mm.c:2573:d1 grant host mapping: va:81696000 frame:0x15f140
> (XEN) mm.c:2507:d1 grant va mapping: va:81696000
> (XEN) multi.c:236:d1 guest_walk_tables: va: 0x81696000.
> (XEN) multi.c:257:d1 guest_walk_tables: get l3e from cache: 0xff1a6ed0.
> (XEN) multi.c:270:d1 guest_walk_tables: l3e flags: 0x1, pfn:0xe9a
> (XEN) , mfn:0x9e13d<G><1>multi.c:285:d1 hypervisor l2e mapped address
> 0xfec8b058
> (XEN) multi.c:315:d1 large pages. 0x1e3
> (XEN) multi.c:574:d1 sh_guest_map_l1e: va:81696000
> (XEN) multi.c:579:d1 sh_guest_map_l1e: gw.l2e flags:0x1e3, supports large 1
> (XEN) multi.c:596:d1 pl1e :0x0,
> (XEN) mm.c:2512:d1 Could not find L1 PTE for address 81696000
>  
>  
> It looks like it specifically avoids mapping a superpage found in Windows PDE
> into the hypervisor¹s virtual space, which I assume are 4KB-pages.  What
> puzzles me is that for a hypercall to read the arguments from the caller¹s
> guest space, it uses __hvm_copy which calls shadow_gva_to_gfn() to walk the
> guest¹s shadow page tables to get to the underlying MFN. Couldn¹t this code
> here also do the same?
>  
> Thanks in advance for any insight into this area.
>  
>  
> Roger Cruz
> Principal SW Engineer
> Marathon Technologies Corp.
> 978-489-1153
>  
> 
> 
> _______________________________________________
> Xen-devel mailing list
> Xen-devel@lists.xensource.com
> http://lists.xensource.com/xen-devel



[-- Attachment #1.2: Type: text/html, Size: 6382 bytes --]

[-- Attachment #2: Type: text/plain, Size: 138 bytes --]

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