[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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



Lists.xenproject.org is hosted with RackSpace, monitoring our
servers 24x7x365 and backed by RackSpace's Fanatical Support®.