From: cr88192@gmail.com   
      
   On 5/24/2023 1:12 PM, Dan Cross wrote:   
   > In article , BGB   wrote:   
   >> On 5/24/2023 6:33 AM, Dan Cross wrote:   
   >>>> I think a lot of this is making a big fuss over nothing, FWIW.   
   >>>   
   >>> You can think that all you want, but sadly, that doesn't mean   
   >>> that these aren't actual problems for real-world systems.   
   >>>   
   >>>> But, in any case, SuperH (along with PA-RISC, MIPS, SPARC, etc) got   
   >>>> along reasonably well with software-managed TLB.   
   >>>   
   >>> In a very different time, with very different demands on the   
   >>> architecture.   
   >>   
   >> Depends on what one wants.   
   >>   
   >> I am mostly imagining an architecture for embedded-systems style   
   >> use-cases (but, more DSP-like than microcontroller-like).   
   >   
   > This perhaps explains why you seem to be discounting the use   
   > cases others are telling your are important in other application   
   > domains.   
   >   
      
   Possibly, I am not trying to design a CPU for desktop PCs or servers...   
      
      
   Granted, I had considered trying to use it for a CNC controller, but   
   this use-case is served reasonably well with something like an ARM-based   
   microcontroller (and having an full OS, or virtual memory, on a CNC   
   controller actually makes it worse).   
      
      
   >>>> [snip]   
   >>>>> Besides....what do you do if a guest decides it wants to insert   
   >>>>> a mapping covering part the hypervisor itself into the TLB?   
   >>>>   
   >>>> There is no reason for the guest to be able to be able to put something   
   >>>> into the TLB which would somehow circumvent the host; since anything the   
   >>>> guest tries to load into the TLB will need to first get translated   
   >>>> through the host.   
   >>>   
   >>> 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 is provided one can give each thing its own ASID, which is   
   potentially limiting in that only 65536 ASIDs can be in use at a time.   
      
   AS soon as one changes the value in the TTB(63:48), then whatever was in   
   the TLB before (that belongs to the other address space) is now ignored.   
      
   So, when one switches to the guest OS, they can switch TTB over to the   
   "guest page table" (possibly actually just a virtual TLB), with its own   
   ASID. When control moves back to the host, the host loads TTB with its   
   host page-table.   
      
      
   I can note that I am already using a mechanism like this to implement   
   system calls:   
      User process triggers a System Call;   
      SYSCALL ISR performs a task switch to the SYSCALL handler task;   
      Handler does its thing;   
      It invokes the SYSCALL ISR again, which transfers control back to the   
   caller task.   
      
   In this case, the user program can run in user-mode, whereas the syscall   
   handler task runs in supervisor mode.   
      
   It is not handled directly by the ISR, mostly because the ISR's run in a   
   special mode which has the MMU disables and which can't handle interrupt   
   (and a fault here will cause the CPU to lock-up until a RESET signal is   
   received, such as from pressing an external reset button). It is   
   possible a flag could be added to auto-reboot the CPU though.   
      
      
      
   Translating things in 96-bit space is another option, but fully   
   generalizing this would likely require adding an additional translation   
   layer. But, this could potentially be used to sidestep the "only 64K   
   unique ASIDs" limitation.   
      
   Then one could have effectively a space of up 2^64 possible 48-bit   
   address spaces...   
      
      
      
   For now though, the number of PIDs+threads in my use-cases small enough   
   that the 64K ASID limit isn't too much of an issue.   
      
   As-is, I would run out of both RAM and pagefile space well before I run   
   out of ASIDs, if I were using this way.   
      
   Granted, for most normal tasks, I am currently running them in a shared   
   address space, and instead the idea is that ACL checks would be used to   
   keep one process from stomping on another process's memory (which   
   ironically, effectively creates sub-rings within User Mode).   
      
      
   > There are several answers here, btw; the obvious one is trap and   
   > emulate the entirety of the guest's access to this region of the   
   > virtual address space, but that's a) complex, and b) expensive.   
   >   
      
   And, unnecessary...   
      
      
   > Another is to make the hypervisor relocable, and only trap into   
   > a small, position-independent trampoline stub that can, say, set   
   > a base register and jump somewhere else.  This will break down   
   > if the guest uses too much of the virtual address space.   
   >   
   > Yet another, since you control the hardware, is to have a   
   > separate "guest" hardware TLB and an execution mode that uses   
   > it, but that adds complexity to the hardware.   
   >   
      
   And, is also unnecessary, given one can have multiple address spaces   
   present in the same TLB at the same time without them conflicting with   
   each other (provided each has a different ASID).   
      
      
   > Another option is to locate the hypervisor somewhere random in   
   > the virtual address space that is unlikely to conflict with a   
   > guest and simply declare it off-limits by convention, but guests   
   > don't necessarily need to obey convention.   
   >   
   > None of these are particularly great options.   
   >   
      
   The latter is also possible.   
      
   Within the high 48 bits, there is plenty of space...   
      
      
   [continued in next message]   
      
   --- SoupGate-Win32 v1.05   
    * Origin: you cannot sedate... all the things you hate (1:229/2)