[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [MiNT] Memory protection for the FireBee?



Hi Mathias,

I think I can do this if you arrange for a few months of (paid) free time from family, job and other commitments ;).
Seriously, I fear you utterly underestimate the necessary efforts 
required to implement this.
Its not only that the Coldfire MMU is different from the m68k MMU's, 
it's that it is _totally_ different.
Besides that, the Coldfire MMU is already in use by FireTOS and EmuTOS 
(BaS) to make the FireBee memory layout Atari compatible, to implement 
'faked' bus errors (that are not available on Coldfire) and to 
superimpose video memory pages into ST RAM. Thus implementing this would 
most likely require changes to existing FireTOS and/or BaS code as well 
(or would at least require intimate knowledge of what's already in use 
and how).
Without going into too much detail:

m68k MMUs basically initialize the MMU with a more or less static tree (a pretty smart implementation to reduce the amount of memory required) of page descriptors that maps virtual memory adresses to physically existing memory pages (or doesn't map them to force an error if somebody tries to access invalid memory). Every single process in MiNT has it's own table/tree that gets switched back and forth at context switches. Once the MMU tree is set up, code basically doesn't need to touch the MMU anymore, it more or less "just works" from this point in time.
The Coldfire MMU's aproach is totally different. There is no MMU tree 
anymore, instead it has a (very limited) number of page descriptors in 
the MMU itself. Every time the processor tries to access a memory 
address where the MMU has no current page descriptor available, the 
processor issues an exception. The exception code then must either 
replace one of the existing descriptors with a new one "manually" using 
a LRU scheme and restart the interrupted routine or issue an access/bus 
error.
Thus, the MiNT implementation of memory protection for Coldfires would 
need to kind of mimic the static MMU trees of the m68k MMUs in software. 
A straightforward implementation of 8k (MiNT's default page size) pages 
would require at least one byte per page descriptor, resulting in a 64k 
table for each process to just cover the 512 MBytes of TT RAM the 
FireBee has (not to mention ST RAM and I/O areas).
To limit the number of necessary page descriptors (and their memory 
usage), Coldfires allow larger (and variable) page sizes (up to 1 
MByte). BaS and FireTOS already use 1 MByte pages while MiNT needs 8k 
pages (which is luckily supported by the Coldfire MMU in hardware), thus 
the memory protection code would likely need to be able to deal with 
variable page sizes as well.
There's yet another pitfall:due to the way page faults are handled on 
Coldfires (exception code needs to deal with them) and MMU inner 
workings (automatic LRU replacement scheme) it's entirely possible that 
an "automatic" LRU replacement of a page descriptor"steals" the page 
where the supervisor stack resides. The next page fault would then end 
in Nirwana (double bus fault) since it would have no stack page 
available needed to push the exception stack frame to.
BaS and FireTOS have very limited support of this situation, today it 
more or less just works by accident due to relatively large page size 
and relatively low load on the limited number of page descriptors the 
MMU can hold which results in low probability of getting lost of 
supervisor stack (it's touched often enough in "normal" code to keep it 
from getting stolen).
A small test I once did by just changing current 1 MByte page size to 8k 
pages immediately led to a fatal crash.
MiNT memory protection thus would also need to deal with that and ensure 
that no process would get lost of its supervisor stack memory page and 
would always have the next lower page available as well (since the stack 
could then span across more than one page if we reduced page size).
I'm not saying it would be impossible (it definitely could be made), 
it's just that its a _real huge_ load of work.
Cheers,
Markus

Am 23.08.2015 um 08:55 schrieb wittau@lnxnt.org:
Dear MiNT developers,

sadly there is still no memory protection for the ColdFire CPU. As some
other developers are highly demanding that feature, and would have a much
easier live if FreeMiNT would run with memory protection as well at
ColdFire CPUs, I wanted to ask if somebody could code that?
I got informed that there are no problems to expect, but "just" new code
has to be written for the CF MMU as it is different to 040/060 MMU which
again is different from the 030 MMU.


Mathias
------------------
http://firebee.org