On Thu, Jun 27, 2013 at 03:23:36PM -0600, Chris Torek wrote: > OK, I wasted :-) way too much time, but here's a text file that > can be comment-ified or stored somewhere alongside the code or > whatever... I think it would be a nice addition to the VM article in the doc collection. The content is correct and useful, IMO. See some notes below.
> The reason for having those "empty" (all-zero) PTE pages is that > whenever new processes are created, in pmap_pinit(), they have > their (new) L4 PTE page set up to point to the *same* physical > pages that the kernel is using. Thus, if the kernel creates or > destroys any level-3-or-below mapping by writing into any of the > above four pages, that mapping is also created/destroyed in all > processes. Similarly, the NDMPML4 pages starting at DMPDPphys are > mapped identically in all processes. The kernel can therefore > "borrow" a user pmap at any time, i.e., there's no need to adjust > the CPU's CR4 on entry to the kernel. It is %cr3. > > (If we used bcopy() to copy the kernel pmap's NKPML4E and NDMPML4E > entries into the new pmap, the L3 pages would not have to be > physically contiguous, but the KVA ones would still all have to > exist. It's free to allocate physically contiguous pages here > anyway though.) I do not see how the physical continuity of the allocated page table pages is relevant there. Copying the L4 or L3 PTEs would cause serious complications. In fact, this is how i386 operates, since due to limited VA, pmap does not have a luxurly of allocating entire L(top-1) page table pages to the kernel. As result, pmap_kenter_pde() have to iterate over the whole pmap list, which is maintained just to be able to update KVA mappings. > > So, the last NKPML4E slots in KPML4phys point to the following > page tables, which use all of L3, L2, and L1 style PTEs. (Note > that we did not need any L1 PTEs for the direct map, which always > uses 2MB or 1GB super-pages.) This is not quite true. In the initial state, indeed all PTEs for direct map are superpages, either 1G or 2M. But Intel states that a situation when the physical page has mappings with different caching modes causes undefined behaviour. As result, if a page is remapped with non-write back caching attributes, the direct map has to demote the superpage and adjust the mapping attribute of the page frame for the page. As result, it is possible to have small mappings in the direct map. See pmap_page_set_memattr(), which delegates the work to pmap_change_attr(_locked).
pgpHAwuqmlvZy.pgp
Description: PGP signature
