Re: New pmap module for m68k

[Romain Dolbeau <romain%dolbeau.org@localhost>]

Le dim. 9 nov. 2025 à 20:04, Jason Thorpe <thorpej%me.com@localhost> a écrit :
> In the new module, the 68851-class (...)

OK thank you!

> 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).

Well playing with FC is not nice, Sun gets away with it as it's just
for control stuff (including updating the MMU). For normal memory,
ueah, no.

Is it possible to have more than one 32-bits space in the qemu model?
That would be a way to create something equivalent to a 34-bits area.
I am wondering if it would be possible to have UPA[1:0] (stored in
bits [9:8] of descriptors, and the treated same as address bits all
the way to the pins) used to discriminate between 4 32-bits area, that
would give the virtual model e.g. 4 GiB of I/O space and up to 12 GiB
of memory. The process virtual space would still be limited to <4 GiB,
but several of them could be resident simultaneously. Completely
useless on a real '040 (too much data, not enough speed), but might be
handy on a build host.

Cordially,

-- 
Romain Dolbeau