Re: New pmap module for m68k

[Jason Thorpe <thorpej%me.com@localhost>]

> On Nov 9, 2025, at 10:34 AM, Romain Dolbeau <romain%dolbeau.org@localhost> wrote:
> 
> Le dim. 9 nov. 2025 à 19:18, Jason Thorpe <thorpej%me.com@localhost> a écrit :
>> (...) natively works with the 3-level table configuration of the 68040 while also natively working with he mandatory 2-level configuration imposed by the HP MMU found in the HP 9000/320 and 9000/350.
> 
> Out of curiosity: what does that mean for other MMUs ? Like the '030,
> or the Sun-style MMUs ? They stick with the current model ?

In the new module, the 68851-class (which includes the 68030) currently uses the same 2-level configuration as in the Hibler pmap.  This is mainly intended to provide test coverage for the 2-level code, because HP 9000/320 and 9000/350 machines are few and far between.  Eventually I intend to switch 68851-class MMUs to use a 68040-compable 3-level configuration (it’s slightly more memory efficient), leaving the HP MMU the only one using the 2-level (although this would be a trivial compile-time configuration option).

Sun-style MMUs not affected.  Sun2/Sun3 use their own pmap module.  Also not impacted is Sun3x, which is a 68030, but also has its own pmap module for historical reasons (and I’m not going to mess with it .. I’ll hassle Jeremy separately :-)

>> One of the reasons I wanted to do this is so that larger memory configs can be supported on 68040
> 
> Good news! and ...
> 
>> successfully booted NetBSD/virt68k multi-user with a 2G RAM configuration
> 
> ... excellent result. Congratulations! No reason for a virtual machine
> to not have as much memory as a 32-bits CPU can support.
> 
> Is the 2 GiB a hard limit of this new design (rather than the QEmu
> machine model), or would it be possible to go beyond that by using
> "tricks" on the physical side, such as using the UPA bit as additional
> address bits ? (The pins are driven by the bits in the MMU IIRC, so I
> think in theory they could be used to generate a 2^34 bytes physical
> address space, should that be potentially useful.)

No hard limit I know if, it’s just what I tried.  The Qemu virt68k machine does have some sort of limit, because the I/O devices are at the top of the physical address space.  Obviously can’t put RAM there.  The m68k port has a 32-bit physical address type, so the only way to get more space would be to use different m68k function codes (like the Sun3’s “control space”) and fiddle the %sfc and %dfc registers and use the instructions that access the spaces explicitly (which … yah, just no).

-- thorpej