From: cr88192@gmail.com   
      
   On 5/22/2023 6:09 AM, Dan Cross wrote:   
   > In article , BGB   wrote:   
   >> On 5/21/2023 4:07 PM, Dan Cross wrote:   
   >>> [snip]   
   >>> Would it really?  Limits and base are already ignored in long   
   >>> mode; about the only thing it's still used for is GSBASE/FSBASE   
   >>> and for that we have MSRs.  But, having to program non-null   
   >>> segment selectors into STAR, and having to have a valid GDT,   
   >>> adds seemingly unnecessary complexity.  If they're going to   
   >>> swap around how they do AP startup with a brand-new SIPI type,   
   >>> it doesn't seem like a big lift to just do away with   
   >>> segmentation entirely.   
   >>>   
   >>   
   >> Ironically, if one goes over to software managed TLB, then the whole   
   >> "nested page table" thing can disappear into the noise (as it is all   
   >> software).   
   >>   
   >>   
   >> Or, you have people like me going and using B-Trees in place of   
   >> page-tables, since B-Trees don't waste as much memory when one has a   
   >> sparse address space managed with aggressive ASLR (the pages in the   
   >> upper levels of the page-tables being almost entirely empty with sparse   
   >> ASLR).   
   >>   
   >> Granted, I don't expect many other people are likely to consider using   
   >> B-Trees in place of page-tables to be a sensible idea.   
   >   
   > Software-managed page tables actually dramatically complicate   
   > address space management in a hypervisor, in part because the   
   > page table used by a guest is not generally knowable in advance   
   > (a guest can just make up their own).   
   >   
      
   If the guest is using the same type of software managed TLB, one doesn't   
   emulate the guest's page-tables, one emulates the guest's TLB   
   (effectively running the TLB through another level of virtual address   
   translation).   
      
      
   > Why a B-tree instead of a radix tree, anyway?   
   >   
      
   If you mean a radix tree, like conventional page-tables, the issue is   
   mostly a combination of a large address space and ASLR.   
      
   The page table works fine for a 48-bit address space, but starts to have   
   problems for a larger space.   
      
      
   In my case, the "full" virtual address space is 96 bits.   
      
   The upper levels of the page table end up being mostly empty, and if one   
   tries to ASLR addresses within this space, then the memory overhead from   
   the page tables ends up being *absurd* (huge numbers of page tables   
   often with only a single entry being non-zero).   
      
   I had ended up often using a hybrid strategy, where the upper-bits of   
   the address are managed using a B-Tree, and the low-order bits with a   
   more conventional page table.   
      
   Say, for 16K pages:   
      Addr(95:36): B-Tree   
      Addr(35:14): 2-level page-table   
      
   Then one can use ASLR freely without burning through excessive amounts   
   of memory (say, with an 8-level page table for 16K pages).   
      
   Note that 4K pages would require a 10-level page-table, and 64K pages a   
   7-level page-table.   
      
      
   A pure B-Tree would use less memory than the hybrid strategy, but the   
   drawback of a B-Tree is that it is slower.   
      
   It is possible to speed-up the B-Tree by using a hash-table to cache   
   lookups, but this is most effective with the hybrid strategy.   
      
      
   Using hash-tables as the primary lookup (rather than B-Trees) had been   
   looked into as well, but hash tables have drawbacks when used in this   
   way (they don't scale very well).   
      
   Had also experimented with using AVL Trees, however these ended up   
   slightly worse in terms of both memory overhead and performance when   
   compared with B-Trees (though, AVL Trees are a little simpler to implement).   
      
   ...   
      
      
   Note that the memory layout here would have programs within their own   
   local 48 bits (programs not generally needing to care about anything   
   beyond their own 48-bit space), but the programs are placed randomly   
   within the 96-bit space (so that one program can't "guess" an address   
   into another program's memory; but memory can still be "shared" via   
   128-bit "huge" pointers).   
      
   Say:   
      void *ptr;  //points within the local 48-bit space (64-bit pointer)   
      void * __huge ptr;  //points within the 96-bit space (128-bit)   
   ...   
      
   Say:   
      void ** __huge ptr;  //128-bit pointer to 64-bit pointers   
      __huge void **ptr;  //64-bit pointer to 128-bit pointers   
      __huge void ** __huge ptr;  //128-bit pointer to 128-bit pointers   
      
   ...   
      
   Though, this part is specific to BGBCC.   
      
      
      
   I had put off some of this for a little while, but it came up again   
   mostly because my CPU core can also run 64-bit RISC-V, but it turns out   
   GCC doesn't support either PIE or shared-objects for this target   
   ("WTF?"), so to be able to load them up as programs, I need to give them   
   their own address space, and throwing them off into random parts of   
   96-bit land seemed the "lesser of two evils" (as compared with needing   
   to actually deal with multiple address spaces in the kernel).   
      
   This is a little bit of an annoyance as it does mean needing to widen   
   the virtual memory system and anything that deals directly with system   
   calls to deal with the larger address space (and, secondarily, use a   
   wrapper interface because, if any of this code is built with GCC in   
   RISC-V mode, then GCC doesn't support either 128-bit pointers or 128-bit   
   integers).   
      
   Though, in some cases, this will mean needing to copy things into local   
   buffers and copy them back into the program's address range (so, a   
   similar annoyance to if one was dealing with multiple address spaces).   
      
   ...   
      
   --- SoupGate-Win32 v1.05   
    * Origin: you cannot sedate... all the things you hate (1:229/2)