processor caching my page directories?

[carbonBased]

I've been implementing a basic memory manager, and I've noticed an oddity:

linearAddr = memoryAllocatePage();
*(long *)linearAddr = 0xffffffff;
memoryFreePage(linearAddr);
*(long *)linearAddr = 0xffffffff;

It stands to reason that the last memory write should cause a page fault, seeing as though memoryFreePage removes the page from the currently running task's paging tables.

Problem is, it doesn't.  And the memoryFreePage() code is 100% correct.

If I remove the initial write to linearAddr, then the secondary write (after the free) does, in fact, cause a page fault.

This leads me to believe the processor is caching my page table entries... how would I go about correcting this problem?

Jeff

[garf]

Take a look at the invlpg instruction. It invalidates the TLB (Translation Lookaside Buffer) internal to the processor. The TLB is essentialy a cache for page table entries. I beleve invlpg does what you need.

In your memoryFreePage() call you would issue the instruction invlpg using the linear address passed in as the operand to the instruction. invlpg 0xffffffff in your example. Also, if you are building an SMP kernal, make sure that the other processors also invalidate thier TLBs as well to keep them in sync.

I have not built my own memory manager yet so I am guessing based on what I have read in the Intel docs. I hope it helps.

[AnotherNewOS]

Hi !

Just reload the CR3 register:

mov eax, cr3
mov cr3, eax

That should work ...

Joerg

[garf]

Reloading CR3 will work, however that will invalidate the whole TLB and could affect performance. INVLPG tries to only invalidate one entry preserving the rest of the cache. If you are changing a block of page directory entries, reloading CR3 is probably the way to go.

[carbonBased]

I did look at the invlpg instruction, but according to my documentation, it will cause an invalid opcode exception when used with a register operand.

In other words, it can only accept a memory operand... but how!?

I can't do a "invlpg 0x05fff000", for example, because I can't possibly know which page has just been allocated... _unless_ I use a register to hold it.

How does this instruction work?

Jeff

PS: Strangely enough, when I add new page tables, everything works.  No need to invalidate cache.  Seems to only be a problem when _changing_ pages (and even then, it only seems to effect changing a page from "present" to "not present"... the opposite works... just thought that was a bit weird).

[carbonBased]

Nevermind, I got it...

invlpg [reg] ; works
invlpg reg   ; doesn't

Works perfectly!  Thanks guys!

ndk v0.05 should be out soon, with lots of goodies (now, including memory management

Jeff

[garf]

Nice docs Intel's got for us to work with

Glad you figured it out.

[[email protected]]

>PS: Strangely enough, when I add new page tables, everything works.  No need to invalidate cache.  Seems to only be a problem when _changing_ pages (and even then, it only seems to effect changing a page from "present" to "not present"... the opposite works... just thought that was a bit weird).

Makes sense if you think about the TLB as the cache it is. If the page was unused before, and the cpu had never touched it, then it can't have a TLB entry that references that page. So adding a new page entry is fine. The next time the cpu touches it it'll load a new TLB entry from the page table and go.

It's only if you change or remove an entry that the TLB gets out of sync, since the cpu can potentially have a TLB entry that covers that page, and it wont reload the entry from the page table, since it doesn't know it changed.

geist