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
