Re: [Xen-devel] Walking an HVM's shadow page tables and other memory management questions.

[Keir Fraser <keir@xxxxxxxxxxxxx>]

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@xxxxxxxxxxxxxxxxxxxxxxxx> 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@xxxxxxxxxxxxxxxxxxx
http://lists.xensource.com/xen-devel

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