OSDev.org

I've been doing some fairly extensive remodeling of my memory management code, and I want to put a question out to anyone who has already dealt with paging. How do you edit your page tables?

You can't just map them temporarily to edit them, because mapping them infers editing a page table, and i see a cycle there...

Do you reserve a section of each page table or directory to point to itself? Thats what I was doing before but it seemed like there would be a better way.

Does anyone actually disable paging, edit that tables, and then turn it back on?

Thanks for your input.

bkilgore wrote:You can't just map them temporarily to edit them, because mapping them infers editing a page table, and i see a cycle there...

Nothing prevents you from doing this. You store the physical address of a page table in a page table entry and edit the table at its new virtual address. Where's the cycle?

bkilgore wrote:Do you reserve a section of each page table or directory to point to itself? Thats what I was doing before but it seemed like there would be a better way.

I store the address of the page directory in page directory entry 1023. This causes the page directory to always appear as an array of 1024 page directory entries at address 0xFFFFF000, and causes the entire (active) system page tables to appear as a million element array at 0xFFC00000. This makes editing them easier. If there's any better way, I've never heard of it, nor can I imagine it -- doing it this way is pretty darn slick.

bkilgore wrote:Does anyone actually disable paging, edit that tables, and then turn it back on?

Aside from the fact that my kernel would instantly crash, this sounds like a horrible kludge. I can't imagine a worse way of doing it. How would disabling paging make things any easier? Memory is just as easy to access with paging on as off, the only thing that changes is the addresses...

Dreamsmith wrote:
Nothing prevents you from doing this. You store the physical address of a page table in a page table entry and edit the table at its new virtual address. Where's the cycle?

I was referring to the fact that if you temporarily map them to edit them, you need to edit them to map them. Do you not see the cycle in this method? I want to edit a page table, so I go to temporarily map it into the virtual address space. But to do so, I need to edit a page table, so I go to temporarily map it into the virtual address space. But to do so, I need to edit a page table....etc, etc.

Dreamsmith wrote: I store the address of the page directory in page directory entry 1023. This causes the page directory to always appear as an array of 1024 page directory entries at address 0xFFFFF000, and causes the entire (active) system page tables to appear as a million element array at 0xFFC00000. This makes editing them easier. If there's any better way, I've never heard of it, nor can I imagine it -- doing it this way is pretty darn slick.

This is the way that I've been doing it. As I said, I was just looking for other people's methods to see if anyone had any better suggestions.

Dreamsmith wrote: Aside from the fact that my kernel would instantly crash, this sounds like a horrible kludge. I can't imagine a worse way of doing it. How would disabling paging make things any easier? Memory is just as easy to access with paging on as off, the only thing that changes is the addresses...

Well, I know my kernel wouldn't instantly crash. And besides, I wasn't saying this was the best way. Just throwing things out there to spark conversation. As far as making it easier, I wasn't saying that either, although by disabling apging for a few instructions, you eliminate the cycle I mentioned earlier, where I can just edit the physical location of the page table/directory without worrying about the cycle that could result from trying to temporarily map it. Of course, if you don't understand the cycle then I can see why you would see no point in this

bkilgore wrote:

Dreamsmith wrote: Nothing prevents you from doing this. You store the physical address of a page table in a page table entry and edit the table at its new virtual address. Where's the cycle?

I was referring to the fact that if you temporarily map them to edit them, you need to edit them to map them. Do you not see the cycle in this method? I want to edit a page table, so I go to temporarily map it into the virtual address space. But to do so, I need to edit a page table, so I go to temporarily map it into the virtual address space. But to do so, I need to edit a page table....etc, etc.

Ah, I see your problem. You're saying you don't have ANY page tables mapped ANYWHERE. This would make it absolutely impossible to ever edit a page table, map pages, or really do any sort of memory management at all.

I was thinking you already had your own page table mapped, and we're attempting to edit a new page table page. You just make an entry in your current page table point to the new page table and edit it.

But, yeah, if you have no pages tables mapped anywhere at all, it would in fact be completely impossible to do any sort of paging... you can't access unmapped memory, and you need to access page tables from an OS, therefore, an OS kernel must keep page table pages mapped into memory. Not necessarily all of them all at once, but at least one! If the count of mapped page table pages reached zero, rebooting would be your only option, unless your kernel does not itself use virtual memory. Then you could get away with turning paging off. But that's a drastic solution to fix an error that's elsewhere.

Obviously, any memory you intend to edit, you need to have mapped. If you intend to be able to edit page tables, you need to map their pages into memory.

Wel I do have some page tables, as before I enable paging I identity-map and virtual-map the kernel, etc. I guess I could find an empty page table entry and temporarily use that slot, but again, it wouldnt be enough to just have a page table, but I would have to have that page table itself mapped in some way so that I can edit it, and what if there are no free entries... I guess for now I'm going to stick with the magic self-referencing page directory like everybody else seems to use too, I was just wondering if anybody had any other ways of dealing with it.

bkilgore wrote:Wel I do have some page tables, as before I enable paging I identity-map and virtual-map the kernel, etc. I guess I could find an empty page table entry and temporarily use that slot, but again, it wouldnt be enough to just have a page table, but I would have to have that page table itself mapped in some way so that I can edit it, and what if there are no free entries... I guess for now I'm going to stick with the magic self-referencing page directory like everybody else seems to use too, I was just wondering if anybody had any other ways of dealing with it.

I've done it before without the self-referencing page directory. You just need to know the address of the page table page you want to edit, and have that page mapped somewhere. If you've identity mapped physical memory in kernel space, that's easy -- all pages are in your memory map, you just need to go edit the right one.

However, since my kernel has advanced to the point of using virtual memory itself, this trick is no longer available. Thus, I now use the "magic" trick...

As for no free entries, that's actually not a problem -- you just need to take an entry not being used at the moment (which should be all but two or three of them), store it's current value, change it to what you need, use it, then restore it's old state. I used to do this with the page table entry for virtual address 0.