Paging issues...

[carbonBased]

In attempting to write some new address-space independent synchronizing utilities I've run into a pager issue.

The scenario is relatively simple:

- I want to map a physical page to 0xbffff000
- To do this, I need to create a page table
- After creating the page table, I set the appropriate location to map linear 0xbffff000 to the physical page I have
- Immediately after I read back this value and I get 0 instead of the value I just wrote there.

I assume this has something to do with the TLB cache, but invlpg doesn't appear to help (is there a general set of rules as to when an invlpg is required on an x86 platform, btw?).

The creation of the page table may play a role here. After creating a new page table, I make sure that I zero out all the entries in it. It's my current assumption that this 0 has stuck in the TLB cache and remains, even though I've more recently overwritten it with a valid physical page.

Any help in this matter would be greatly appreciated!

Thanks,
Jeff

[Kevin McGuire]

The creation of the page table may play a role here. After creating a new page table, I make sure that I zero out all the entries in it. It's my current assumption that this 0 has stuck in the TLB cache and remains, even though I've more recently overwritten it with a valid physical page.

If you are verifying the value by a data read which would be doing it through writing some code to change it then writing some code to display it then the TLB is most likely not the problem since you would be reading and writing to the L1 cache, L2 cache, L3 cache, or main memory (nothing to do with the TLB).

(Possibility)
Your physical page allocation routines may be handing you a page address that is used by a device for MMIO, or a area of memory that is shadowing a ROM which is READ-ONLY. In this case all writes would have no affect. I have personally had this problem before.

_Some_ of your page tables must write and read back a correct value. I am assuming this is true, because you state that the TLB is active by saying it could be part of the problem and since you must have your kernel mapped in to be running with virtual memory enabled which should hopefully prove that the problem is not writing and reading a value but something else specific to this one or multiple affected page tables instead of them all.