From: cross@spitfire.i.gajendra.net   
      
   In article , BGB   wrote:   
   >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).   
      
   Indeed, but that introduces complications: on a TLB miss   
   interrupt, the hypervisor must invoke the guest's TLB miss   
   handler to supply the translation (since it can't just walk the   
   guest's page tables, since it doesn't know about them), then   
   trap the TLB update.  That's all straight-forward, but it's also   
   slow.  Often, to mitigate this, the hypervisor will cache recent   
   translations itself (e.g., Disco's L2TLB), but now we have to   
   emulate removals as well (again, straight-forward, but something   
   to consider nontheless).  And when we consider nested   
   virtualization (that is, a hypervisor running under a   
   hypervisor) this overhead gets even worse.   
      
   L2PT's like the EPT and NPT are wins here; even in the nested   
   VM case, where we have to resort to shadow paging techniques, we   
   can handle L2 page faults in the top-level hypervisor.   
      
   There's a reason soft-TLBs have basically disappeared.  :-)   
      
   	- Dan C.   
      
   --- SoupGate-Win32 v1.05   
    * Origin: you cannot sedate... all the things you hate (1:229/2)