Re: New pmap module for m68k

> On Nov 9, 2025, at 10:34=E2=80=AFAM, Romain Dolbeau =
<[email protected]> wrote:
>=20
> Le dim. 9 nov. 2025 =C3=A0 19:18, Jason Thorpe <[email protected]> a =
=C3=A9crit :
>> (...) 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.
>=20
> 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=E2=80=99s 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=E2=80=99m not going to mess with it =
.. I=E2=80=99ll hassle Jeremy separately :-)

>> One of the reasons I wanted to do this is so that larger memory =
configs can be supported on 68040
>=20
> Good news! and ...
>=20
>> successfully booted NetBSD/virt68k multi-user with a 2G RAM =
configuration
>=20
> ... excellent result. Congratulations! No reason for a virtual machine
> to not have as much memory as a 32-bits CPU can support.
>=20
> 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=E2=80=99s 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=E2=80=99t =
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=E2=80=99s =E2=80=9Ccontrol space=E2=80=9D) and fiddle the =
%sfc and %dfc registers and use the instructions that access the spaces =
explicitly (which =E2=80=A6 yah, just no).

-- thorpej