OSDev.org

I'm working out some of the details of memory management, and I came across a potential problem.

First, a bit of background. My kernel is currently loaded at physical address 0x00100000 by GRUB, then mapped to 0xC0100000 with a 4MB page that starts at 0xC0000000 (I use PSE, but not PAE). Eventually, I want to be able to map regions of the first physical 1MB into the virtual address spaces of driver processes. But, I also want to keep the 4MB global kernel page to conserve space in the TLB. This would mean having more than one page (the 4MB one plus some 4KB ones) mapping to the same physical addresses for a given page directory (since the 4MB kernel page is mapped in all page directories).

This seemed like an OK idea to me, until I remembered reading this (from the Intel docs, volume 3):

3.7.4. Memory Aliasing

The IA-32 architecture permits memory aliasing by allowing two page-directory entries to point to a common page-table entry. Software that needs to implement memory aliasing in this manner must manage the consistency of the accessed and dirty bits in the page-directory and page-table entries. Allowing the accessed and dirty bits for the two page-directory entries to become inconsistent may lead to a processor deadlock.

Why would this hang the processor? That sounds absolutely evil. Has anyone actually had this problem? The wording is a bit funny, in that page directory entries don't have dirty bits unless they point to 4MB pages... But it says the problem only happens when two PDEs refer to the same PTE... But PDEs refer to entire page tables, not to individual PTEs. This is almost as bad as M$ documentation.

How do those of you with user-mode drivers deal with the first 1MB of the physical address space? What do you think is the best way?

I'd really say they're just miswording it, and that you can point two entries of a page directory to the same page table.

Copy and paste some code to write a mini-kernel that you can use to test the theory in Bochs. The worst that could happen is that the mini-kernel won't work, and you'll have to go find another thing to do.

I don't think they mean that the processor will auto-hang if they get out of sync (that would make it impossible to keep them *in* sync), just that if they are out of sync and then the processor does something that replies on those bits then it might bork.

That sounds about right. I'd really only touch memory aliasing with your page tables/directories if you're writing it into your virtual memory manager, just so you keep the two synchronized.

Think of it: Why should the processor hang, just if two page entries that point to the same physical page frame are out of sync? AFAIK, the processor won't even notice that the two mean one and the same page frame - it just translates the addresses when they are accessed. I guess what they meant is actually that the software could behave unexpectedly when it relies on these page table entry attributes.

cheers Joe

i'd even add that dirty and accessed bits are never checked by the CPU. They're just blindly set when a page is accessed. period.