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