| |
|
 |
|
 |
|
|
|
| |
|
|
xen-devel
Re: [Xen-devel] PAE guest address maps?
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
|
|
|
| |
|
Home