Paging

[Pype.Clicker]

just for the sake of completeness ... could you quickly explain (or provide a link to) what are GDT trick (i think i have an idea of what it could be) and pointer mangling (not the smallest idea for that one) techniques ?

thanks in advance

[shad]

So the virtual address of any page table is (1023 << 22) OR'd with the physical address of the page?

[Pype.Clicker]

So the virtual address of any page table is (1023 << 22) OR'd with the physical address of the page?

i don't really see what you're talkin' about but if this is about the self-mapping, it is more like
pageTable.virtual == (1023<<22) | (pageTable.index_in_directory << 12)

[shad]

Yah.. isnt that the same thing? If the table is page aligned then its address is the same as its index << 12

[Pype.Clicker]

err ... i don't feel so ...

Let's say you have virtual address 0x12345678 (ooh. How original am i ).

you know its page is the one that handles 0x12345000 ... 0x12345xxx. Its page table is the one that collects pages 0x12000000 .. 0x123fffff, thus it has index 0x12000000 >> 22 in the page directory, but the *physical* address of that page table depends on the directory content ... It might be mapped anywhere in the physical memory, say at 0x00201000. You just don't care as you know you can access your page table from 0xffd20000 .. 0xffd20fff


[attachment deleted by admin]

[shad]

ok.. so.. to find its index in the directory you take the virtual address of the pages that this table accesses, and shift right 12 bits, then and it approprately ? (& 0x3ff)

[Pype.Clicker]

not really ...

Code: Select all

   struct pgEntry {
      unsigned present : 1;
      unsigned flags:11;
      unsigned frame:20;
    } __attribute__((packed));

   struct pgEntry *pgDirectory=(struct pgEntry*) 0xFFFFF000;
   struct pgEntry *pgTables=(struct pgEntry*) 0xFFC00000;

All the content of the virtual memory starting from tables[] are defined by the content of directory[]. It uses the last 4MB of your virtual address space. if pgDirectory.present==0, then pgTables[i*1024 .. ((i+1)*1024)-1] are not valid addresses.

if you want to access page directory entry related to address X, you'll use PDE=pgDirectory[X>>22]: the last 10 bits are the entry index in the directory (see Intel manuals) and C will gracefully replace this by

Code: Select all

    mov ebx,[pgDirectory]
    mov esi, <X>
    shr esi,22
    mov eax,[ebx+esi*4]
    mov <PTE>,eax

Say X=0x12345678, the PDE is at FFFFF000|((0x12345678>>22)*4) == FFFFF480, which is translated by the MMU as:
PDE[3FF](uses the page directory as page table)->PTE[3FF](use the page directory as the page) ->offset[480..483]

If you want to access the page table entry for address X, you should first read the page directory entry and check its present bit is 1, at least if you're in a page fault handler. If not, you might try to read an invalid page table, which would result in weird error conditions (including Exception loop)

As we are sure page tables are contiguous in the pgTables[...] structure, we don't have to do the PDE lookup to know where the page table actually is: it is immediate

Code: Select all

PTE=pgTables[X>>12];
/* once again, there is a "*4" implied in this C construct
 * because sizeof(pgEntry) == 4
 */

if X=0x12345678, you have PTE = 0xFFC00000 + 12345*4 == 0xFFC0000 | 0x00048D14 = 0xFFC48d14, which will be interpreted by the MMU as
PDE[3FF](uses the page directory as page table)--> PTE[048](uses page table for 0x120xxxxx as page) --> offset [d14 .. d17] (read the entry for 0x12345xxx)

Hope i made it clearer.
seems there's something wrong thus in the previous picture: 0xffd20000 should be replaced by 0xffc48000.