Brendan (btrotter.delete@this.gmail.com) on July 18, 2022 3:11 pm wrote:
> Hi,
>
> Adrian (a.delete@this.acm.org) on July 18, 2022 10:21 am wrote:
> > Paul A. Clayton (paaronclayton.delete@this.gmail.com) on July 18, 2022 7:49 am wrote:
> > > Kester L (nobody.delete@this.nothing.com) on June 29, 2022 1:49 pm wrote:
> > >
> > >

Having a single linear map would be prohibitively expensive in terms of memory for the
> > > map itself, so translations use a truncated tree structure, but that adds a whole slew
> > > of new possible exceptions: What if the page entry for the page directory entry for the
> > > page entry for the exception handler for missing page entries is itself empty?

> > >
> > > For a single system-wide exception handler, this problem
> > > can be avoided by having hardwired mappings. 32-bit
> > > MIPS provided kseg0 (hardwired translation, cacheable memory)
> > > and kseg1 (hardwired translation, uncacheable memory),
> > > each 0.5 GiB. Fairchild's CLIPPER hardwired eight 4KiB
> > > pages in the kernel address space (CLIPPER completely
> > > separated supervisor and user address spaces and had separate
> > > cache and MMU chips for data so that there were
> > > technically four possible address spaces. "This permanent
> > > mapping provides several benefits: it makes the Boot
> > > ROM immediately available on reset; it also makes some I/O
> > > available during initialization; finally, it insures
> > > that the lowest 3 pages of the supervisor's address space
> > > (which are in constant use, since they contain the
> > > exception vector table) are always translated rapidly." [Introduction to the CLIPPER Architecture])
> > >
> > > Another option is to have lockable translation entries. This does not keep software from
> > > improperly initializing system state; even hardware initialization of precognifigured
> > > and locked translations is not foolproof, software could unlock a translation entry or
> > > even just place critical memory in areas not mapped by such locked translations.
> >
> > Another simpler option is that used by IBM POWER, which I prefer over the others.
> >
> > When in privileged mode, the paging is bypassed, so the kernel uses
> > physical addresses, except when copying to/from a user process.
> >
> > In this case, there are no page faults in privileged mode, including during exception handling.
>
> Page tables/MMU allow some powerful tricks (swap space, copy on write/allocate on demand, etc); and
> a kernel can and should exploit these same powerful tricks for its own benefit (e.g. making data that
> kernel shouldn't need to access unable to be accessed accidentally to improve kernel bug and/or vulnerability
> detection, allowing parts of itself (and user-space page tables) to be sent to swap space to reduce
> kernel's memory consumption, using a deliberately randomized physical address for each individual
> page to improve kernel's security, NUMA optimizations where different copies of read-only kernel code
> and data are used by different CPUs to improve kernel's performance, etc).
>
> In this case, if there are no page faults in privileged mode, then kernel
> must be a steaming pile of garbage (unable to benefit from MMU).

POWER can run with MMU enabled or disabled in privileged modes. Presumably when in supervisor mode it just "appears" to be disabled but still has the hypervisor level management in place.