OSDev.org

rootel77 wrote:all soluttions i've found implements either the 1st or the 2nd solution. and i like to know if someone knows another solution.

This is complicated and slow, but allows the OS to change address spaces that aren't currently being used (where a simple implementation of method 2 doesn't).

For PAE it's different because there's 4 seperate page directories (CR3 points to a PDPT or "page directory pointer table" with 4 entries). This actually makes things much easier - I have one "kernel page directory" that is used for all address spaces (i.e. put into every page directory pointer table). Because of this there is no problem with adding kernel page tables. Here, I map the kernel's page directory as the highest kernel page directory entry (creating a 2 MB kernel page table map at the end of address space), and then map the user level page directories into the highest user level page directory entries (creating a 6 MB user level page table mapping from 0xBFA00000 to 0xBFFFFFFF).

For long mode there's multiple page directory pointer tables and a "PML4" (page map level 4 table), where CR3 contains the address of the PML4. In this case I set the highest PML4 entry to the address of the PML4, which creates a 512 GB page table mapping for the current address space. The problem here is adding a new page directory pointer table in kernel space (it's the same problem as adding a new page table in kernel space with 32 bit paging). Here I ignore the problem and hope that the kernel will never need more than one page directory pointer table. This restricts the kernel to 512 GB (it could use up to 128 TB if I allowed it to add new kernel PDPTs), which IMHO is large enough.

rootel77 wrote:

This is complicated and slow, but allows the OS to change address spaces that aren't currently being used (where a simple implementation of method 2 doesn't).

i assume if you have a page dir, you have already allocated it by some method, and probably have a pointer to it. this applies to all others page dirs allocated. so i dont see any problem to change adress space that are not currently used. a simple loop over a linked list will do.

rootel77 wrote:certainly, this make things a lot easier. in PAE mode, i still prefer the method 2. however in "long mode" where the kernel can map a large space for itself, i would opt for the linux way, ie identity map the whole physical memory to simplify access and implements some continuous memory alocation policy.

If you mean changing CR3 to each address space that needs to be modified, then yes this would work. Unfortunately it'd also wipe out the TLB (and might cause problems for interrupt/IRQ handlers if they assume that the current address space belongs to the currently running process, unless you disable interrupts).

sos_ret_t sos_mm_context_synch_kernel_PDE(unsigned int index_in_pd,
                 sos_ui32_t pde)
{
  sos_ui32_t flags;
  struct sos_mm_context * dest_mm_context;
  int nb_mm_contexts;

  sos_disable_IRQs(flags);
  list_foreach_forward(list_mm_context, dest_mm_context, nb_mm_contexts)
    {
      sos_ui32_t * dest_pd;

      SOS_ASSERT_FATAL(dest_mm_context->ref_cnt > 0);

      dest_pd = (sos_ui32_t*) dest_mm_context->vaddr_PD;
      dest_pd[index_in_pd] = pde;
    }
  sos_restore_IRQs(flags);

  return SOS_OK;
}

      dest_pd = (sos_ui32_t*) dest_mm_context->vaddr_PD;

i assume if you have a page dir, you have already allocated it by some method, and probably have a pointer to it. this applies to all others page dirs allocated. so i dont see any problem to change adress space that are not currently used. a simple loop over a linked list will do.

If you mean changing CR3 to each address space that needs to be modified, then yes this would work. Unfortunately it'd also wipe out the TLB (and might cause problems for interrupt/IRQ handlers if they assume that the current address space belongs to the currently running process, unless you disable interrupts).

i dont see what we must change the the CR3 each time we have to modify a page dir other than the current. this is an example extracted from a french os tutorial SOS (http://sos.enix.org/fr/PagePrincipale) that loop over all user's page dirs to synchronize them

Of course for "method 1" the physical address of the page directory is not useless - you can add a constant to it to find where the physical page was mapped in kernel space. This might be what SoS is doing (I may have been wrong above) - " dest_mm_context->vaddr_PD" might be equal to "dest_mm_context->paddr_PD + some_constant", but for some unknown reason I doubt this (I haven't downloaded their source and checked though).

JAAman wrote:mapping all physical memory into kernel-space won't work once you start paging out to disk -- then the page tables for less commonly used processes may not be in memory

JAAman wrote:it is quite rare that you will need to update more than a single address-space (actually i cannot think of any reason) -- the destination of a shared memory (or passed, but not shared) request (if passing, then the current address-space would also need updateing -- but thats easy)

JAAman wrote:what if you mark the transaction in a table in global space, then flag the destination process in the task handler to enter kernel mode first -- that way it can be handled before the task is reentered at which point there will be a CR3 change anyway, so TLB invalidation wont cost anything extra, yet you are only changing it within the address space? -- this would solve all problems -- including the possibility that the page tables are not even in physical memory (taken a step further, if they aren't in memory, you could wait to update until they are referenced -- at which time a page fault would occure, and the entry could be updated at that time)

For most OS's, there's 1 GB or more of "kernel space" that is mapped into every address space. For example, for my OS, if the kernel needs another page table and it's running 1000 processes, then it needs to allocate a physical page and then put it into 1000 address spaces at the same time (while other CPUs may be running in some of those other address spaces).

rootel77 wrote: @JAAman: well, if you choose method 1, and user's pagedirs and page tables are mapped into the kernel space (ie for the kernel they are just normal data structures with virtual adresses). it is not a good practice to swap them out. if you are low in memory it is more natural to choose pages from user process to swap them out.