Re: [Xen-devel] PAE guest address maps?

[Randy Thelen <rthelen@xxxxxxxxxx>]

Randy Thelen wrote:

> Randy Thelen wrote:
>
> > Folks --
> >
> > I'm looking through a PAE guest's address map and I'm trying to  
> > make sense out of it.  Is there some documentation about these  
> > address regions:
> I meant to annotate the following table a bit more:
>
> > 0xc0000000 - 0xc0800000: 8MB    <-- My kernel
> > 0xfde00000 - 0xfde04000: 16KB   <-- pfn to mfn ptes
> > 0xfdfac000 - 0xfdfae000: 8KB    NOT READABLE
> > 0xfdfb4000 - 0xfdfc0000: 48KB   NOT READABLE
> > 0xfdfe4000 - 0xfdfe6000: 8KB    NOT READABLE
> > 0xfdfec000 - 0xfdff0000: 16KB   <-- ???
> > 0xfdff4000 - 0xfe000000: 48KB   NOT READABLE
Alright, I now believe that in a PAE guest (with a PAE Xen, i.e.,  
we're using real MMU tables), the recursive virtual mapping base  
address is 0xFD80_0000.  And, the basic virtual address to virtual  
address of the PTE is: 0xFD80_0000 | (VA & 0xFFFF_F000) >> 0.
There's a large drawing on the white board behind me to explain  
this.  I apologize for not actually carrying it into words in this  
email, but my wife and child are at home, hungry, waiting for me so  
we can eat dinner.  I'll elaborate on the mechanics of the above  
function at a later date.
It took me a while, but I was able to perform a series of  
transactions that properly mapped virtual addresses to the Page Table  
Entries that map them.
If you're interested, follow this:

First, I modified Xend (privately) to always allocate 4 L2 page  
tables.  I now believe I can revert that (local) change.  At any  
rate, in Xend when I'm allocating page table pages, I create an L3  
page and four L2 pages, consecutively:
(gdb) x/4x xen_start_info->pt_base
0xc03bb000:     0x00000000fb045001      0x00000000fb044001
0xc03bb010:     0x00000000fb043001      0x00000000fb042001
(gdb) x/8x 0xc03bc000
0xc03bc000:     0x0000000000000000      0x0000000000000000
0xc03bc010:     0x0000000000000000      0x0000000000000000
0xc03bc020:     0x0000000000000000      0x0000000000000000
0xc03bc030:     0x0000000000000000      0x0000000000000000
(gdb) x/8x 0xc03bd000
0xc03bd000:     0x0000000000000000      0x0000000000000000
0xc03bd010:     0x0000000000000000      0x0000000000000000
0xc03bd020:     0x0000000000000000      0x0000000000000000
0xc03bd030:     0x0000000000000000      0x0000000000000000
(gdb) x/8x 0xc03be000
0xc03be000:     0x0000000000000000      0x0000000000000000
0xc03be010:     0x0000000000000000      0x0000000000000000
0xc03be020:     0x0000000000000000      0x0000000000000000
0xc03be030:     0x0000000000000000      0x0000000000000000
(gdb) x/8x 0xc03bf000
0xc03bf000:     0x00000000fb041067      0x00000000fb040067
0xc03bf010:     0x00000000fb03f067      0x00000000fb03e067
0xc03bf020:     0x0000000000000000      0x0000000000000000
0xc03bf030:     0x0000000000000000      0x0000000000000000

At address 0xc03bb000 you see the four mappings for the four L2 page  
tables.
At address 0xc03bc000 .. 0xc03befff you (almost) see three pages of  
zeros.  There are no valid virtual addresses below 0xC000_0000.
My kernel is virtually mapped at address 0xC000_0000 and consume 8MB,  
resulting in four L1 pages of page table entries.
Fine.  Now, let's see if we can find the PTE that maps the virtual  
address (0xC03BF000) for the L0 page of interest.
In other words, address 0xC03BF000 is the virtual address of a Level  
0 block (a data block).  We can find the PTE which maps that block by  
applying the above algorithm on the virtual address.
You know, I'm not sure you all want this level of detail.  I'm going  
home for dinner.
-- Randy

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