CPU plugins are code fragment resources that allow the NanoKernel to
perform CPU-specific functions, such as starting or stopping a processor
core or getting core temperature. They live in the Apple CPU Plugins
file. The Power Manager selects a plugin at boot (or doesn't), prepares
and holds it in memory, and registers it with the NanoKernel using
MPRegisterCpuPlugin(). The NanoKernel can then call any of the plugin's
entry points synchronously using its SIGP() function, which is also
exposed via the MPCpuPlugin() call. The plugin return path is tricky,
but involved the ReturnFromInterrupt trap instruction in the emulator
ROM code.
The CPU plugin calling convention is described in the SIGP comments. CPU
plugins operate in the blue address space, but with interrupts disabled
and supervisor mode on.
This code was reversed to get the Mac mini working. It is not clear how
the Power Manager determines CPU temperature when there are no CPU
registers to do this.
VeryPopularFunction (now GetPARPageInfo) takes a page number in the PAR
and returns a bunch of info on it. The flags of the PTE are copied into
cr5-cr7 of the condition register so that VMCalls can easily make
decisions off of them. I had already figured out the bit flags of the
PTEs Mac OS 9 uses when I reversed PagingFunc1. The definitions are in
the end of the 'Area Definitions.txt' file I sent you a while ago.
If you see a ' bltl cr5, VMDoSomethingWithTLB' (now RemovePageFromTLB)
followed by a ' bltl cr5, major_0x09b40' (now RemovePTEFromHTAB), you
know that the function is manipulating pages directly. RemovePageFromTLB
clears a page from the TLB if it follows a VeryPopularFunction call.
RemovePTEFromHTAB takes a page that is resident in the HTAB and removes
its HTAB entry. cr5_lt is bit 20 (mask 0x800), which my notes tell me is
set when the PTE is in the HTAB. Altogether, the sequence translates to
'if the page is in the HTAB, flush it from the TLB and delete its HTAB
entry'. VMExchangePages uses this (twice) to make sure there are no race
conditions when it is swapping the data in the pages.
I still don't have proof, but I am very very strongly convinced that
KDP.FlatPageListPointer is always equal to the PAR's PageMapArrayPtr.
On an unrelated note, KCMapPage seems to always panic when called on an
area where the PageMapArrayPtr is 2d. I have absolutely no idea why this
happens, but it is bad news for MPMapper because the threshold for
2-dimensionality is around 1 MB. I would have to make 512 separate
CreateArea calls to map all the memory without the NK panicking. I will
have to look into this.
Namely queues, semaphores, critical regions, event groups and
"notifications". The MP calls implementing these services have been
named after their MPLibrary wrapper functions. This convention will be
followed in the future (no more NKCreateEvent).
