From: cr88192@gmail.com   
      
   On 5/22/2023 3:10 PM, Dan Cross wrote:   
   > 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.   
   >   
      
   IME, it isn't really all that difficult in practice.   
      
   Granted, for things like removing a page from the TLB, these were   
   generally handled by loading an empty TLBE (for a given virtual address)   
   roughly 8 times in a row. With a set-associative TLB, this was enough to   
   make sure the page was evicted (and should also be easy enough to detect   
   and handle).   
      
      
   > 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.   
   >   
      
   But, if one uses SW TLB, then NPT (as a concept) has no reason to need   
   to exist...   
      
      
   > There's a reason soft-TLBs have basically disappeared.  :-)   
   >   
      
   Probably depends some on how the software-managed TLB is implemented.   
      
   In my case, TLB miss triggers an interrupt, and there is an "LDTLB"   
   instruction which basically means "Take the TLBE from these two   
   registers and shove it into the TLB at the appropriate place".   
      
   In this case, there is no way for the program to directly view or modify   
   the contents of the TLB.   
      
      
   As can be noted in my testing, TLB miss rate is typically low enough   
   (with 16K pages and a 256x 4-way TLB) that the performance impact of   
   handling TLB misses in software doesn't really have all that much effect   
   on the overall performance of the program.   
      
   As can be noted:   
   TLB miss rate increases significantly with 4K pages vs 16K pages;   
   Dropping to 64x 4-way also increases miss rate;   
   Miss rate is "pretty bad" at 16x 4-way.   
      
   Generally, stable operation of the TLB seems to require at least 4-way   
   associativity for the L2 TLB (an L1 TLB can get by more effectively with   
   1-way assuming a modulo indexing scheme; So, 16x 1-way for the L1 TLB).   
      
   Note that fully associative TLBs aren't really viable on an FPGA.   
      
      
   > 	- Dan C.   
   >   
      
   --- SoupGate-Win32 v1.05   
    * Origin: you cannot sedate... all the things you hate (1:229/2)