From: cr88192@gmail.com   
      
   On 5/25/2023 2:08 PM, Dan Cross wrote:   
   > In article , BGB   wrote:   
   >> On 5/24/2023 1:12 PM, Dan Cross wrote:   
   >>>>> Right.  But the guest expects to run within a virtual address   
   >>>>> space of its own construction.  You have a single TLB at the top   
   >>>>> level that is shared by both guest and host and must be   
   >>>>> multiplexed between them; what do you do when they conflict?   
   >>>>   
   >>>> The guest doesn't push into the main TLB.   
   >>>> The whole thing is a "pull" model, not a "push" model.   
   >>>>   
   >>>> Rather, it would be more like:   
   >>>>     Host experiences a TLB miss, checks its structures;   
   >>>>       If it is host memory, the host can translate it as appropriate;   
   >>>>     Checks the guests TLB;   
   >>>>       If it is found in the guest's TLB, pull it down into the host.   
   >>>>       This performs any address translation.   
   >>>>     If it is not found, trap into guest.   
   >>>   
   >>> This is not the scenario that I'm talking about here.   
   >>>   
   >>> You have the host.  The host has chosen to run itself at virtual   
   >>> address 0xWhatever.  The host is executing a guest, that has   
   >>> also chosen to run itself at 0xWhatever.  The type of fault you   
   >>> receive here is actually a page protection fault (presumably,   
   >>> you are forcing the guest to run in userspace while the   
   >>> hypervisor runs in privileged mode), not a TLB miss; there is   
   >>> already a TLB entry for the address in question, since you were   
   >>> (presumably) just using it in the host.  So what do you do?   
   >>>   
   >>   
   >> This is where ASIDs come in:   
   >> They allow multiple address spaces to coexist in the TLB at the same   
   >> time, while being mutually invisible to each other.   
   >>   
   >> So, say:   
   >>    0123_456789AB with ASID=1234   
   >> And:   
   >>    0123_456789AB with ASID=5678   
   >>   
   >> Can both exist in the TLB at the same time.   
   >   
   > This doesn't really solve the problem, but just moves the   
   > goal-posts (because now, of course, you're sharing the ASID   
   > space with the guest in the exact same way that you are sharing   
   > the virtual address space).  Now, you have to trap every guest   
   > reference to an ASID and adjust it, pushing significant   
   > complexity into the VMM, which was the original argument for why   
   > a soft-TLB was "better."   
   >   
      
   You can adjust them when them in the handlers at basically the same time   
   as when doing an additional level of address translation, no additional   
   trapping needed.   
      
   The point is not "well, it requires some additional code", but rather   
   that it does not require additional hardware support for each feature   
   that is added.   
      
   Most would not likely consider needing to use a few additional lookup   
   tables or similar to be a significant issue.   
      
      
   So, as the guest sees it, it has one set of addresses, one set of ASIDs,   
   etc, and for the host, different addresses and ASIDs.   
      
   No big issue so long as one doesn't run out of ASIDs.   
      
      
   But, as noted, I am using 16-bit ASIDs here.   
      SuperH had used 8-bit ASIDs;   
      Some traditional RISC's had used 5-bit ASIDs.   
   A 16-bit space is going to last a lot longer than 5 or 8 bits.   
      
      
      
   If the mechanism were a little more flexible, one could also emulate   
   8086 real-mode addressing (or 286/386 style segmented addressing) via   
   the TLB, but currently this is not supported (could be added if a strong   
   use-case came up though). Would likely be added if I were trying to do   
   something along similar lines to DOSBox.   
      
   This would mostly require adding a mode where a low-order bias could be   
   added to the page during translation.   
      
   Otherwise, it would be more expensive to emulate segmented addressing in   
   cases where the segment base is not a multiple of the page size.   
      
      
   The main difficult/annoying part would be needing to come up with some   
   way to efficiently emulate x86 style flags / condition codes (my ISA   
   doesn't currently have any support for ALU flags or condition codes; and   
   they are expensive to emulate via bit twiddling when a significant part   
   of the ISA may potentially update the status flags).   
      
   Though, this would still be assuming some sort of dynamic   
   trace-translation mechanism.   
      
   Well, and then the GDT and LDT handling can basically be glued onto the   
   normal page-table handling code. Though, supporting "big real mode"   
   would make things a little more fiddly (since the state of the segment   
   is tied to the segment register itself, rather than the value held by   
   the segment register; and one wouldn't want to do a TLB flush due to   
   reloading a segment register or similar).   
      
   ...   
      
   --- SoupGate-Win32 v1.05   
    * Origin: you cannot sedate... all the things you hate (1:229/2)