Re: New pmap module for m68k

Le dim. 9 nov. 2025 =C3=A0 20:04, Jason Thorpe <[email protected]> a =C3=A9cri=
t :
> In the new module, the 68851-class (...)

OK thank you!

> No hard limit I know if, it=E2=80=99s just what I tried.  The Qemu virt68=
k 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 m=
ore 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 regis=
ters and
use the instructions that access the spaces explicitly (which =E2=80=A6 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,

--=20
Romain Dolbeau