OSDev.org

I suspect, I badly misunderstood those talking about "mapping all physical memory" approach. so my question may be stupid. you say you map all RAM. where? in the kernel part of AS? ok, what's next, where do you get free pages for user mode processes? you have multiple mappings for the same physical page to different "virtual" pages in the same AS? is it allowed at all? I don't remember what is on x86.

zaval wrote:you have multiple mappings for the same physical page to different "virtual" pages in the same AS?

Yes.

zaval wrote:is it allowed at all?

Yes, but you can't map the same physical page with different cache types, and if you want to change the cache type you must be very careful to ensure no CPU can contain any cached references to the page with the old mapping before you use the new mapping.

Let me ask the other way around: is there an architecture where having multiple mappings of the same page is not allowed? I do not know any.

thanks, Octocontrabass.

Korona wrote: Let me ask the other way around: is there an architecture where having multiple mappings of the same page is not allowed? I do not know any.

I honestly don't know. I never considered this possibility a good idea and as such, didn't investigate on it. also, there are subtleties between how it's made in different archs, that make comparison harder. for example on MIPS, you have 2 regions in the kernel part of AS, that both architecturally mapped to the same predefined system (physical) address range. and they do differ in cacheability. one may be cacheable or not, another one is uncached always. so multiple mappings here appear even without any actions on your side.

it was interesting to hear in case if I understood correct, what having a mapping Mk for some ph. page could give to you when you need to free (unmap) that page as a result say a process freeing some buffer? you still need to unmap Mu for this page and create another mapping Mu2 when you decide to give that page to another process.

In a structure, holding the state of the physical pages, there is a pointer to PTE wired to this page at this time. apparently not to the array of of PTEs for different places. but this is OS specific.

zaval wrote: it was interesting to hear in case if I understood correct, what having a mapping Mk for some ph. page could give to you when you need to free (unmap) that page as a result say a process freeing some buffer? you still need to unmap Mu for this page and create another mapping Mu2 when you decide to give that page to another process.

The process itself only has one mapping for the page (well, it *could* have multiple mappings if it mmap()s the same file twice, but that probably isn't useful, and if it is, the process is responsible for managing it correctly). The *kernel*, operating in the process's address space, has two mappings: the mapping visible to the process down in userspace, and the mapping that's part of its physical memory map up in kernel space. While the userspace mapping exists, the kernel probably isn't doing much with the kernelspace mapping: it just exists whether it's being used or not for convenience. When the process frees the page, it's returned to the kernel's free page list. If the kernel then sets up a new page table for a different process, and pops the newly freed page of the free page list, it can just use the physical address for the page returned by the physical memory manager, add a constant offset, and fill in the new page table on the spot, because it already has a mapping. Otherwise it would need to map the page to a virtual address in kernel space before writing to it.