Macintosh-SW/powermac-rom
1
0
Fork 0
mirror of https://github.com/elliotnunn/powermac-rom.git synced 2024-07-10 18:28:57 +00:00
Code Issues Projects Releases Wiki Activity
7c05aaf190
powermac-rom/NanoKernel/NKLegacyVM.s

1162 lines
23 KiB
ArmAsm
Raw Normal View History

Auto-generate per-file function lists
2018-06-30 08:00:35 +00:00
; AUTO-GENERATED SYMBOL LIST
; IMPORTS:
Split up NKInterrupts.s
2018-07-04 11:26:33 +00:00
; NKExceptions
lots of architectural work
2018-07-27 08:41:59 +00:00
; ReturnFromInt
Auto-generate per-file function lists
2018-06-30 08:00:35 +00:00
; NKPaging
memretry in some shape
2018-07-24 04:56:38 +00:00
; PutPTE
Auto-generate per-file function lists
2018-06-30 08:00:35 +00:00
; EXPORTS:
; EditPTEInHTAB (=> NKMPCalls)
; GetPARPageInfo (=> NKMPCalls)
; VMSecondLastExportedFunc (=> NKMPCalls)
; kcVMDispatch (=> NKInit)
much nicer
2018-07-28 05:37:20 +00:00
########################################################################
Auto-generate per-file function lists
2018-06-30 08:00:35 +00:00
Initial commit
2017-11-19 04:11:07 +00:00
MaxVMCallCount equ 26
MACRO
DeclareVMCall &n, &code
@h
common sense reform to v1 for v2 for v1 large vm diff getting shape correct Local_Panic -> VMPanic kdp revert to v1 teensy fix byte-perfect
2018-07-02 16:12:09 +00:00
org VMDispatchTable + &n * 2
much nicer
2018-07-28 05:37:20 +00:00
dc.w &code - CodeBase - &n * 2
Initial commit
2017-11-19 04:11:07 +00:00
org @h
ENDM
; Accessed ONLY via Sup table
correct symbol locations
2018-07-06 13:56:33 +00:00
KCallVMDispatch ; OUTSIDE REFERER
Initial commit
2017-11-19 04:11:07 +00:00
common sense reform to v1 for v2 for v1 large vm diff getting shape correct Local_Panic -> VMPanic kdp revert to v1 teensy fix byte-perfect
2018-07-02 16:12:09 +00:00
stw r7, KDP.Flags(r1)
everything perfect except one last MR table
2018-07-24 11:43:17 +00:00
lwz r7, KDP.CodeBase(r1)
Initial commit
2017-11-19 04:11:07 +00:00
cmplwi r3, MaxVMCallCount
common sense reform to v1 for v2 for v1 large vm diff getting shape correct Local_Panic -> VMPanic kdp revert to v1 teensy fix byte-perfect
2018-07-02 16:12:09 +00:00
insrwi r7, r3, 7, 24
much nicer
2018-07-28 05:37:20 +00:00
lhz r8, VMDispatchTable - CodeBase(r7)
Lots of work on Address Spaces
2018-04-23 15:22:55 +00:00
lwz r9, KDP.VMLogicalPages(r1)
Initial commit
2017-11-19 04:11:07 +00:00
add r8, r8, r7
mtlr r8
ewa and other fixes
2018-07-15 10:30:41 +00:00
lwz r6, KDP.r6(r1)
stw r14, KDP.r14(r1)
stw r15, KDP.r15(r1)
stw r16, KDP.r16(r1)
common sense reform to v1 for v2 for v1 large vm diff getting shape correct Local_Panic -> VMPanic kdp revert to v1 teensy fix byte-perfect
2018-07-02 16:12:09 +00:00
bltlr
b VMReturnMinus1
VMDispatchTable
dcb.w MaxVMCallCount, 0
Initial commit
2017-11-19 04:11:07 +00:00
; UNIMPLEMENTED kcVMDispatch selectors:
; VMUnInit: 'un-init the MMU virtual space'
DeclareVMCall 1, VMReturn
common sense reform to v1 for v2 for v1 large vm diff getting shape correct Local_Panic -> VMPanic kdp revert to v1 teensy fix byte-perfect
2018-07-02 16:12:09 +00:00
; VMFinalInit: 'last chance to init after new memory dispatch is installed'
DeclareVMCall 2, VMReturn
memretry in some shape
2018-07-24 04:56:38 +00:00
; VMGetPhysicaless: 'return phys address given log page (can be different from above!)'
Initial commit
2017-11-19 04:11:07 +00:00
; ('above' means VMGetPhysicalPage)
common sense reform to v1 for v2 for v1 large vm diff getting shape correct Local_Panic -> VMPanic kdp revert to v1 teensy fix byte-perfect
2018-07-02 16:12:09 +00:00
DeclareVMCall 11, VMReturnMinus1
Initial commit
2017-11-19 04:11:07 +00:00
; VMReload: 'reload the ATC with specified page'
DeclareVMCall 13, VMReturn
; VMFlushAddressTranslationCache: 'just do it'
DeclareVMCall 14, VMReturn
; VMFlushDataCache: 'wack the data cache'
DeclareVMCall 15, VMReturn
; VMFlushCodeCache: 'wack the code cache'
DeclareVMCall 16, VMReturn
; VMReturn
memretry in some shape
2018-07-24 04:56:38 +00:00
; VMGetPhysicaless_one
Initial commit
2017-11-19 04:11:07 +00:00
VMReturnMinus1 ; OUTSIDE REFERER
li r3, -0x01
b VMReturn
VMReturn0 ; OUTSIDE REFERER
li r3, 0x00
b VMReturn
VMReturn1 ; OUTSIDE REFERER
li r3, 0x01
VMReturn ; OUTSIDE REFERER
ewa and other fixes
2018-07-15 10:30:41 +00:00
lwz r14, KDP.r14(r1)
lwz r15, KDP.r15(r1)
lwz r16, KDP.r16(r1)
common sense reform to v1 for v2 for v1 large vm diff getting shape correct Local_Panic -> VMPanic kdp revert to v1 teensy fix byte-perfect
2018-07-02 16:12:09 +00:00
lwz r7, KDP.Flags(r1)
lots of architectural work
2018-07-27 08:41:59 +00:00
lwz r6, KDP.ContextPtr(r1)
b ReturnFromInt
Initial commit
2017-11-19 04:11:07 +00:00
; 'init the MMU virtual space'
common sense reform to v1 for v2 for v1 large vm diff getting shape correct Local_Panic -> VMPanic kdp revert to v1 teensy fix byte-perfect
2018-07-02 16:12:09 +00:00
DeclareVMCall 0, VMInit
Initial commit
2017-11-19 04:11:07 +00:00
VMInit ; OUTSIDE REFERER
looks good
2018-07-06 13:44:52 +00:00
lwz r7, KDP.PARPageListPtr(r1) ; check that zero seg isn't empty
happy
2018-07-06 13:30:48 +00:00
lwz r8, KDP.PARPerSegmentPLEPtrs + 0(r1)
Initial commit
2017-11-19 04:11:07 +00:00
cmpw r7, r8
Remove unnecessary static branch hints These + and - characters in a branch mnemonic can cause the assembler to produce conditional branch instructions with that hint the branch predictor. The default for forward branches is -, and for backward branches is +. If a mnemonic is issued with the opposite sign, then bit 10 of the instruction (the LSB of the BO field) is set. My long-retired "ppcdisasm" script inserted these hints unconditionally, despite 98% of them not being required. The code is much cleaner now. I read in some old MPW release notes that PPCAsm and PPCLink together exhibit a quirk when linking conditional branches to imported symbols. PPCAsm always assembles these conditional branches as if they were forward branches (that is, a + hint will always set the hint bit, and a - hint will never). I hoped to use this property to divine whether the NanoKernel was linked from one or many assembly files, but I was frustrated by the lack of conditional branches between files.
2018-04-15 07:05:02 +00:00
bne VMReturn1
Start to reverse the legacy VM subsystem
2018-02-03 12:56:13 +00:00
Lots of work on Address Spaces
2018-04-23 15:22:55 +00:00
stw r4, KDP.VMLogicalPages(r1) ; resize PAR
Start to reverse the legacy VM subsystem
2018-02-03 12:56:13 +00:00
looks good
2018-07-06 13:44:52 +00:00
stw r5, KDP.PARPageListPtr(r1) ; where did NK find this???
Start to reverse the legacy VM subsystem
2018-02-03 12:56:13 +00:00
memretry in some shape
2018-07-24 04:56:38 +00:00
lwz r6, KDP.CurMap.SegMapPtr(r1)
Initial commit
2017-11-19 04:11:07 +00:00
li r5, 0x00
li r4, 0x00
Start to reverse the legacy VM subsystem
2018-02-03 12:56:13 +00:00
VMInit_BigLoop
Initial commit
2017-11-19 04:11:07 +00:00
lwz r8, 0x0000(r6)
addi r6, r6, 0x08
lhz r3, 0x0000(r8)
lhz r7, 0x0002(r8)
lwz r8, 0x0004(r8)
addi r7, r7, 0x01
cmpwi cr1, r3, 0x00
andi. r3, r8, 0xc00
cmpwi r3, 0xc00
Remove unnecessary static branch hints These + and - characters in a branch mnemonic can cause the assembler to produce conditional branch instructions with that hint the branch predictor. The default for forward branches is -, and for backward branches is +. If a mnemonic is issued with the opposite sign, then bit 10 of the instruction (the LSB of the BO field) is set. My long-retired "ppcdisasm" script inserted these hints unconditionally, despite 98% of them not being required. The code is much cleaner now. I read in some old MPW release notes that PPCAsm and PPCLink together exhibit a quirk when linking conditional branches to imported symbols. PPCAsm always assembles these conditional branches as if they were forward branches (that is, a + hint will always set the hint bit, and a - hint will never). I hoped to use this property to divine whether the NanoKernel was linked from one or many assembly files, but I was frustrated by the lack of conditional branches between files.
2018-04-15 07:05:02 +00:00
bne VMInit_0x110
fixes
2018-07-15 09:34:52 +00:00
bnel cr1, SystemCrash
Initial commit
2017-11-19 04:11:07 +00:00
rlwinm r15, r8, 22, 0, 29
happy
2018-07-06 13:30:48 +00:00
addi r3, r1, KDP.PARPerSegmentPLEPtrs
Initial commit
2017-11-19 04:11:07 +00:00
rlwimi r3, r5, 2, 28, 29
stw r15, 0x0000(r3)
slwi r3, r5, 16
cmpw r3, r4
fixes
2018-07-15 09:34:52 +00:00
bnel SystemCrash
Initial commit
2017-11-19 04:11:07 +00:00
VMInit_0xa8
lwz r16, 0x0000(r15)
addi r7, r7, -0x01
andi. r3, r16, 0x01
fixes
2018-07-15 09:34:52 +00:00
beql SystemCrash
Initial commit
2017-11-19 04:11:07 +00:00
andi. r3, r16, 0x800
Remove unnecessary static branch hints These + and - characters in a branch mnemonic can cause the assembler to produce conditional branch instructions with that hint the branch predictor. The default for forward branches is -, and for backward branches is +. If a mnemonic is issued with the opposite sign, then bit 10 of the instruction (the LSB of the BO field) is set. My long-retired "ppcdisasm" script inserted these hints unconditionally, despite 98% of them not being required. The code is much cleaner now. I read in some old MPW release notes that PPCAsm and PPCLink together exhibit a quirk when linking conditional branches to imported symbols. PPCAsm always assembles these conditional branches as if they were forward branches (that is, a + hint will always set the hint bit, and a - hint will never). I hoped to use this property to divine whether the NanoKernel was linked from one or many assembly files, but I was frustrated by the lack of conditional branches between files.
2018-04-15 07:05:02 +00:00
beq VMInit_0x100
Start to reverse the legacy VM subsystem
2018-02-03 12:56:13 +00:00
lwz r14, KDP.HTABORG(r1)
Initial commit
2017-11-19 04:11:07 +00:00
rlwinm r3, r16, 23, 9, 28
lwzux r8, r14, r3
lwz r9, 0x0004(r14)
andis. r3, r8, 0x8000
fixes
2018-07-15 09:34:52 +00:00
beql SystemCrash
Initial commit
2017-11-19 04:11:07 +00:00
andi. r3, r9, 0x03
cmpwi r3, 0x00
fixes
2018-07-15 09:34:52 +00:00
beql SystemCrash
Initial commit
2017-11-19 04:11:07 +00:00
rlwinm r3, r16, 17, 22, 31
rlwimi r3, r8, 10, 16, 21
rlwimi r3, r8, 21, 12, 15
cmpw r3, r4
fixes
2018-07-15 09:34:52 +00:00
bnel SystemCrash
common sense reform to v1 for v2 for v1 large vm diff getting shape correct Local_Panic -> VMPanic kdp revert to v1 teensy fix byte-perfect
2018-07-02 16:12:09 +00:00
; bl RemovePageFromTLB
Reverse some VM functions (Daniel) 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.
2018-02-18 03:17:23 +00:00
bl RemovePTEFromHTAB
Initial commit
2017-11-19 04:11:07 +00:00
VMInit_0x100
cmpwi r7, 0x00
addi r15, r15, 0x04
addi r4, r4, 0x01
Remove unnecessary static branch hints These + and - characters in a branch mnemonic can cause the assembler to produce conditional branch instructions with that hint the branch predictor. The default for forward branches is -, and for backward branches is +. If a mnemonic is issued with the opposite sign, then bit 10 of the instruction (the LSB of the BO field) is set. My long-retired "ppcdisasm" script inserted these hints unconditionally, despite 98% of them not being required. The code is much cleaner now. I read in some old MPW release notes that PPCAsm and PPCLink together exhibit a quirk when linking conditional branches to imported symbols. PPCAsm always assembles these conditional branches as if they were forward branches (that is, a + hint will always set the hint bit, and a - hint will never). I hoped to use this property to divine whether the NanoKernel was linked from one or many assembly files, but I was frustrated by the lack of conditional branches between files.
2018-04-15 07:05:02 +00:00
bne VMInit_0xa8
Initial commit
2017-11-19 04:11:07 +00:00
VMInit_0x110
addi r5, r5, 0x01
common sense reform to v1 for v2 for v1 large vm diff getting shape correct Local_Panic -> VMPanic kdp revert to v1 teensy fix byte-perfect
2018-07-02 16:12:09 +00:00
cmpwi r5, 4
bne VMInit_BigLoop
Start to reverse the legacy VM subsystem
2018-02-03 12:56:13 +00:00
lwz r7, KDP.TotalPhysicalPages(r1)
Initial commit
2017-11-19 04:11:07 +00:00
cmpw r4, r7
fixes
2018-07-15 09:34:52 +00:00
bnel SystemCrash
looks good
2018-07-06 13:44:52 +00:00
lwz r5, KDP.PARPageListPtr(r1)
Lots of work on Address Spaces
2018-04-23 15:22:55 +00:00
lwz r4, KDP.VMLogicalPages(r1)
Initial commit
2017-11-19 04:11:07 +00:00
andi. r7, r5, 0xfff
Start to reverse the legacy VM subsystem
2018-02-03 12:56:13 +00:00
Initial commit
2017-11-19 04:11:07 +00:00
li r3, 0x02
Remove unnecessary static branch hints These + and - characters in a branch mnemonic can cause the assembler to produce conditional branch instructions with that hint the branch predictor. The default for forward branches is -, and for backward branches is +. If a mnemonic is issued with the opposite sign, then bit 10 of the instruction (the LSB of the BO field) is set. My long-retired "ppcdisasm" script inserted these hints unconditionally, despite 98% of them not being required. The code is much cleaner now. I read in some old MPW release notes that PPCAsm and PPCLink together exhibit a quirk when linking conditional branches to imported symbols. PPCAsm always assembles these conditional branches as if they were forward branches (that is, a + hint will always set the hint bit, and a - hint will never). I hoped to use this property to divine whether the NanoKernel was linked from one or many assembly files, but I was frustrated by the lack of conditional branches between files.
2018-04-15 07:05:02 +00:00
bne VMInit_Fail
Start to reverse the legacy VM subsystem
2018-02-03 12:56:13 +00:00
common sense reform to v1 for v2 for v1 large vm diff getting shape correct Local_Panic -> VMPanic kdp revert to v1 teensy fix byte-perfect
2018-07-02 16:12:09 +00:00
lis r7, 4
Initial commit
2017-11-19 04:11:07 +00:00
cmplw r7, r4
Start to reverse the legacy VM subsystem
2018-02-03 12:56:13 +00:00
Initial commit
2017-11-19 04:11:07 +00:00
li r3, 0x03
Remove unnecessary static branch hints These + and - characters in a branch mnemonic can cause the assembler to produce conditional branch instructions with that hint the branch predictor. The default for forward branches is -, and for backward branches is +. If a mnemonic is issued with the opposite sign, then bit 10 of the instruction (the LSB of the BO field) is set. My long-retired "ppcdisasm" script inserted these hints unconditionally, despite 98% of them not being required. The code is much cleaner now. I read in some old MPW release notes that PPCAsm and PPCLink together exhibit a quirk when linking conditional branches to imported symbols. PPCAsm always assembles these conditional branches as if they were forward branches (that is, a + hint will always set the hint bit, and a - hint will never). I hoped to use this property to divine whether the NanoKernel was linked from one or many assembly files, but I was frustrated by the lack of conditional branches between files.
2018-04-15 07:05:02 +00:00
blt VMInit_Fail
Start to reverse the legacy VM subsystem
2018-02-03 12:56:13 +00:00
Initial commit
2017-11-19 04:11:07 +00:00
addi r7, r4, 0x3ff
srwi r6, r7, 10
srwi r8, r5, 12
add r8, r8, r6
Start to reverse the legacy VM subsystem
2018-02-03 12:56:13 +00:00
lwz r9, KDP.TotalPhysicalPages(r1)
Initial commit
2017-11-19 04:11:07 +00:00
cmplw r8, r9
Start to reverse the legacy VM subsystem
2018-02-03 12:56:13 +00:00
Initial commit
2017-11-19 04:11:07 +00:00
li r3, 0x04
Remove unnecessary static branch hints These + and - characters in a branch mnemonic can cause the assembler to produce conditional branch instructions with that hint the branch predictor. The default for forward branches is -, and for backward branches is +. If a mnemonic is issued with the opposite sign, then bit 10 of the instruction (the LSB of the BO field) is set. My long-retired "ppcdisasm" script inserted these hints unconditionally, despite 98% of them not being required. The code is much cleaner now. I read in some old MPW release notes that PPCAsm and PPCLink together exhibit a quirk when linking conditional branches to imported symbols. PPCAsm always assembles these conditional branches as if they were forward branches (that is, a + hint will always set the hint bit, and a - hint will never). I hoped to use this property to divine whether the NanoKernel was linked from one or many assembly files, but I was frustrated by the lack of conditional branches between files.
2018-04-15 07:05:02 +00:00
bgt VMInit_Fail
Start to reverse the legacy VM subsystem
2018-02-03 12:56:13 +00:00
Initial commit
2017-11-19 04:11:07 +00:00
cmplw r4, r9
Start to reverse the legacy VM subsystem
2018-02-03 12:56:13 +00:00
Initial commit
2017-11-19 04:11:07 +00:00
li r3, 0x05
Remove unnecessary static branch hints These + and - characters in a branch mnemonic can cause the assembler to produce conditional branch instructions with that hint the branch predictor. The default for forward branches is -, and for backward branches is +. If a mnemonic is issued with the opposite sign, then bit 10 of the instruction (the LSB of the BO field) is set. My long-retired "ppcdisasm" script inserted these hints unconditionally, despite 98% of them not being required. The code is much cleaner now. I read in some old MPW release notes that PPCAsm and PPCLink together exhibit a quirk when linking conditional branches to imported symbols. PPCAsm always assembles these conditional branches as if they were forward branches (that is, a + hint will always set the hint bit, and a - hint will never). I hoped to use this property to divine whether the NanoKernel was linked from one or many assembly files, but I was frustrated by the lack of conditional branches between files.
2018-04-15 07:05:02 +00:00
blt VMInit_Fail
Start to reverse the legacy VM subsystem
2018-02-03 12:56:13 +00:00
Initial commit
2017-11-19 04:11:07 +00:00
srwi r7, r5, 12
bl major_0x09c9c
looks good
2018-07-06 13:44:52 +00:00
stw r9, KDP.PARPageListPtr(r1)
Initial commit
2017-11-19 04:11:07 +00:00
mr r15, r9
srwi r7, r5, 12
add r7, r7, r6
addi r7, r7, -0x01
bl major_0x09c9c
subf r9, r15, r9
srwi r9, r9, 12
addi r9, r9, 0x01
cmpw r9, r6
Start to reverse the legacy VM subsystem
2018-02-03 12:56:13 +00:00
Initial commit
2017-11-19 04:11:07 +00:00
li r3, 0x06
Remove unnecessary static branch hints These + and - characters in a branch mnemonic can cause the assembler to produce conditional branch instructions with that hint the branch predictor. The default for forward branches is -, and for backward branches is +. If a mnemonic is issued with the opposite sign, then bit 10 of the instruction (the LSB of the BO field) is set. My long-retired "ppcdisasm" script inserted these hints unconditionally, despite 98% of them not being required. The code is much cleaner now. I read in some old MPW release notes that PPCAsm and PPCLink together exhibit a quirk when linking conditional branches to imported symbols. PPCAsm always assembles these conditional branches as if they were forward branches (that is, a + hint will always set the hint bit, and a - hint will never). I hoped to use this property to divine whether the NanoKernel was linked from one or many assembly files, but I was frustrated by the lack of conditional branches between files.
2018-04-15 07:05:02 +00:00
bne VMInit_Fail
Start to reverse the legacy VM subsystem
2018-02-03 12:56:13 +00:00
Lots of work on Address Spaces
2018-04-23 15:22:55 +00:00
stw r4, KDP.VMLogicalPages(r1)
Initial commit
2017-11-19 04:11:07 +00:00
slwi r7, r4, 12
intelligent structures
2018-07-09 08:13:00 +00:00
stw r7, KDP.SysInfo.LogicalMemorySize(r1) ; bug in NKv2??
Initial commit
2017-11-19 04:11:07 +00:00
slwi r7, r4, 2
li r8, 0x00
VMInit_0x1d4
subi r7, r7, 4
cmpwi r7, 0x00
stwx r8, r15, r7
Remove unnecessary static branch hints These + and - characters in a branch mnemonic can cause the assembler to produce conditional branch instructions with that hint the branch predictor. The default for forward branches is -, and for backward branches is +. If a mnemonic is issued with the opposite sign, then bit 10 of the instruction (the LSB of the BO field) is set. My long-retired "ppcdisasm" script inserted these hints unconditionally, despite 98% of them not being required. The code is much cleaner now. I read in some old MPW release notes that PPCAsm and PPCLink together exhibit a quirk when linking conditional branches to imported symbols. PPCAsm always assembles these conditional branches as if they were forward branches (that is, a + hint will always set the hint bit, and a - hint will never). I hoped to use this property to divine whether the NanoKernel was linked from one or many assembly files, but I was frustrated by the lack of conditional branches between files.
2018-04-15 07:05:02 +00:00
bne VMInit_0x1d4
Start to reverse the legacy VM subsystem
2018-02-03 12:56:13 +00:00
lwz r7, KDP.TotalPhysicalPages(r1)
Initial commit
2017-11-19 04:11:07 +00:00
slwi r6, r7, 2
VMInit_0x1ec
subi r6, r6, 4
srwi r7, r6, 2
bl major_0x09c9c
cmpwi r6, 0x00
ori r16, r9, 0x21
stwx r16, r15, r6
Remove unnecessary static branch hints These + and - characters in a branch mnemonic can cause the assembler to produce conditional branch instructions with that hint the branch predictor. The default for forward branches is -, and for backward branches is +. If a mnemonic is issued with the opposite sign, then bit 10 of the instruction (the LSB of the BO field) is set. My long-retired "ppcdisasm" script inserted these hints unconditionally, despite 98% of them not being required. The code is much cleaner now. I read in some old MPW release notes that PPCAsm and PPCLink together exhibit a quirk when linking conditional branches to imported symbols. PPCAsm always assembles these conditional branches as if they were forward branches (that is, a + hint will always set the hint bit, and a - hint will never). I hoped to use this property to divine whether the NanoKernel was linked from one or many assembly files, but I was frustrated by the lack of conditional branches between files.
2018-04-15 07:05:02 +00:00
bne VMInit_0x1ec
looks good
2018-07-06 13:44:52 +00:00
lwz r15, KDP.PARPageListPtr(r1)
Initial commit
2017-11-19 04:11:07 +00:00
srwi r7, r5, 10
add r15, r15, r7
Lots of work on Address Spaces
2018-04-23 15:22:55 +00:00
lwz r5, KDP.VMLogicalPages(r1)
Initial commit
2017-11-19 04:11:07 +00:00
VMInit_0x218
lwz r16, 0x0000(r15)
andi. r7, r16, 0x01
fixes
2018-07-15 09:34:52 +00:00
beql SystemCrash
Initial commit
2017-11-19 04:11:07 +00:00
ori r16, r16, 0x404
stw r16, 0x0000(r15)
addi r5, r5, -0x400
cmpwi r5, 0x00
addi r15, r15, 0x04
Remove unnecessary static branch hints These + and - characters in a branch mnemonic can cause the assembler to produce conditional branch instructions with that hint the branch predictor. The default for forward branches is -, and for backward branches is +. If a mnemonic is issued with the opposite sign, then bit 10 of the instruction (the LSB of the BO field) is set. My long-retired "ppcdisasm" script inserted these hints unconditionally, despite 98% of them not being required. The code is much cleaner now. I read in some old MPW release notes that PPCAsm and PPCLink together exhibit a quirk when linking conditional branches to imported symbols. PPCAsm always assembles these conditional branches as if they were forward branches (that is, a + hint will always set the hint bit, and a - hint will never). I hoped to use this property to divine whether the NanoKernel was linked from one or many assembly files, but I was frustrated by the lack of conditional branches between files.
2018-04-15 07:05:02 +00:00
bgt VMInit_0x218
memretry in some shape
2018-07-24 04:56:38 +00:00
lwz r6, KDP.CurMap.SegMapPtr(r1)
common sense reform to v1 for v2 for v1 large vm diff getting shape correct Local_Panic -> VMPanic kdp revert to v1 teensy fix byte-perfect
2018-07-02 16:12:09 +00:00
li r9, 0
ori r7, r9, 0xffff
Initial commit
2017-11-19 04:11:07 +00:00
li r8, 0xa00
VMInit_0x250
lwz r3, 0x0000(r6)
addi r6, r6, 0x08
stw r7, 0x0000(r3)
stw r8, 0x0004(r3)
stw r7, 0x0008(r3)
stw r8, 0x000c(r3)
common sense reform to v1 for v2 for v1 large vm diff getting shape correct Local_Panic -> VMPanic kdp revert to v1 teensy fix byte-perfect
2018-07-02 16:12:09 +00:00
addi r9, r9, 1
cmpwi r9, 3
ble VMInit_0x250
memretry in some shape
2018-07-24 04:56:38 +00:00
lwz r6, KDP.CurMap.SegMapPtr(r1)
Lots of work on Address Spaces
2018-04-23 15:22:55 +00:00
lwz r9, KDP.VMLogicalPages(r1)
looks good
2018-07-06 13:44:52 +00:00
lwz r15, KDP.PARPageListPtr(r1)
Initial commit
2017-11-19 04:11:07 +00:00
VMInit_0x288
lwz r8, 0x0000(r6)
lis r7, 0x01
rlwinm. r3, r9, 16, 16, 31
Remove unnecessary static branch hints These + and - characters in a branch mnemonic can cause the assembler to produce conditional branch instructions with that hint the branch predictor. The default for forward branches is -, and for backward branches is +. If a mnemonic is issued with the opposite sign, then bit 10 of the instruction (the LSB of the BO field) is set. My long-retired "ppcdisasm" script inserted these hints unconditionally, despite 98% of them not being required. The code is much cleaner now. I read in some old MPW release notes that PPCAsm and PPCLink together exhibit a quirk when linking conditional branches to imported symbols. PPCAsm always assembles these conditional branches as if they were forward branches (that is, a + hint will always set the hint bit, and a - hint will never). I hoped to use this property to divine whether the NanoKernel was linked from one or many assembly files, but I was frustrated by the lack of conditional branches between files.
2018-04-15 07:05:02 +00:00
bne VMInit_0x29c
Initial commit
2017-11-19 04:11:07 +00:00
mr r7, r9
VMInit_0x29c
subf. r9, r7, r9
addi r7, r7, -0x01
stw r7, 0x0000(r8)
rlwinm r7, r15, 10, 22, 19
ori r7, r7, 0xc00
stw r7, 0x0004(r8)
addis r15, r15, 0x04
addi r6, r6, 0x08
Remove unnecessary static branch hints These + and - characters in a branch mnemonic can cause the assembler to produce conditional branch instructions with that hint the branch predictor. The default for forward branches is -, and for backward branches is +. If a mnemonic is issued with the opposite sign, then bit 10 of the instruction (the LSB of the BO field) is set. My long-retired "ppcdisasm" script inserted these hints unconditionally, despite 98% of them not being required. The code is much cleaner now. I read in some old MPW release notes that PPCAsm and PPCLink together exhibit a quirk when linking conditional branches to imported symbols. PPCAsm always assembles these conditional branches as if they were forward branches (that is, a + hint will always set the hint bit, and a - hint will never). I hoped to use this property to divine whether the NanoKernel was linked from one or many assembly files, but I was frustrated by the lack of conditional branches between files.
2018-04-15 07:05:02 +00:00
bne VMInit_0x288
Start to reverse the legacy VM subsystem
2018-02-03 12:56:13 +00:00
Initial commit
2017-11-19 04:11:07 +00:00
b VMReturn0
Start to reverse the legacy VM subsystem
2018-02-03 12:56:13 +00:00
VMInit_Fail
lwz r7, KDP.TotalPhysicalPages(r1)
happy
2018-07-06 13:30:48 +00:00
lwz r8, KDP.PARPerSegmentPLEPtrs + 0(r1)
Lots of work on Address Spaces
2018-04-23 15:22:55 +00:00
stw r7, KDP.VMLogicalPages(r1)
looks good
2018-07-06 13:44:52 +00:00
stw r8, KDP.PARPageListPtr(r1)
Start to reverse the legacy VM subsystem
2018-02-03 12:56:13 +00:00
Initial commit
2017-11-19 04:11:07 +00:00
b VMReturn
; 'exchange physical page contents'
common sense reform to v1 for v2 for v1 large vm diff getting shape correct Local_Panic -> VMPanic kdp revert to v1 teensy fix byte-perfect
2018-07-02 16:12:09 +00:00
DeclareVMCall 12, VMExchangePages
Initial commit
2017-11-19 04:11:07 +00:00
VMExchangePages ; OUTSIDE REFERER
Reverse some VM functions (Daniel) 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.
2018-02-18 03:17:23 +00:00
bl GetPARPageInfo
Remove unnecessary static branch hints These + and - characters in a branch mnemonic can cause the assembler to produce conditional branch instructions with that hint the branch predictor. The default for forward branches is -, and for backward branches is +. If a mnemonic is issued with the opposite sign, then bit 10 of the instruction (the LSB of the BO field) is set. My long-retired "ppcdisasm" script inserted these hints unconditionally, despite 98% of them not being required. The code is much cleaner now. I read in some old MPW release notes that PPCAsm and PPCLink together exhibit a quirk when linking conditional branches to imported symbols. PPCAsm always assembles these conditional branches as if they were forward branches (that is, a + hint will always set the hint bit, and a - hint will never). I hoped to use this property to divine whether the NanoKernel was linked from one or many assembly files, but I was frustrated by the lack of conditional branches between files.
2018-04-15 07:05:02 +00:00
bge cr4, VMReturnMinus1
bgt cr5, VMReturnMinus1
bns cr7, VMReturnMinus1
bgt cr6, VMReturnMinus1
bne cr6, VMReturnMinus1
common sense reform to v1 for v2 for v1 large vm diff getting shape correct Local_Panic -> VMPanic kdp revert to v1 teensy fix byte-perfect
2018-07-02 16:12:09 +00:00
; bltl cr5, RemovePageFromTLB
Remove unnecessary static branch hints These + and - characters in a branch mnemonic can cause the assembler to produce conditional branch instructions with that hint the branch predictor. The default for forward branches is -, and for backward branches is +. If a mnemonic is issued with the opposite sign, then bit 10 of the instruction (the LSB of the BO field) is set. My long-retired "ppcdisasm" script inserted these hints unconditionally, despite 98% of them not being required. The code is much cleaner now. I read in some old MPW release notes that PPCAsm and PPCLink together exhibit a quirk when linking conditional branches to imported symbols. PPCAsm always assembles these conditional branches as if they were forward branches (that is, a + hint will always set the hint bit, and a - hint will never). I hoped to use this property to divine whether the NanoKernel was linked from one or many assembly files, but I was frustrated by the lack of conditional branches between files.
2018-04-15 07:05:02 +00:00
bltl cr5, RemovePTEFromHTAB
Initial commit
2017-11-19 04:11:07 +00:00
mr r6, r15
mr r4, r5
mr r5, r16
Lots of work on Address Spaces
2018-04-23 15:22:55 +00:00
lwz r9, KDP.VMLogicalPages(r1)
Reverse some VM functions (Daniel) 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.
2018-02-18 03:17:23 +00:00
bl GetPARPageInfo
Remove unnecessary static branch hints These + and - characters in a branch mnemonic can cause the assembler to produce conditional branch instructions with that hint the branch predictor. The default for forward branches is -, and for backward branches is +. If a mnemonic is issued with the opposite sign, then bit 10 of the instruction (the LSB of the BO field) is set. My long-retired "ppcdisasm" script inserted these hints unconditionally, despite 98% of them not being required. The code is much cleaner now. I read in some old MPW release notes that PPCAsm and PPCLink together exhibit a quirk when linking conditional branches to imported symbols. PPCAsm always assembles these conditional branches as if they were forward branches (that is, a + hint will always set the hint bit, and a - hint will never). I hoped to use this property to divine whether the NanoKernel was linked from one or many assembly files, but I was frustrated by the lack of conditional branches between files.
2018-04-15 07:05:02 +00:00
bge cr4, VMReturnMinus1
bgt cr5, VMReturnMinus1
bns cr7, VMReturnMinus1
bgt cr6, VMReturnMinus1
bne cr6, VMReturnMinus1
common sense reform to v1 for v2 for v1 large vm diff getting shape correct Local_Panic -> VMPanic kdp revert to v1 teensy fix byte-perfect
2018-07-02 16:12:09 +00:00
; bltl cr5, RemovePageFromTLB
Remove unnecessary static branch hints These + and - characters in a branch mnemonic can cause the assembler to produce conditional branch instructions with that hint the branch predictor. The default for forward branches is -, and for backward branches is +. If a mnemonic is issued with the opposite sign, then bit 10 of the instruction (the LSB of the BO field) is set. My long-retired "ppcdisasm" script inserted these hints unconditionally, despite 98% of them not being required. The code is much cleaner now. I read in some old MPW release notes that PPCAsm and PPCLink together exhibit a quirk when linking conditional branches to imported symbols. PPCAsm always assembles these conditional branches as if they were forward branches (that is, a + hint will always set the hint bit, and a - hint will never). I hoped to use this property to divine whether the NanoKernel was linked from one or many assembly files, but I was frustrated by the lack of conditional branches between files.
2018-04-15 07:05:02 +00:00
bltl cr5, RemovePTEFromHTAB
Initial commit
2017-11-19 04:11:07 +00:00
stw r5, 0x0000(r15)
stw r16, 0x0000(r6)
rlwinm r4, r5, 0, 0, 19
rlwinm r5, r16, 0, 0, 19
li r9, 0x1000
li r6, 0x04
VMExchangePages_0x68
subf. r9, r6, r9
lwzx r7, r4, r9
lwzx r8, r5, r9
stwx r7, r5, r9
stwx r8, r4, r9
Remove unnecessary static branch hints These + and - characters in a branch mnemonic can cause the assembler to produce conditional branch instructions with that hint the branch predictor. The default for forward branches is -, and for backward branches is +. If a mnemonic is issued with the opposite sign, then bit 10 of the instruction (the LSB of the BO field) is set. My long-retired "ppcdisasm" script inserted these hints unconditionally, despite 98% of them not being required. The code is much cleaner now. I read in some old MPW release notes that PPCAsm and PPCLink together exhibit a quirk when linking conditional branches to imported symbols. PPCAsm always assembles these conditional branches as if they were forward branches (that is, a + hint will always set the hint bit, and a - hint will never). I hoped to use this property to divine whether the NanoKernel was linked from one or many assembly files, but I was frustrated by the lack of conditional branches between files.
2018-04-15 07:05:02 +00:00
bne VMExchangePages_0x68
Initial commit
2017-11-19 04:11:07 +00:00
b VMReturn
; 'return phys page given log page'
DeclareVMCall 10, VMGetPhysicalPage
VMGetPhysicalPage ; OUTSIDE REFERER
Reverse some VM functions (Daniel) 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.
2018-02-18 03:17:23 +00:00
bl GetPARPageInfo
Remove unnecessary static branch hints These + and - characters in a branch mnemonic can cause the assembler to produce conditional branch instructions with that hint the branch predictor. The default for forward branches is -, and for backward branches is +. If a mnemonic is issued with the opposite sign, then bit 10 of the instruction (the LSB of the BO field) is set. My long-retired "ppcdisasm" script inserted these hints unconditionally, despite 98% of them not being required. The code is much cleaner now. I read in some old MPW release notes that PPCAsm and PPCLink together exhibit a quirk when linking conditional branches to imported symbols. PPCAsm always assembles these conditional branches as if they were forward branches (that is, a + hint will always set the hint bit, and a - hint will never). I hoped to use this property to divine whether the NanoKernel was linked from one or many assembly files, but I was frustrated by the lack of conditional branches between files.
2018-04-15 07:05:02 +00:00
bns cr7, VMReturnMinus1
Initial commit
2017-11-19 04:11:07 +00:00
srwi r3, r9, 12
b VMReturn
; 'given a page, get its 68K PTE'
DeclareVMCall 19, getPTEntryGivenPage
getPTEntryGivenPage ; OUTSIDE REFERER
Reverse some VM functions (Daniel) 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.
2018-02-18 03:17:23 +00:00
bl GetPARPageInfo
Initial commit
2017-11-19 04:11:07 +00:00
mr r3, r16
common sense reform to v1 for v2 for v1 large vm diff getting shape correct Local_Panic -> VMPanic kdp revert to v1 teensy fix byte-perfect
2018-07-02 16:12:09 +00:00
bns cr7, VMReturn
Initial commit
2017-11-19 04:11:07 +00:00
rlwimi r3, r9, 0, 0, 19
b VMReturn
; 'ask about page status' (typo?)
common sense reform to v1 for v2 for v1 large vm diff getting shape correct Local_Panic -> VMPanic kdp revert to v1 teensy fix byte-perfect
2018-07-02 16:12:09 +00:00
DeclareVMCall 5, VMIsInited
Initial commit
2017-11-19 04:11:07 +00:00
VMIsInited ; OUTSIDE REFERER
Reverse some VM functions (Daniel) 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.
2018-02-18 03:17:23 +00:00
bl GetPARPageInfo
Remove unnecessary static branch hints These + and - characters in a branch mnemonic can cause the assembler to produce conditional branch instructions with that hint the branch predictor. The default for forward branches is -, and for backward branches is +. If a mnemonic is issued with the opposite sign, then bit 10 of the instruction (the LSB of the BO field) is set. My long-retired "ppcdisasm" script inserted these hints unconditionally, despite 98% of them not being required. The code is much cleaner now. I read in some old MPW release notes that PPCAsm and PPCLink together exhibit a quirk when linking conditional branches to imported symbols. PPCAsm always assembles these conditional branches as if they were forward branches (that is, a + hint will always set the hint bit, and a - hint will never). I hoped to use this property to divine whether the NanoKernel was linked from one or many assembly files, but I was frustrated by the lack of conditional branches between files.
2018-04-15 07:05:02 +00:00
bso cr7, VMReturn1
Initial commit
2017-11-19 04:11:07 +00:00
rlwinm r3, r16, 16, 31, 31
b VMReturn
; 'ask about page status' (typo?)
DeclareVMCall 3, VMIsResident
VMIsResident ; OUTSIDE REFERER
Reverse some VM functions (Daniel) 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.
2018-02-18 03:17:23 +00:00
bl GetPARPageInfo
Initial commit
2017-11-19 04:11:07 +00:00
clrlwi r3, r16, 0x1f
b VMReturn
; 'ask about page status' (typo?)
common sense reform to v1 for v2 for v1 large vm diff getting shape correct Local_Panic -> VMPanic kdp revert to v1 teensy fix byte-perfect
2018-07-02 16:12:09 +00:00
DeclareVMCall 4, VMIsUnmodified
Initial commit
2017-11-19 04:11:07 +00:00
VMIsUnmodified ; OUTSIDE REFERER
Reverse some VM functions (Daniel) 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.
2018-02-18 03:17:23 +00:00
bl GetPARPageInfo
Initial commit
2017-11-19 04:11:07 +00:00
rlwinm r3, r16, 28, 31, 31
xori r3, r3, 0x01
b VMReturn
; Cube-E has no comment
common sense reform to v1 for v2 for v1 large vm diff getting shape correct Local_Panic -> VMPanic kdp revert to v1 teensy fix byte-perfect
2018-07-02 16:12:09 +00:00
DeclareVMCall 22, VMLRU
Initial commit
2017-11-19 04:11:07 +00:00
VMLRU ; OUTSIDE REFERER
rlwinm. r9, r9, 2, 0, 29
looks good
2018-07-06 13:44:52 +00:00
lwz r15, KDP.PARPageListPtr(r1)
Start to reverse the legacy VM subsystem
2018-02-03 12:56:13 +00:00
lwz r14, KDP.HTABORG(r1)
Initial commit
2017-11-19 04:11:07 +00:00
add r15, r15, r9
srwi r4, r9, 2
li r5, 0x100
li r6, 0x08
VMLRU_0x1c
lwzu r16, -0x0004(r15)
addi r4, r4, -0x01
common sense reform to v1 for v2 for v1 large vm diff getting shape correct Local_Panic -> VMPanic kdp revert to v1 teensy fix byte-perfect
2018-07-02 16:12:09 +00:00
mtcr r16
Initial commit
2017-11-19 04:11:07 +00:00
cmpwi r4, 0x00
rlwinm r7, r16, 23, 9, 28
Remove unnecessary static branch hints These + and - characters in a branch mnemonic can cause the assembler to produce conditional branch instructions with that hint the branch predictor. The default for forward branches is -, and for backward branches is +. If a mnemonic is issued with the opposite sign, then bit 10 of the instruction (the LSB of the BO field) is set. My long-retired "ppcdisasm" script inserted these hints unconditionally, despite 98% of them not being required. The code is much cleaner now. I read in some old MPW release notes that PPCAsm and PPCLink together exhibit a quirk when linking conditional branches to imported symbols. PPCAsm always assembles these conditional branches as if they were forward branches (that is, a + hint will always set the hint bit, and a - hint will never). I hoped to use this property to divine whether the NanoKernel was linked from one or many assembly files, but I was frustrated by the lack of conditional branches between files.
2018-04-15 07:05:02 +00:00
bns cr7, VMLRU_0x5c
bge cr5, VMLRU_0x50
Initial commit
2017-11-19 04:11:07 +00:00
add r14, r14, r7
common sense reform to v1 for v2 for v1 large vm diff getting shape correct Local_Panic -> VMPanic kdp revert to v1 teensy fix byte-perfect
2018-07-02 16:12:09 +00:00
lwz r9, 4(r14)
rlwimi r16, r9, 27, 28, 28
Initial commit
2017-11-19 04:11:07 +00:00
andc r9, r9, r5
common sense reform to v1 for v2 for v1 large vm diff getting shape correct Local_Panic -> VMPanic kdp revert to v1 teensy fix byte-perfect
2018-07-02 16:12:09 +00:00
bl EditPTEOnlyInHTAB
Initial commit
2017-11-19 04:11:07 +00:00
subf r14, r7, r14
VMLRU_0x50
rlwimi r16, r16, 6, 22, 22
andc r16, r16, r6
stw r16, 0x0000(r15)
VMLRU_0x5c
Remove unnecessary static branch hints These + and - characters in a branch mnemonic can cause the assembler to produce conditional branch instructions with that hint the branch predictor. The default for forward branches is -, and for backward branches is +. If a mnemonic is issued with the opposite sign, then bit 10 of the instruction (the LSB of the BO field) is set. My long-retired "ppcdisasm" script inserted these hints unconditionally, despite 98% of them not being required. The code is much cleaner now. I read in some old MPW release notes that PPCAsm and PPCLink together exhibit a quirk when linking conditional branches to imported symbols. PPCAsm always assembles these conditional branches as if they were forward branches (that is, a + hint will always set the hint bit, and a - hint will never). I hoped to use this property to divine whether the NanoKernel was linked from one or many assembly files, but I was frustrated by the lack of conditional branches between files.
2018-04-15 07:05:02 +00:00
bne VMLRU_0x1c
Initial commit
2017-11-19 04:11:07 +00:00
b VMReturn
; 'make it so'
DeclareVMCall 17, VMMakePageCacheable
VMMakePageCacheable ; OUTSIDE REFERER
Reverse some VM functions (Daniel) 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.
2018-02-18 03:17:23 +00:00
bl GetPARPageInfo
Initial commit
2017-11-19 04:11:07 +00:00
rlwinm r7, r16, 0, 25, 26
cmpwi r7, 0x20
Remove unnecessary static branch hints These + and - characters in a branch mnemonic can cause the assembler to produce conditional branch instructions with that hint the branch predictor. The default for forward branches is -, and for backward branches is +. If a mnemonic is issued with the opposite sign, then bit 10 of the instruction (the LSB of the BO field) is set. My long-retired "ppcdisasm" script inserted these hints unconditionally, despite 98% of them not being required. The code is much cleaner now. I read in some old MPW release notes that PPCAsm and PPCLink together exhibit a quirk when linking conditional branches to imported symbols. PPCAsm always assembles these conditional branches as if they were forward branches (that is, a + hint will always set the hint bit, and a - hint will never). I hoped to use this property to divine whether the NanoKernel was linked from one or many assembly files, but I was frustrated by the lack of conditional branches between files.
2018-04-15 07:05:02 +00:00
bns cr7, VMReturnMinus1
beq VMReturn
common sense reform to v1 for v2 for v1 large vm diff getting shape correct Local_Panic -> VMPanic kdp revert to v1 teensy fix byte-perfect
2018-07-02 16:12:09 +00:00
bge cr4, VMReturnMinus1
Remove unnecessary static branch hints These + and - characters in a branch mnemonic can cause the assembler to produce conditional branch instructions with that hint the branch predictor. The default for forward branches is -, and for backward branches is +. If a mnemonic is issued with the opposite sign, then bit 10 of the instruction (the LSB of the BO field) is set. My long-retired "ppcdisasm" script inserted these hints unconditionally, despite 98% of them not being required. The code is much cleaner now. I read in some old MPW release notes that PPCAsm and PPCLink together exhibit a quirk when linking conditional branches to imported symbols. PPCAsm always assembles these conditional branches as if they were forward branches (that is, a + hint will always set the hint bit, and a - hint will never). I hoped to use this property to divine whether the NanoKernel was linked from one or many assembly files, but I was frustrated by the lack of conditional branches between files.
2018-04-15 07:05:02 +00:00
bgel cr5, VMSecondLastExportedFunc
Initial commit
2017-11-19 04:11:07 +00:00
rlwinm r16, r16, 0, 27, 24
rlwinm r9, r9, 0, 27, 24
ori r16, r16, 0x20
Reverse some VM functions (Daniel) 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.
2018-02-18 03:17:23 +00:00
bl EditPTEInHTAB
Initial commit
2017-11-19 04:11:07 +00:00
b VMReturn
; Cube-E has no comment
DeclareVMCall 24, VMMakePageWriteThrough
VMMakePageWriteThrough ; OUTSIDE REFERER
Reverse some VM functions (Daniel) 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.
2018-02-18 03:17:23 +00:00
bl GetPARPageInfo
Initial commit
2017-11-19 04:11:07 +00:00
rlwinm. r7, r16, 0, 25, 26
Remove unnecessary static branch hints These + and - characters in a branch mnemonic can cause the assembler to produce conditional branch instructions with that hint the branch predictor. The default for forward branches is -, and for backward branches is +. If a mnemonic is issued with the opposite sign, then bit 10 of the instruction (the LSB of the BO field) is set. My long-retired "ppcdisasm" script inserted these hints unconditionally, despite 98% of them not being required. The code is much cleaner now. I read in some old MPW release notes that PPCAsm and PPCLink together exhibit a quirk when linking conditional branches to imported symbols. PPCAsm always assembles these conditional branches as if they were forward branches (that is, a + hint will always set the hint bit, and a - hint will never). I hoped to use this property to divine whether the NanoKernel was linked from one or many assembly files, but I was frustrated by the lack of conditional branches between files.
2018-04-15 07:05:02 +00:00
bns cr7, VMReturnMinus1
beq VMReturn
bge cr4, VMMakePageWriteThrough_0x3c
bgel cr5, VMSecondLastExportedFunc
Initial commit
2017-11-19 04:11:07 +00:00
rlwinm r16, r16, 0, 27, 24
rlwinm r9, r9, 0, 27, 24
ori r9, r9, 0x40
Reverse some VM functions (Daniel) 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.
2018-02-18 03:17:23 +00:00
bl EditPTEInHTAB
Initial commit
2017-11-19 04:11:07 +00:00
b VMMakePageNonCacheable_0x3c
VMMakePageWriteThrough_0x3c
rlwinm r7, r4, 16, 28, 31
common sense reform to v1 for v2 for v1 large vm diff getting shape correct Local_Panic -> VMPanic kdp revert to v1 teensy fix byte-perfect
2018-07-02 16:12:09 +00:00
cmpwi r7, 0x09
Remove unnecessary static branch hints These + and - characters in a branch mnemonic can cause the assembler to produce conditional branch instructions with that hint the branch predictor. The default for forward branches is -, and for backward branches is +. If a mnemonic is issued with the opposite sign, then bit 10 of the instruction (the LSB of the BO field) is set. My long-retired "ppcdisasm" script inserted these hints unconditionally, despite 98% of them not being required. The code is much cleaner now. I read in some old MPW release notes that PPCAsm and PPCLink together exhibit a quirk when linking conditional branches to imported symbols. PPCAsm always assembles these conditional branches as if they were forward branches (that is, a + hint will always set the hint bit, and a - hint will never). I hoped to use this property to divine whether the NanoKernel was linked from one or many assembly files, but I was frustrated by the lack of conditional branches between files.
2018-04-15 07:05:02 +00:00
blt VMReturnMinus1
ble cr6, VMReturnMinus1
Initial commit
2017-11-19 04:11:07 +00:00
lwz r5, 0x000c(r15)
andi. r6, r5, 0xe01
cmpwi r6, 0xa01
Remove unnecessary static branch hints These + and - characters in a branch mnemonic can cause the assembler to produce conditional branch instructions with that hint the branch predictor. The default for forward branches is -, and for backward branches is +. If a mnemonic is issued with the opposite sign, then bit 10 of the instruction (the LSB of the BO field) is set. My long-retired "ppcdisasm" script inserted these hints unconditionally, despite 98% of them not being required. The code is much cleaner now. I read in some old MPW release notes that PPCAsm and PPCLink together exhibit a quirk when linking conditional branches to imported symbols. PPCAsm always assembles these conditional branches as if they were forward branches (that is, a + hint will always set the hint bit, and a - hint will never). I hoped to use this property to divine whether the NanoKernel was linked from one or many assembly files, but I was frustrated by the lack of conditional branches between files.
2018-04-15 07:05:02 +00:00
beq VMMakePageWriteThrough_0xec
Initial commit
2017-11-19 04:11:07 +00:00
addi r15, r15, -0x08
lwz r5, 0x0004(r15)
lhz r6, 0x0000(r15)
andi. r5, r5, 0xc00
lhz r5, 0x0002(r15)
Remove unnecessary static branch hints These + and - characters in a branch mnemonic can cause the assembler to produce conditional branch instructions with that hint the branch predictor. The default for forward branches is -, and for backward branches is +. If a mnemonic is issued with the opposite sign, then bit 10 of the instruction (the LSB of the BO field) is set. My long-retired "ppcdisasm" script inserted these hints unconditionally, despite 98% of them not being required. The code is much cleaner now. I read in some old MPW release notes that PPCAsm and PPCLink together exhibit a quirk when linking conditional branches to imported symbols. PPCAsm always assembles these conditional branches as if they were forward branches (that is, a + hint will always set the hint bit, and a - hint will never). I hoped to use this property to divine whether the NanoKernel was linked from one or many assembly files, but I was frustrated by the lack of conditional branches between files.
2018-04-15 07:05:02 +00:00
bne VMReturnMinus1
Initial commit
2017-11-19 04:11:07 +00:00
addi r5, r5, 0x01
add r6, r6, r5
xor r6, r6, r4
andi. r6, r6, 0xffff
Remove unnecessary static branch hints These + and - characters in a branch mnemonic can cause the assembler to produce conditional branch instructions with that hint the branch predictor. The default for forward branches is -, and for backward branches is +. If a mnemonic is issued with the opposite sign, then bit 10 of the instruction (the LSB of the BO field) is set. My long-retired "ppcdisasm" script inserted these hints unconditionally, despite 98% of them not being required. The code is much cleaner now. I read in some old MPW release notes that PPCAsm and PPCLink together exhibit a quirk when linking conditional branches to imported symbols. PPCAsm always assembles these conditional branches as if they were forward branches (that is, a + hint will always set the hint bit, and a - hint will never). I hoped to use this property to divine whether the NanoKernel was linked from one or many assembly files, but I was frustrated by the lack of conditional branches between files.
2018-04-15 07:05:02 +00:00
bne VMReturnMinus1
Initial commit
2017-11-19 04:11:07 +00:00
sth r5, 0x0002(r15)
b PageSetCommon
VMMakePageWriteThrough_0xec
lwz r5, 0x0000(r15)
lwz r6, 0x0004(r15)
stw r5, 0x0008(r15)
stw r6, 0x000c(r15)
slwi r5, r4, 16
stw r5, 0x0000(r15)
slwi r5, r4, 12
common sense reform to v1 for v2 for v1 large vm diff getting shape correct Local_Panic -> VMPanic kdp revert to v1 teensy fix byte-perfect
2018-07-02 16:12:09 +00:00
ori r5, r5, 0x42
Initial commit
2017-11-19 04:11:07 +00:00
stw r5, 0x0004(r15)
; PageSetCommon
PageSetCommon ; OUTSIDE REFERER
Start to reverse the legacy VM subsystem
2018-02-03 12:56:13 +00:00
lwz r15, KDP.PTEGMask(r1)
lwz r14, KDP.HTABORG(r1)
Initial commit
2017-11-19 04:11:07 +00:00
slwi r6, r4, 12
mfsrin r6, r6
rlwinm r8, r6, 7, 0, 20
xor r6, r6, r4
slwi r7, r6, 6
and r15, r15, r7
rlwimi r8, r4, 22, 26, 31
crset cr0_eq
oris r8, r8, 0x8000
PageSetCommon_0x2c
lwzux r7, r14, r15
lwz r15, 0x0008(r14)
lwz r6, 0x0010(r14)
lwz r5, 0x0018(r14)
cmplw cr1, r7, r8
cmplw cr2, r15, r8
cmplw cr3, r6, r8
cmplw cr4, r5, r8
Remove unnecessary static branch hints These + and - characters in a branch mnemonic can cause the assembler to produce conditional branch instructions with that hint the branch predictor. The default for forward branches is -, and for backward branches is +. If a mnemonic is issued with the opposite sign, then bit 10 of the instruction (the LSB of the BO field) is set. My long-retired "ppcdisasm" script inserted these hints unconditionally, despite 98% of them not being required. The code is much cleaner now. I read in some old MPW release notes that PPCAsm and PPCLink together exhibit a quirk when linking conditional branches to imported symbols. PPCAsm always assembles these conditional branches as if they were forward branches (that is, a + hint will always set the hint bit, and a - hint will never). I hoped to use this property to divine whether the NanoKernel was linked from one or many assembly files, but I was frustrated by the lack of conditional branches between files.
2018-04-15 07:05:02 +00:00
beq cr1, PageSetCommon_0xc8
beq cr2, PageSetCommon_0xc4
beq cr3, PageSetCommon_0xc0
beq cr4, PageSetCommon_0xbc
Initial commit
2017-11-19 04:11:07 +00:00
lwzu r7, 0x0020(r14)
lwz r15, 0x0008(r14)
lwz r6, 0x0010(r14)
lwz r5, 0x0018(r14)
cmplw cr1, r7, r8
cmplw cr2, r15, r8
cmplw cr3, r6, r8
cmplw cr4, r5, r8
Remove unnecessary static branch hints These + and - characters in a branch mnemonic can cause the assembler to produce conditional branch instructions with that hint the branch predictor. The default for forward branches is -, and for backward branches is +. If a mnemonic is issued with the opposite sign, then bit 10 of the instruction (the LSB of the BO field) is set. My long-retired "ppcdisasm" script inserted these hints unconditionally, despite 98% of them not being required. The code is much cleaner now. I read in some old MPW release notes that PPCAsm and PPCLink together exhibit a quirk when linking conditional branches to imported symbols. PPCAsm always assembles these conditional branches as if they were forward branches (that is, a + hint will always set the hint bit, and a - hint will never). I hoped to use this property to divine whether the NanoKernel was linked from one or many assembly files, but I was frustrated by the lack of conditional branches between files.
2018-04-15 07:05:02 +00:00
beq cr1, PageSetCommon_0xc8
beq cr2, PageSetCommon_0xc4
beq cr3, PageSetCommon_0xc0
beq cr4, PageSetCommon_0xbc
Initial commit
2017-11-19 04:11:07 +00:00
crnot 2, 2
Start to reverse the legacy VM subsystem
2018-02-03 12:56:13 +00:00
lwz r15, KDP.PTEGMask(r1)
lwz r14, KDP.HTABORG(r1)
Initial commit
2017-11-19 04:11:07 +00:00
slwi r6, r4, 12
mfsrin r6, r6
xor r6, r6, r4
not r6, r6
slwi r7, r6, 6
and r15, r15, r7
xori r8, r8, 0x40
Remove unnecessary static branch hints These + and - characters in a branch mnemonic can cause the assembler to produce conditional branch instructions with that hint the branch predictor. The default for forward branches is -, and for backward branches is +. If a mnemonic is issued with the opposite sign, then bit 10 of the instruction (the LSB of the BO field) is set. My long-retired "ppcdisasm" script inserted these hints unconditionally, despite 98% of them not being required. The code is much cleaner now. I read in some old MPW release notes that PPCAsm and PPCLink together exhibit a quirk when linking conditional branches to imported symbols. PPCAsm always assembles these conditional branches as if they were forward branches (that is, a + hint will always set the hint bit, and a - hint will never). I hoped to use this property to divine whether the NanoKernel was linked from one or many assembly files, but I was frustrated by the lack of conditional branches between files.
2018-04-15 07:05:02 +00:00
bne PageSetCommon_0x2c
Initial commit
2017-11-19 04:11:07 +00:00
b VMReturn
PageSetCommon_0xbc
addi r14, r14, 0x08
PageSetCommon_0xc0
addi r14, r14, 0x08
PageSetCommon_0xc4
addi r14, r14, 0x08
PageSetCommon_0xc8
common sense reform to v1 for v2 for v1 large vm diff getting shape correct Local_Panic -> VMPanic kdp revert to v1 teensy fix byte-perfect
2018-07-02 16:12:09 +00:00
; bl RemovePageFromTLB
Initial commit
2017-11-19 04:11:07 +00:00
li r8, 0x00
li r9, 0x00
common sense reform to v1 for v2 for v1 large vm diff getting shape correct Local_Panic -> VMPanic kdp revert to v1 teensy fix byte-perfect
2018-07-02 16:12:09 +00:00
bl EditLowerPTEOnlyInHTAB
Initial commit
2017-11-19 04:11:07 +00:00
b VMReturn
; 'make it so'
DeclareVMCall 18, VMMakePageNonCacheable
VMMakePageNonCacheable ; OUTSIDE REFERER
Reverse some VM functions (Daniel) 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.
2018-02-18 03:17:23 +00:00
bl GetPARPageInfo
Initial commit
2017-11-19 04:11:07 +00:00
rlwinm r7, r16, 0, 25, 26
cmpwi r7, 0x60
Remove unnecessary static branch hints These + and - characters in a branch mnemonic can cause the assembler to produce conditional branch instructions with that hint the branch predictor. The default for forward branches is -, and for backward branches is +. If a mnemonic is issued with the opposite sign, then bit 10 of the instruction (the LSB of the BO field) is set. My long-retired "ppcdisasm" script inserted these hints unconditionally, despite 98% of them not being required. The code is much cleaner now. I read in some old MPW release notes that PPCAsm and PPCLink together exhibit a quirk when linking conditional branches to imported symbols. PPCAsm always assembles these conditional branches as if they were forward branches (that is, a + hint will always set the hint bit, and a - hint will never). I hoped to use this property to divine whether the NanoKernel was linked from one or many assembly files, but I was frustrated by the lack of conditional branches between files.
2018-04-15 07:05:02 +00:00
bns cr7, VMReturnMinus1
beq VMReturn
common sense reform to v1 for v2 for v1 large vm diff getting shape correct Local_Panic -> VMPanic kdp revert to v1 teensy fix byte-perfect
2018-07-02 16:12:09 +00:00
bge cr4, VMReturnMinus1
Remove unnecessary static branch hints These + and - characters in a branch mnemonic can cause the assembler to produce conditional branch instructions with that hint the branch predictor. The default for forward branches is -, and for backward branches is +. If a mnemonic is issued with the opposite sign, then bit 10 of the instruction (the LSB of the BO field) is set. My long-retired "ppcdisasm" script inserted these hints unconditionally, despite 98% of them not being required. The code is much cleaner now. I read in some old MPW release notes that PPCAsm and PPCLink together exhibit a quirk when linking conditional branches to imported symbols. PPCAsm always assembles these conditional branches as if they were forward branches (that is, a + hint will always set the hint bit, and a - hint will never). I hoped to use this property to divine whether the NanoKernel was linked from one or many assembly files, but I was frustrated by the lack of conditional branches between files.
2018-04-15 07:05:02 +00:00
bgel cr5, VMSecondLastExportedFunc
Initial commit
2017-11-19 04:11:07 +00:00
rlwinm r9, r9, 0, 27, 24
ori r16, r16, 0x60
ori r9, r9, 0x20
Reverse some VM functions (Daniel) 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.
2018-02-18 03:17:23 +00:00
bl EditPTEInHTAB
Initial commit
2017-11-19 04:11:07 +00:00
VMMakePageNonCacheable_0x3c ; OUTSIDE REFERER
rlwinm r4, r9, 0, 0, 19
common sense reform to v1 for v2 for v1 large vm diff getting shape correct Local_Panic -> VMPanic kdp revert to v1 teensy fix byte-perfect
2018-07-02 16:12:09 +00:00
addi r5, r4, 0x20
Initial commit
2017-11-19 04:11:07 +00:00
li r7, 0x1000
common sense reform to v1 for v2 for v1 large vm diff getting shape correct Local_Panic -> VMPanic kdp revert to v1 teensy fix byte-perfect
2018-07-02 16:12:09 +00:00
li r8, 0x40
Initial commit
2017-11-19 04:11:07 +00:00
VMMakePageNonCacheable_0x50
subf. r7, r8, r7
dcbf r7, r4
dcbf r7, r5
Remove unnecessary static branch hints These + and - characters in a branch mnemonic can cause the assembler to produce conditional branch instructions with that hint the branch predictor. The default for forward branches is -, and for backward branches is +. If a mnemonic is issued with the opposite sign, then bit 10 of the instruction (the LSB of the BO field) is set. My long-retired "ppcdisasm" script inserted these hints unconditionally, despite 98% of them not being required. The code is much cleaner now. I read in some old MPW release notes that PPCAsm and PPCLink together exhibit a quirk when linking conditional branches to imported symbols. PPCAsm always assembles these conditional branches as if they were forward branches (that is, a + hint will always set the hint bit, and a - hint will never). I hoped to use this property to divine whether the NanoKernel was linked from one or many assembly files, but I was frustrated by the lack of conditional branches between files.
2018-04-15 07:05:02 +00:00
bne VMMakePageNonCacheable_0x50
Initial commit
2017-11-19 04:11:07 +00:00
b VMReturn
; 'set page status'
DeclareVMCall 8, VMMarkBacking
VMMarkBacking ; OUTSIDE REFERER
Reverse some VM functions (Daniel) 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.
2018-02-18 03:17:23 +00:00
bl GetPARPageInfo
Remove unnecessary static branch hints These + and - characters in a branch mnemonic can cause the assembler to produce conditional branch instructions with that hint the branch predictor. The default for forward branches is -, and for backward branches is +. If a mnemonic is issued with the opposite sign, then bit 10 of the instruction (the LSB of the BO field) is set. My long-retired "ppcdisasm" script inserted these hints unconditionally, despite 98% of them not being required. The code is much cleaner now. I read in some old MPW release notes that PPCAsm and PPCLink together exhibit a quirk when linking conditional branches to imported symbols. PPCAsm always assembles these conditional branches as if they were forward branches (that is, a + hint will always set the hint bit, and a - hint will never). I hoped to use this property to divine whether the NanoKernel was linked from one or many assembly files, but I was frustrated by the lack of conditional branches between files.
2018-04-15 07:05:02 +00:00
bge cr4, VMReturnMinus1
bgt cr5, VMReturnMinus1
bltl cr5, RemovePTEFromHTAB
Initial commit
2017-11-19 04:11:07 +00:00
rlwimi r16, r5, 16, 15, 15
li r7, 0x01
andc r16, r16, r7
stw r16, 0x0000(r15)
b VMReturn
; 'ask about page status' (typo?)
common sense reform to v1 for v2 for v1 large vm diff getting shape correct Local_Panic -> VMPanic kdp revert to v1 teensy fix byte-perfect
2018-07-02 16:12:09 +00:00
DeclareVMCall 9, VMMarkCleanUnused
Initial commit
2017-11-19 04:11:07 +00:00
VMMarkCleanUnused ; OUTSIDE REFERER
Reverse some VM functions (Daniel) 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.
2018-02-18 03:17:23 +00:00
bl GetPARPageInfo
Remove unnecessary static branch hints These + and - characters in a branch mnemonic can cause the assembler to produce conditional branch instructions with that hint the branch predictor. The default for forward branches is -, and for backward branches is +. If a mnemonic is issued with the opposite sign, then bit 10 of the instruction (the LSB of the BO field) is set. My long-retired "ppcdisasm" script inserted these hints unconditionally, despite 98% of them not being required. The code is much cleaner now. I read in some old MPW release notes that PPCAsm and PPCLink together exhibit a quirk when linking conditional branches to imported symbols. PPCAsm always assembles these conditional branches as if they were forward branches (that is, a + hint will always set the hint bit, and a - hint will never). I hoped to use this property to divine whether the NanoKernel was linked from one or many assembly files, but I was frustrated by the lack of conditional branches between files.
2018-04-15 07:05:02 +00:00
bge cr4, VMReturnMinus1
bns cr7, VMReturnMinus1
bgel cr5, VMSecondLastExportedFunc
Initial commit
2017-11-19 04:11:07 +00:00
li r7, 0x180
andc r9, r9, r7
ori r16, r16, 0x100
Reverse some VM functions (Daniel) 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.
2018-02-18 03:17:23 +00:00
bl EditPTEInHTAB
Initial commit
2017-11-19 04:11:07 +00:00
b VMReturn
; Cube-E has no comment
common sense reform to v1 for v2 for v1 large vm diff getting shape correct Local_Panic -> VMPanic kdp revert to v1 teensy fix byte-perfect
2018-07-02 16:12:09 +00:00
DeclareVMCall 23, VMMarkUndefined
Initial commit
2017-11-19 04:11:07 +00:00
VMMarkUndefined ; OUTSIDE REFERER
cmplw r4, r9
cmplw cr1, r5, r9
add r7, r4, r5
cmplw cr2, r7, r9
Remove unnecessary static branch hints These + and - characters in a branch mnemonic can cause the assembler to produce conditional branch instructions with that hint the branch predictor. The default for forward branches is -, and for backward branches is +. If a mnemonic is issued with the opposite sign, then bit 10 of the instruction (the LSB of the BO field) is set. My long-retired "ppcdisasm" script inserted these hints unconditionally, despite 98% of them not being required. The code is much cleaner now. I read in some old MPW release notes that PPCAsm and PPCLink together exhibit a quirk when linking conditional branches to imported symbols. PPCAsm always assembles these conditional branches as if they were forward branches (that is, a + hint will always set the hint bit, and a - hint will never). I hoped to use this property to divine whether the NanoKernel was linked from one or many assembly files, but I was frustrated by the lack of conditional branches between files.
2018-04-15 07:05:02 +00:00
bge VMReturnMinus1
bgt cr1, VMReturnMinus1
bgt cr2, VMReturnMinus1
looks good
2018-07-06 13:44:52 +00:00
lwz r15, KDP.PARPageListPtr(r1)
Initial commit
2017-11-19 04:11:07 +00:00
slwi r8, r7, 2
li r7, 0x01
VMMarkUndefined_0x28
subi r8, r8, 4
subf. r5, r7, r5
lwzx r16, r15, r8
Remove unnecessary static branch hints These + and - characters in a branch mnemonic can cause the assembler to produce conditional branch instructions with that hint the branch predictor. The default for forward branches is -, and for backward branches is +. If a mnemonic is issued with the opposite sign, then bit 10 of the instruction (the LSB of the BO field) is set. My long-retired "ppcdisasm" script inserted these hints unconditionally, despite 98% of them not being required. The code is much cleaner now. I read in some old MPW release notes that PPCAsm and PPCLink together exhibit a quirk when linking conditional branches to imported symbols. PPCAsm always assembles these conditional branches as if they were forward branches (that is, a + hint will always set the hint bit, and a - hint will never). I hoped to use this property to divine whether the NanoKernel was linked from one or many assembly files, but I was frustrated by the lack of conditional branches between files.
2018-04-15 07:05:02 +00:00
blt VMReturn
Initial commit
2017-11-19 04:11:07 +00:00
rlwimi r16, r6, 7, 24, 24
stwx r16, r15, r8
b VMMarkUndefined_0x28
; 'set page status'
DeclareVMCall 7, VMMarkResident
VMMarkResident ; OUTSIDE REFERER
Reverse some VM functions (Daniel) 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.
2018-02-18 03:17:23 +00:00
bl GetPARPageInfo
Remove unnecessary static branch hints These + and - characters in a branch mnemonic can cause the assembler to produce conditional branch instructions with that hint the branch predictor. The default for forward branches is -, and for backward branches is +. If a mnemonic is issued with the opposite sign, then bit 10 of the instruction (the LSB of the BO field) is set. My long-retired "ppcdisasm" script inserted these hints unconditionally, despite 98% of them not being required. The code is much cleaner now. I read in some old MPW release notes that PPCAsm and PPCLink together exhibit a quirk when linking conditional branches to imported symbols. PPCAsm always assembles these conditional branches as if they were forward branches (that is, a + hint will always set the hint bit, and a - hint will never). I hoped to use this property to divine whether the NanoKernel was linked from one or many assembly files, but I was frustrated by the lack of conditional branches between files.
2018-04-15 07:05:02 +00:00
bge cr4, VMReturnMinus1
bso cr7, VMReturnMinus1
fixes
2018-07-15 09:34:52 +00:00
bltl cr5, SystemCrash
Initial commit
2017-11-19 04:11:07 +00:00
rlwimi r16, r5, 12, 0, 19
ori r16, r16, 0x01
stw r16, 0x0000(r15)
bl VMSecondLastExportedFunc
Reverse some VM functions (Daniel) 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.
2018-02-18 03:17:23 +00:00
bl EditPTEInHTAB
Initial commit
2017-11-19 04:11:07 +00:00
b VMReturn
; 'ask why we got this page fault'
common sense reform to v1 for v2 for v1 large vm diff getting shape correct Local_Panic -> VMPanic kdp revert to v1 teensy fix byte-perfect
2018-07-02 16:12:09 +00:00
DeclareVMCall 21, VMPTest
Initial commit
2017-11-19 04:11:07 +00:00
VMPTest ; OUTSIDE REFERER
srwi r4, r4, 12
cmplw r4, r9
li r3, 0x4000
Remove unnecessary static branch hints These + and - characters in a branch mnemonic can cause the assembler to produce conditional branch instructions with that hint the branch predictor. The default for forward branches is -, and for backward branches is +. If a mnemonic is issued with the opposite sign, then bit 10 of the instruction (the LSB of the BO field) is set. My long-retired "ppcdisasm" script inserted these hints unconditionally, despite 98% of them not being required. The code is much cleaner now. I read in some old MPW release notes that PPCAsm and PPCLink together exhibit a quirk when linking conditional branches to imported symbols. PPCAsm always assembles these conditional branches as if they were forward branches (that is, a + hint will always set the hint bit, and a - hint will never). I hoped to use this property to divine whether the NanoKernel was linked from one or many assembly files, but I was frustrated by the lack of conditional branches between files.
2018-04-15 07:05:02 +00:00
bge VMReturn
Reverse some VM functions (Daniel) 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.
2018-02-18 03:17:23 +00:00
bl GetPARPageInfo
Initial commit
2017-11-19 04:11:07 +00:00
li r3, 0x400
Remove unnecessary static branch hints These + and - characters in a branch mnemonic can cause the assembler to produce conditional branch instructions with that hint the branch predictor. The default for forward branches is -, and for backward branches is +. If a mnemonic is issued with the opposite sign, then bit 10 of the instruction (the LSB of the BO field) is set. My long-retired "ppcdisasm" script inserted these hints unconditionally, despite 98% of them not being required. The code is much cleaner now. I read in some old MPW release notes that PPCAsm and PPCLink together exhibit a quirk when linking conditional branches to imported symbols. PPCAsm always assembles these conditional branches as if they were forward branches (that is, a + hint will always set the hint bit, and a - hint will never). I hoped to use this property to divine whether the NanoKernel was linked from one or many assembly files, but I was frustrated by the lack of conditional branches between files.
2018-04-15 07:05:02 +00:00
bns cr7, VMReturn
Initial commit
2017-11-19 04:11:07 +00:00
li r3, 0x00
ori r3, r3, 0x8000
Remove unnecessary static branch hints These + and - characters in a branch mnemonic can cause the assembler to produce conditional branch instructions with that hint the branch predictor. The default for forward branches is -, and for backward branches is +. If a mnemonic is issued with the opposite sign, then bit 10 of the instruction (the LSB of the BO field) is set. My long-retired "ppcdisasm" script inserted these hints unconditionally, despite 98% of them not being required. The code is much cleaner now. I read in some old MPW release notes that PPCAsm and PPCLink together exhibit a quirk when linking conditional branches to imported symbols. PPCAsm always assembles these conditional branches as if they were forward branches (that is, a + hint will always set the hint bit, and a - hint will never). I hoped to use this property to divine whether the NanoKernel was linked from one or many assembly files, but I was frustrated by the lack of conditional branches between files.
2018-04-15 07:05:02 +00:00
ble cr7, VMReturn
Initial commit
2017-11-19 04:11:07 +00:00
cmpwi r6, 0x00
Remove unnecessary static branch hints These + and - characters in a branch mnemonic can cause the assembler to produce conditional branch instructions with that hint the branch predictor. The default for forward branches is -, and for backward branches is +. If a mnemonic is issued with the opposite sign, then bit 10 of the instruction (the LSB of the BO field) is set. My long-retired "ppcdisasm" script inserted these hints unconditionally, despite 98% of them not being required. The code is much cleaner now. I read in some old MPW release notes that PPCAsm and PPCLink together exhibit a quirk when linking conditional branches to imported symbols. PPCAsm always assembles these conditional branches as if they were forward branches (that is, a + hint will always set the hint bit, and a - hint will never). I hoped to use this property to divine whether the NanoKernel was linked from one or many assembly files, but I was frustrated by the lack of conditional branches between files.
2018-04-15 07:05:02 +00:00
beq VMReturn
Initial commit
2017-11-19 04:11:07 +00:00
li r3, 0x800
b VMReturn
; 'given a page & 68K pte, set the real PTE'
DeclareVMCall 20, setPTEntryGivenPage
setPTEntryGivenPage ; OUTSIDE REFERER
mr r6, r4
mr r4, r5
Reverse some VM functions (Daniel) 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.
2018-02-18 03:17:23 +00:00
bl GetPARPageInfo
Remove unnecessary static branch hints These + and - characters in a branch mnemonic can cause the assembler to produce conditional branch instructions with that hint the branch predictor. The default for forward branches is -, and for backward branches is +. If a mnemonic is issued with the opposite sign, then bit 10 of the instruction (the LSB of the BO field) is set. My long-retired "ppcdisasm" script inserted these hints unconditionally, despite 98% of them not being required. The code is much cleaner now. I read in some old MPW release notes that PPCAsm and PPCLink together exhibit a quirk when linking conditional branches to imported symbols. PPCAsm always assembles these conditional branches as if they were forward branches (that is, a + hint will always set the hint bit, and a - hint will never). I hoped to use this property to divine whether the NanoKernel was linked from one or many assembly files, but I was frustrated by the lack of conditional branches between files.
2018-04-15 07:05:02 +00:00
bge cr4, VMReturnMinus1
Initial commit
2017-11-19 04:11:07 +00:00
xor r7, r16, r6
li r3, 0x461
rlwimi r3, r16, 24, 29, 29
and. r3, r3, r7
Remove unnecessary static branch hints These + and - characters in a branch mnemonic can cause the assembler to produce conditional branch instructions with that hint the branch predictor. The default for forward branches is -, and for backward branches is +. If a mnemonic is issued with the opposite sign, then bit 10 of the instruction (the LSB of the BO field) is set. My long-retired "ppcdisasm" script inserted these hints unconditionally, despite 98% of them not being required. The code is much cleaner now. I read in some old MPW release notes that PPCAsm and PPCLink together exhibit a quirk when linking conditional branches to imported symbols. PPCAsm always assembles these conditional branches as if they were forward branches (that is, a + hint will always set the hint bit, and a - hint will never). I hoped to use this property to divine whether the NanoKernel was linked from one or many assembly files, but I was frustrated by the lack of conditional branches between files.
2018-04-15 07:05:02 +00:00
bne VMReturnMinus1
Initial commit
2017-11-19 04:11:07 +00:00
andi. r7, r7, 0x11c
xor r16, r16, r7
stw r16, 0x0000(r15)
Remove unnecessary static branch hints These + and - characters in a branch mnemonic can cause the assembler to produce conditional branch instructions with that hint the branch predictor. The default for forward branches is -, and for backward branches is +. If a mnemonic is issued with the opposite sign, then bit 10 of the instruction (the LSB of the BO field) is set. My long-retired "ppcdisasm" script inserted these hints unconditionally, despite 98% of them not being required. The code is much cleaner now. I read in some old MPW release notes that PPCAsm and PPCLink together exhibit a quirk when linking conditional branches to imported symbols. PPCAsm always assembles these conditional branches as if they were forward branches (that is, a + hint will always set the hint bit, and a - hint will never). I hoped to use this property to divine whether the NanoKernel was linked from one or many assembly files, but I was frustrated by the lack of conditional branches between files.
2018-04-15 07:05:02 +00:00
bge cr5, VMReturn
Initial commit
2017-11-19 04:11:07 +00:00
rlwimi r9, r16, 5, 23, 23
rlwimi r9, r16, 3, 24, 24
rlwimi r9, r16, 30, 31, 31
Reverse some VM functions (Daniel) 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.
2018-02-18 03:17:23 +00:00
bl EditPTEOnlyInHTAB
Initial commit
2017-11-19 04:11:07 +00:00
b VMReturn
; 'ask about page status' (typo?)
common sense reform to v1 for v2 for v1 large vm diff getting shape correct Local_Panic -> VMPanic kdp revert to v1 teensy fix byte-perfect
2018-07-02 16:12:09 +00:00
DeclareVMCall 6, VMShouldClean
Initial commit
2017-11-19 04:11:07 +00:00
VMShouldClean ; OUTSIDE REFERER
Reverse some VM functions (Daniel) 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.
2018-02-18 03:17:23 +00:00
bl GetPARPageInfo
Remove unnecessary static branch hints These + and - characters in a branch mnemonic can cause the assembler to produce conditional branch instructions with that hint the branch predictor. The default for forward branches is -, and for backward branches is +. If a mnemonic is issued with the opposite sign, then bit 10 of the instruction (the LSB of the BO field) is set. My long-retired "ppcdisasm" script inserted these hints unconditionally, despite 98% of them not being required. The code is much cleaner now. I read in some old MPW release notes that PPCAsm and PPCLink together exhibit a quirk when linking conditional branches to imported symbols. PPCAsm always assembles these conditional branches as if they were forward branches (that is, a + hint will always set the hint bit, and a - hint will never). I hoped to use this property to divine whether the NanoKernel was linked from one or many assembly files, but I was frustrated by the lack of conditional branches between files.
2018-04-15 07:05:02 +00:00
bns cr7, VMReturn0
common sense reform to v1 for v2 for v1 large vm diff getting shape correct Local_Panic -> VMPanic kdp revert to v1 teensy fix byte-perfect
2018-07-02 16:12:09 +00:00
blt cr7, VMReturn0
bns cr6, VMReturn0
Remove unnecessary static branch hints These + and - characters in a branch mnemonic can cause the assembler to produce conditional branch instructions with that hint the branch predictor. The default for forward branches is -, and for backward branches is +. If a mnemonic is issued with the opposite sign, then bit 10 of the instruction (the LSB of the BO field) is set. My long-retired "ppcdisasm" script inserted these hints unconditionally, despite 98% of them not being required. The code is much cleaner now. I read in some old MPW release notes that PPCAsm and PPCLink together exhibit a quirk when linking conditional branches to imported symbols. PPCAsm always assembles these conditional branches as if they were forward branches (that is, a + hint will always set the hint bit, and a - hint will never). I hoped to use this property to divine whether the NanoKernel was linked from one or many assembly files, but I was frustrated by the lack of conditional branches between files.
2018-04-15 07:05:02 +00:00
bge cr4, VMReturnMinus1
Initial commit
2017-11-19 04:11:07 +00:00
xori r16, r16, 0x10
ori r16, r16, 0x100
stw r16, 0x0000(r15)
Remove unnecessary static branch hints These + and - characters in a branch mnemonic can cause the assembler to produce conditional branch instructions with that hint the branch predictor. The default for forward branches is -, and for backward branches is +. If a mnemonic is issued with the opposite sign, then bit 10 of the instruction (the LSB of the BO field) is set. My long-retired "ppcdisasm" script inserted these hints unconditionally, despite 98% of them not being required. The code is much cleaner now. I read in some old MPW release notes that PPCAsm and PPCLink together exhibit a quirk when linking conditional branches to imported symbols. PPCAsm always assembles these conditional branches as if they were forward branches (that is, a + hint will always set the hint bit, and a - hint will never). I hoped to use this property to divine whether the NanoKernel was linked from one or many assembly files, but I was frustrated by the lack of conditional branches between files.
2018-04-15 07:05:02 +00:00
bge cr5, VMReturn1
Initial commit
2017-11-19 04:11:07 +00:00
xori r9, r9, 0x80
Reverse some VM functions (Daniel) 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.
2018-02-18 03:17:23 +00:00
bl EditPTEOnlyInHTAB
Initial commit
2017-11-19 04:11:07 +00:00
b VMReturn1
; Cube-E has no comment
common sense reform to v1 for v2 for v1 large vm diff getting shape correct Local_Panic -> VMPanic kdp revert to v1 teensy fix byte-perfect
2018-07-02 16:12:09 +00:00
DeclareVMCall 25, VMAllocateMemory
Initial commit
2017-11-19 04:11:07 +00:00
VMAllocateMemory ; OUTSIDE REFERER
looks good
2018-07-06 13:44:52 +00:00
lwz r7, KDP.PARPageListPtr(r1)
happy
2018-07-06 13:30:48 +00:00
lwz r8, KDP.PARPerSegmentPLEPtrs + 0(r1)
Initial commit
2017-11-19 04:11:07 +00:00
cmpwi cr6, r5, 0x00
cmpw cr7, r7, r8
or r7, r4, r6
rlwinm. r7, r7, 0, 0, 11
Remove unnecessary static branch hints These + and - characters in a branch mnemonic can cause the assembler to produce conditional branch instructions with that hint the branch predictor. The default for forward branches is -, and for backward branches is +. If a mnemonic is issued with the opposite sign, then bit 10 of the instruction (the LSB of the BO field) is set. My long-retired "ppcdisasm" script inserted these hints unconditionally, despite 98% of them not being required. The code is much cleaner now. I read in some old MPW release notes that PPCAsm and PPCLink together exhibit a quirk when linking conditional branches to imported symbols. PPCAsm always assembles these conditional branches as if they were forward branches (that is, a + hint will always set the hint bit, and a - hint will never). I hoped to use this property to divine whether the NanoKernel was linked from one or many assembly files, but I was frustrated by the lack of conditional branches between files.
2018-04-15 07:05:02 +00:00
ble cr6, VMReturnMinus1
Lots of work on Address Spaces
2018-04-23 15:22:55 +00:00
lwz r9, KDP.VMLogicalPages(r1)
Remove unnecessary static branch hints These + and - characters in a branch mnemonic can cause the assembler to produce conditional branch instructions with that hint the branch predictor. The default for forward branches is -, and for backward branches is +. If a mnemonic is issued with the opposite sign, then bit 10 of the instruction (the LSB of the BO field) is set. My long-retired "ppcdisasm" script inserted these hints unconditionally, despite 98% of them not being required. The code is much cleaner now. I read in some old MPW release notes that PPCAsm and PPCLink together exhibit a quirk when linking conditional branches to imported symbols. PPCAsm always assembles these conditional branches as if they were forward branches (that is, a + hint will always set the hint bit, and a - hint will never). I hoped to use this property to divine whether the NanoKernel was linked from one or many assembly files, but I was frustrated by the lack of conditional branches between files.
2018-04-15 07:05:02 +00:00
bne cr7, VMReturnMinus1
Initial commit
2017-11-19 04:11:07 +00:00
mr r7, r4
Remove unnecessary static branch hints These + and - characters in a branch mnemonic can cause the assembler to produce conditional branch instructions with that hint the branch predictor. The default for forward branches is -, and for backward branches is +. If a mnemonic is issued with the opposite sign, then bit 10 of the instruction (the LSB of the BO field) is set. My long-retired "ppcdisasm" script inserted these hints unconditionally, despite 98% of them not being required. The code is much cleaner now. I read in some old MPW release notes that PPCAsm and PPCLink together exhibit a quirk when linking conditional branches to imported symbols. PPCAsm always assembles these conditional branches as if they were forward branches (that is, a + hint will always set the hint bit, and a - hint will never). I hoped to use this property to divine whether the NanoKernel was linked from one or many assembly files, but I was frustrated by the lack of conditional branches between files.
2018-04-15 07:05:02 +00:00
bne VMReturnMinus1
Initial commit
2017-11-19 04:11:07 +00:00
mr r4, r9
slwi r6, r6, 12
addi r5, r5, -0x01
VMAllocateMemory_0x74
addi r4, r4, -0x01
Reverse some VM functions (Daniel) 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.
2018-02-18 03:17:23 +00:00
bl GetPARPageInfo
Remove unnecessary static branch hints These + and - characters in a branch mnemonic can cause the assembler to produce conditional branch instructions with that hint the branch predictor. The default for forward branches is -, and for backward branches is +. If a mnemonic is issued with the opposite sign, then bit 10 of the instruction (the LSB of the BO field) is set. My long-retired "ppcdisasm" script inserted these hints unconditionally, despite 98% of them not being required. The code is much cleaner now. I read in some old MPW release notes that PPCAsm and PPCLink together exhibit a quirk when linking conditional branches to imported symbols. PPCAsm always assembles these conditional branches as if they were forward branches (that is, a + hint will always set the hint bit, and a - hint will never). I hoped to use this property to divine whether the NanoKernel was linked from one or many assembly files, but I was frustrated by the lack of conditional branches between files.
2018-04-15 07:05:02 +00:00
bltl cr5, RemovePTEFromHTAB
Lots of work on Address Spaces
2018-04-23 15:22:55 +00:00
lwz r9, KDP.VMLogicalPages(r1)
Initial commit
2017-11-19 04:11:07 +00:00
subf r8, r4, r9
cmplw cr7, r5, r8
and. r8, r16, r6
Remove unnecessary static branch hints These + and - characters in a branch mnemonic can cause the assembler to produce conditional branch instructions with that hint the branch predictor. The default for forward branches is -, and for backward branches is +. If a mnemonic is issued with the opposite sign, then bit 10 of the instruction (the LSB of the BO field) is set. My long-retired "ppcdisasm" script inserted these hints unconditionally, despite 98% of them not being required. The code is much cleaner now. I read in some old MPW release notes that PPCAsm and PPCLink together exhibit a quirk when linking conditional branches to imported symbols. PPCAsm always assembles these conditional branches as if they were forward branches (that is, a + hint will always set the hint bit, and a - hint will never). I hoped to use this property to divine whether the NanoKernel was linked from one or many assembly files, but I was frustrated by the lack of conditional branches between files.
2018-04-15 07:05:02 +00:00
bge cr7, VMAllocateMemory_0x74
bne VMAllocateMemory_0x74
Initial commit
2017-11-19 04:11:07 +00:00
cmpwi cr6, r6, 0x00
Remove unnecessary static branch hints These + and - characters in a branch mnemonic can cause the assembler to produce conditional branch instructions with that hint the branch predictor. The default for forward branches is -, and for backward branches is +. If a mnemonic is issued with the opposite sign, then bit 10 of the instruction (the LSB of the BO field) is set. My long-retired "ppcdisasm" script inserted these hints unconditionally, despite 98% of them not being required. The code is much cleaner now. I read in some old MPW release notes that PPCAsm and PPCLink together exhibit a quirk when linking conditional branches to imported symbols. PPCAsm always assembles these conditional branches as if they were forward branches (that is, a + hint will always set the hint bit, and a - hint will never). I hoped to use this property to divine whether the NanoKernel was linked from one or many assembly files, but I was frustrated by the lack of conditional branches between files.
2018-04-15 07:05:02 +00:00
beq cr6, VMAllocateMemory_0xc0
Initial commit
2017-11-19 04:11:07 +00:00
slwi r8, r5, 2
lwzx r8, r15, r8
slwi r14, r5, 12
add r14, r14, r16
xor r8, r8, r14
rlwinm. r8, r8, 0, 0, 19
Remove unnecessary static branch hints These + and - characters in a branch mnemonic can cause the assembler to produce conditional branch instructions with that hint the branch predictor. The default for forward branches is -, and for backward branches is +. If a mnemonic is issued with the opposite sign, then bit 10 of the instruction (the LSB of the BO field) is set. My long-retired "ppcdisasm" script inserted these hints unconditionally, despite 98% of them not being required. The code is much cleaner now. I read in some old MPW release notes that PPCAsm and PPCLink together exhibit a quirk when linking conditional branches to imported symbols. PPCAsm always assembles these conditional branches as if they were forward branches (that is, a + hint will always set the hint bit, and a - hint will never). I hoped to use this property to divine whether the NanoKernel was linked from one or many assembly files, but I was frustrated by the lack of conditional branches between files.
2018-04-15 07:05:02 +00:00
bne VMAllocateMemory_0x74
Initial commit
2017-11-19 04:11:07 +00:00
VMAllocateMemory_0xc0
common sense reform to v1 for v2 for v1 large vm diff getting shape correct Local_Panic -> VMPanic kdp revert to v1 teensy fix byte-perfect
2018-07-02 16:12:09 +00:00
lis r9, 4
Initial commit
2017-11-19 04:11:07 +00:00
cmplw cr7, r7, r9
rlwinm. r9, r7, 0, 0, 11
Remove unnecessary static branch hints These + and - characters in a branch mnemonic can cause the assembler to produce conditional branch instructions with that hint the branch predictor. The default for forward branches is -, and for backward branches is +. If a mnemonic is issued with the opposite sign, then bit 10 of the instruction (the LSB of the BO field) is set. My long-retired "ppcdisasm" script inserted these hints unconditionally, despite 98% of them not being required. The code is much cleaner now. I read in some old MPW release notes that PPCAsm and PPCLink together exhibit a quirk when linking conditional branches to imported symbols. PPCAsm always assembles these conditional branches as if they were forward branches (that is, a + hint will always set the hint bit, and a - hint will never). I hoped to use this property to divine whether the NanoKernel was linked from one or many assembly files, but I was frustrated by the lack of conditional branches between files.
2018-04-15 07:05:02 +00:00
blt cr7, VMReturnMinus1
bne VMReturnMinus1
memretry in some shape
2018-07-24 04:56:38 +00:00
lwz r14, KDP.CurMap.SegMapPtr(r1)
Initial commit
2017-11-19 04:11:07 +00:00
rlwinm r9, r7, 19, 25, 28
lwzx r14, r14, r9
clrlwi r9, r7, 0x10
lhz r8, 0x0000(r14)
b VMAllocateMemory_0xf4
VMAllocateMemory_0xf0
lhzu r8, 0x0008(r14)
VMAllocateMemory_0xf4
lhz r16, 0x0002(r14)
subf r8, r8, r9
cmplw cr7, r8, r16
Remove unnecessary static branch hints These + and - characters in a branch mnemonic can cause the assembler to produce conditional branch instructions with that hint the branch predictor. The default for forward branches is -, and for backward branches is +. If a mnemonic is issued with the opposite sign, then bit 10 of the instruction (the LSB of the BO field) is set. My long-retired "ppcdisasm" script inserted these hints unconditionally, despite 98% of them not being required. The code is much cleaner now. I read in some old MPW release notes that PPCAsm and PPCLink together exhibit a quirk when linking conditional branches to imported symbols. PPCAsm always assembles these conditional branches as if they were forward branches (that is, a + hint will always set the hint bit, and a - hint will never). I hoped to use this property to divine whether the NanoKernel was linked from one or many assembly files, but I was frustrated by the lack of conditional branches between files.
2018-04-15 07:05:02 +00:00
bgt cr7, VMAllocateMemory_0xf0
Initial commit
2017-11-19 04:11:07 +00:00
add r8, r8, r5
cmplw cr7, r8, r16
Remove unnecessary static branch hints These + and - characters in a branch mnemonic can cause the assembler to produce conditional branch instructions with that hint the branch predictor. The default for forward branches is -, and for backward branches is +. If a mnemonic is issued with the opposite sign, then bit 10 of the instruction (the LSB of the BO field) is set. My long-retired "ppcdisasm" script inserted these hints unconditionally, despite 98% of them not being required. The code is much cleaner now. I read in some old MPW release notes that PPCAsm and PPCLink together exhibit a quirk when linking conditional branches to imported symbols. PPCAsm always assembles these conditional branches as if they were forward branches (that is, a + hint will always set the hint bit, and a - hint will never). I hoped to use this property to divine whether the NanoKernel was linked from one or many assembly files, but I was frustrated by the lack of conditional branches between files.
2018-04-15 07:05:02 +00:00
bgt cr7, VMReturnMinus1
Initial commit
2017-11-19 04:11:07 +00:00
lwz r16, 0x0004(r14)
slwi r8, r7, 16
andi. r16, r16, 0xe01
cmpwi r16, 0xa01
or r8, r8, r5
addi r5, r5, 0x01
Remove unnecessary static branch hints These + and - characters in a branch mnemonic can cause the assembler to produce conditional branch instructions with that hint the branch predictor. The default for forward branches is -, and for backward branches is +. If a mnemonic is issued with the opposite sign, then bit 10 of the instruction (the LSB of the BO field) is set. My long-retired "ppcdisasm" script inserted these hints unconditionally, despite 98% of them not being required. The code is much cleaner now. I read in some old MPW release notes that PPCAsm and PPCLink together exhibit a quirk when linking conditional branches to imported symbols. PPCAsm always assembles these conditional branches as if they were forward branches (that is, a + hint will always set the hint bit, and a - hint will never). I hoped to use this property to divine whether the NanoKernel was linked from one or many assembly files, but I was frustrated by the lack of conditional branches between files.
2018-04-15 07:05:02 +00:00
bne VMReturnMinus1
Initial commit
2017-11-19 04:11:07 +00:00
stw r8, 0x0000(r14)
Remove unnecessary static branch hints These + and - characters in a branch mnemonic can cause the assembler to produce conditional branch instructions with that hint the branch predictor. The default for forward branches is -, and for backward branches is +. If a mnemonic is issued with the opposite sign, then bit 10 of the instruction (the LSB of the BO field) is set. My long-retired "ppcdisasm" script inserted these hints unconditionally, despite 98% of them not being required. The code is much cleaner now. I read in some old MPW release notes that PPCAsm and PPCLink together exhibit a quirk when linking conditional branches to imported symbols. PPCAsm always assembles these conditional branches as if they were forward branches (that is, a + hint will always set the hint bit, and a - hint will never). I hoped to use this property to divine whether the NanoKernel was linked from one or many assembly files, but I was frustrated by the lack of conditional branches between files.
2018-04-15 07:05:02 +00:00
bnel cr6, VMAllocateMemory_0x2e8
Initial commit
2017-11-19 04:11:07 +00:00
rotlwi r15, r15, 0x0a
ori r15, r15, 0xc00
stw r15, 0x0004(r14)
Start to reverse the legacy VM subsystem
2018-02-03 12:56:13 +00:00
lwz r7, KDP.TotalPhysicalPages(r1)
Initial commit
2017-11-19 04:11:07 +00:00
subf r7, r5, r7
Start to reverse the legacy VM subsystem
2018-02-03 12:56:13 +00:00
stw r7, KDP.TotalPhysicalPages(r1)
Lots of work on Address Spaces
2018-04-23 15:22:55 +00:00
stw r7, KDP.VMLogicalPages(r1)
Initial commit
2017-11-19 04:11:07 +00:00
slwi r8, r7, 12
intelligent structures
2018-07-09 08:13:00 +00:00
stw r8, KDP.SysInfo.UsableMemorySize(r1)
stw r8, KDP.SysInfo.LogicalMemorySize(r1)
common sense reform to v1 for v2 for v1 large vm diff getting shape correct Local_Panic -> VMPanic kdp revert to v1 teensy fix byte-perfect
2018-07-02 16:12:09 +00:00
addi r14, r1, 120
looks good
2018-07-06 13:44:52 +00:00
lwz r15, KDP.PARPageListPtr(r1)
common sense reform to v1 for v2 for v1 large vm diff getting shape correct Local_Panic -> VMPanic kdp revert to v1 teensy fix byte-perfect
2018-07-02 16:12:09 +00:00
li r8, 0
addi r7, r7, -0x01
ori r8, r8, 0xffff
VMAllocateMemory_0x34c
cmplwi r7, 0xffff
lwzu r16, 0x0008(r14)
rotlwi r9, r15, 0x0a
ori r9, r9, 0xc00
stw r8, 0x0000(r16)
stw r9, 0x0004(r16)
addis r15, r15, 0x04
addis r7, r7, -0x01
bgt VMAllocateMemory_0x34c
sth r7, 0x0002(r16)
Initial commit
2017-11-19 04:11:07 +00:00
b VMReturn1
common sense reform to v1 for v2 for v1 large vm diff getting shape correct Local_Panic -> VMPanic kdp revert to v1 teensy fix byte-perfect
2018-07-02 16:12:09 +00:00
Initial commit
2017-11-19 04:11:07 +00:00
VMAllocateMemory_0x2e8
lwz r16, 0x0000(r15)
Start to reverse the legacy VM subsystem
2018-02-03 12:56:13 +00:00
lwz r7, KDP.TotalPhysicalPages(r1)
looks good
2018-07-06 13:44:52 +00:00
lwz r8, KDP.PARPageListPtr(r1)
Initial commit
2017-11-19 04:11:07 +00:00
slwi r7, r7, 2
add r7, r7, r8
slwi r8, r5, 2
subf r7, r8, r7
cmplw r15, r7
Remove unnecessary static branch hints These + and - characters in a branch mnemonic can cause the assembler to produce conditional branch instructions with that hint the branch predictor. The default for forward branches is -, and for backward branches is +. If a mnemonic is issued with the opposite sign, then bit 10 of the instruction (the LSB of the BO field) is set. My long-retired "ppcdisasm" script inserted these hints unconditionally, despite 98% of them not being required. The code is much cleaner now. I read in some old MPW release notes that PPCAsm and PPCLink together exhibit a quirk when linking conditional branches to imported symbols. PPCAsm always assembles these conditional branches as if they were forward branches (that is, a + hint will always set the hint bit, and a - hint will never). I hoped to use this property to divine whether the NanoKernel was linked from one or many assembly files, but I was frustrated by the lack of conditional branches between files.
2018-04-15 07:05:02 +00:00
beqlr
Initial commit
2017-11-19 04:11:07 +00:00
subi r7, r7, 4
VMAllocateMemory_0x310
lwzx r9, r15, r8
cmplw r15, r7
stw r9, 0x0000(r15)
addi r15, r15, 0x04
Remove unnecessary static branch hints These + and - characters in a branch mnemonic can cause the assembler to produce conditional branch instructions with that hint the branch predictor. The default for forward branches is -, and for backward branches is +. If a mnemonic is issued with the opposite sign, then bit 10 of the instruction (the LSB of the BO field) is set. My long-retired "ppcdisasm" script inserted these hints unconditionally, despite 98% of them not being required. The code is much cleaner now. I read in some old MPW release notes that PPCAsm and PPCLink together exhibit a quirk when linking conditional branches to imported symbols. PPCAsm always assembles these conditional branches as if they were forward branches (that is, a + hint will always set the hint bit, and a - hint will never). I hoped to use this property to divine whether the NanoKernel was linked from one or many assembly files, but I was frustrated by the lack of conditional branches between files.
2018-04-15 07:05:02 +00:00
blt VMAllocateMemory_0x310
Initial commit
2017-11-19 04:11:07 +00:00
VMAllocateMemory_0x324
cmpwi r8, 0x04
subi r8, r8, 4
stwu r16, 0x0004(r7)
addi r16, r16, 0x1000
Remove unnecessary static branch hints These + and - characters in a branch mnemonic can cause the assembler to produce conditional branch instructions with that hint the branch predictor. The default for forward branches is -, and for backward branches is +. If a mnemonic is issued with the opposite sign, then bit 10 of the instruction (the LSB of the BO field) is set. My long-retired "ppcdisasm" script inserted these hints unconditionally, despite 98% of them not being required. The code is much cleaner now. I read in some old MPW release notes that PPCAsm and PPCLink together exhibit a quirk when linking conditional branches to imported symbols. PPCAsm always assembles these conditional branches as if they were forward branches (that is, a + hint will always set the hint bit, and a - hint will never). I hoped to use this property to divine whether the NanoKernel was linked from one or many assembly files, but I was frustrated by the lack of conditional branches between files.
2018-04-15 07:05:02 +00:00
bgt VMAllocateMemory_0x324
Initial commit
2017-11-19 04:11:07 +00:00
blr
Reverse some VM functions (Daniel) 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.
2018-02-18 03:17:23 +00:00
;This function gets sent an page# for a page in the main mac os memory area and returns a bunch of useful info on it.
;Return values that mention HTAB are undefined when the PTE is not in the HTAB
;HTAB residence is determined by bit 20 (value 0x800) of the PTE. This is often checked by a bltl cr5
Initial commit
2017-11-19 04:11:07 +00:00
Reverse some VM functions (Daniel) 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.
2018-02-18 03:17:23 +00:00
; ARG page# r4, KDP.VMMaxVirtualPages r9,
; RET PTE_flags CR, HTAB_upper r8, HTAB_lower r9, PTE_value r16, HTAB_entry_loc r14, PTE_loc r15,
Initial commit
2017-11-19 04:11:07 +00:00
Reverse some VM functions (Daniel) 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.
2018-02-18 03:17:23 +00:00
GetPARPageInfo ; OUTSIDE REFERER
cmplw cr4, r4, r9 ;r9 is VMMaxVirtualPages by convention
looks good
2018-07-06 13:44:52 +00:00
lwz r15, KDP.PARPageListPtr(r1)
Initial commit
2017-11-19 04:11:07 +00:00
slwi r8, r4, 2
Remove unnecessary static branch hints These + and - characters in a branch mnemonic can cause the assembler to produce conditional branch instructions with that hint the branch predictor. The default for forward branches is -, and for backward branches is +. If a mnemonic is issued with the opposite sign, then bit 10 of the instruction (the LSB of the BO field) is set. My long-retired "ppcdisasm" script inserted these hints unconditionally, despite 98% of them not being required. The code is much cleaner now. I read in some old MPW release notes that PPCAsm and PPCLink together exhibit a quirk when linking conditional branches to imported symbols. PPCAsm always assembles these conditional branches as if they were forward branches (that is, a + hint will always set the hint bit, and a - hint will never). I hoped to use this property to divine whether the NanoKernel was linked from one or many assembly files, but I was frustrated by the lack of conditional branches between files.
2018-04-15 07:05:02 +00:00
bge cr4, GetPARPageInfo_0x40
Reverse some VM functions (Daniel) 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.
2018-02-18 03:17:23 +00:00
GetPARPageInfo_0x10
lwzux r16, r15, r8 ;get PTE from KDP.FlatPageListPointer
lwz r14, KDP.HTABORG(r1)
mtcrf 0x07, r16 ;copy bits 20-31 to cr
rlwinm r8, r16, 23, 9, 28;convert page# into an index
rlwinm r9, r16, 0, 0, 19;get unshifted page#
Remove unnecessary static branch hints These + and - characters in a branch mnemonic can cause the assembler to produce conditional branch instructions with that hint the branch predictor. The default for forward branches is -, and for backward branches is +. If a mnemonic is issued with the opposite sign, then bit 10 of the instruction (the LSB of the BO field) is set. My long-retired "ppcdisasm" script inserted these hints unconditionally, despite 98% of them not being required. The code is much cleaner now. I read in some old MPW release notes that PPCAsm and PPCLink together exhibit a quirk when linking conditional branches to imported symbols. PPCAsm always assembles these conditional branches as if they were forward branches (that is, a + hint will always set the hint bit, and a - hint will never). I hoped to use this property to divine whether the NanoKernel was linked from one or many assembly files, but I was frustrated by the lack of conditional branches between files.
2018-04-15 07:05:02 +00:00
bgelr cr5 ;return if PTE is not in HTAB
fixes
2018-07-15 09:34:52 +00:00
bns cr7, SystemCrash;panic if the PTE is in the HTAB but isn't mapped to a real page
Reverse some VM functions (Daniel) 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.
2018-02-18 03:17:23 +00:00
lwzux r8, r14, r8 ;get first word of PTE from HTAB
lwz r9, 0x0004(r14);get second word of PTE from HTAB
Initial commit
2017-11-19 04:11:07 +00:00
mtcrf 0x80, r8
common sense reform to v1 for v2 for v1 large vm diff getting shape correct Local_Panic -> VMPanic kdp revert to v1 teensy fix byte-perfect
2018-07-02 16:12:09 +00:00
rlwimi r16, r9, 29, 27, 27
rlwimi r16, r9, 27, 28, 28
mtcrf 0x07, r16
Remove unnecessary static branch hints These + and - characters in a branch mnemonic can cause the assembler to produce conditional branch instructions with that hint the branch predictor. The default for forward branches is -, and for backward branches is +. If a mnemonic is issued with the opposite sign, then bit 10 of the instruction (the LSB of the BO field) is set. My long-retired "ppcdisasm" script inserted these hints unconditionally, despite 98% of them not being required. The code is much cleaner now. I read in some old MPW release notes that PPCAsm and PPCLink together exhibit a quirk when linking conditional branches to imported symbols. PPCAsm always assembles these conditional branches as if they were forward branches (that is, a + hint will always set the hint bit, and a - hint will never). I hoped to use this property to divine whether the NanoKernel was linked from one or many assembly files, but I was frustrated by the lack of conditional branches between files.
2018-04-15 07:05:02 +00:00
bltlr ;return if PTE is valid
fixes
2018-07-15 09:34:52 +00:00
bl SystemCrash;panic if PTE isn't valid but is in the HTAB
Initial commit
2017-11-19 04:11:07 +00:00
Reverse some VM functions (Daniel) 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.
2018-02-18 03:17:23 +00:00
GetPARPageInfo_0x40 ;some kind of little-used code path for when VMMaxVirtualPages is invalid? ROM overlay?
common sense reform to v1 for v2 for v1 large vm diff getting shape correct Local_Panic -> VMPanic kdp revert to v1 teensy fix byte-perfect
2018-07-02 16:12:09 +00:00
lis r9, 4
Initial commit
2017-11-19 04:11:07 +00:00
cmplw cr4, r4, r9
rlwinm. r9, r4, 0, 0, 11
Remove unnecessary static branch hints These + and - characters in a branch mnemonic can cause the assembler to produce conditional branch instructions with that hint the branch predictor. The default for forward branches is -, and for backward branches is +. If a mnemonic is issued with the opposite sign, then bit 10 of the instruction (the LSB of the BO field) is set. My long-retired "ppcdisasm" script inserted these hints unconditionally, despite 98% of them not being required. The code is much cleaner now. I read in some old MPW release notes that PPCAsm and PPCLink together exhibit a quirk when linking conditional branches to imported symbols. PPCAsm always assembles these conditional branches as if they were forward branches (that is, a + hint will always set the hint bit, and a - hint will never). I hoped to use this property to divine whether the NanoKernel was linked from one or many assembly files, but I was frustrated by the lack of conditional branches between files.
2018-04-15 07:05:02 +00:00
blt cr4, VMReturnMinus1;return failure if r4<VMMaxVirtualPages
bne VMReturnMinus1 ;return failure if bits 0-11 of r4 are non-zero
memretry in some shape
2018-07-24 04:56:38 +00:00
lwz r15, KDP.CurMap.SegMapPtr(r1);this appears to be an array of 8-byte structures.
Reverse some VM functions (Daniel) 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.
2018-02-18 03:17:23 +00:00
rlwinm r9, r4, 19, 25, 28;copy bits 12-15 or r4 to bits 25-28 of r9
lwzx r15, r15, r9 ;do an index for some reason
clrlwi r9, r4, 0x10 ;copy bits 16-31 to r9
Initial commit
2017-11-19 04:11:07 +00:00
lhz r8, 0x0000(r15)
Reverse some VM functions (Daniel) 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.
2018-02-18 03:17:23 +00:00
b GetPARPageInfo_0x70
Initial commit
2017-11-19 04:11:07 +00:00
Reverse some VM functions (Daniel) 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.
2018-02-18 03:17:23 +00:00
GetPARPageInfo_0x6c
Initial commit
2017-11-19 04:11:07 +00:00
lhzu r8, 0x0008(r15)
Reverse some VM functions (Daniel) 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.
2018-02-18 03:17:23 +00:00
GetPARPageInfo_0x70
Initial commit
2017-11-19 04:11:07 +00:00
lhz r16, 0x0002(r15)
subf r8, r8, r9
cmplw cr4, r8, r16
Remove unnecessary static branch hints These + and - characters in a branch mnemonic can cause the assembler to produce conditional branch instructions with that hint the branch predictor. The default for forward branches is -, and for backward branches is +. If a mnemonic is issued with the opposite sign, then bit 10 of the instruction (the LSB of the BO field) is set. My long-retired "ppcdisasm" script inserted these hints unconditionally, despite 98% of them not being required. The code is much cleaner now. I read in some old MPW release notes that PPCAsm and PPCLink together exhibit a quirk when linking conditional branches to imported symbols. PPCAsm always assembles these conditional branches as if they were forward branches (that is, a + hint will always set the hint bit, and a - hint will never). I hoped to use this property to divine whether the NanoKernel was linked from one or many assembly files, but I was frustrated by the lack of conditional branches between files.
2018-04-15 07:05:02 +00:00
bgt cr4, GetPARPageInfo_0x6c
Initial commit
2017-11-19 04:11:07 +00:00
lwz r9, 0x0004(r15)
andi. r16, r9, 0xc00
cmpwi cr6, r16, 0x400
cmpwi cr7, r16, 0xc00
Remove unnecessary static branch hints These + and - characters in a branch mnemonic can cause the assembler to produce conditional branch instructions with that hint the branch predictor. The default for forward branches is -, and for backward branches is +. If a mnemonic is issued with the opposite sign, then bit 10 of the instruction (the LSB of the BO field) is set. My long-retired "ppcdisasm" script inserted these hints unconditionally, despite 98% of them not being required. The code is much cleaner now. I read in some old MPW release notes that PPCAsm and PPCLink together exhibit a quirk when linking conditional branches to imported symbols. PPCAsm always assembles these conditional branches as if they were forward branches (that is, a + hint will always set the hint bit, and a - hint will never). I hoped to use this property to divine whether the NanoKernel was linked from one or many assembly files, but I was frustrated by the lack of conditional branches between files.
2018-04-15 07:05:02 +00:00
beq GetPARPageInfo_0xac
beq cr6, GetPARPageInfo_0xb4
bne cr7, VMReturnMinus1
Initial commit
2017-11-19 04:11:07 +00:00
slwi r8, r8, 2
rlwinm r15, r9, 22, 0, 29
crset cr4_lt
Reverse some VM functions (Daniel) 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.
2018-02-18 03:17:23 +00:00
b GetPARPageInfo_0x10
Initial commit
2017-11-19 04:11:07 +00:00
Reverse some VM functions (Daniel) 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.
2018-02-18 03:17:23 +00:00
GetPARPageInfo_0xac
Initial commit
2017-11-19 04:11:07 +00:00
slwi r8, r8, 12
add r9, r9, r8
Reverse some VM functions (Daniel) 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.
2018-02-18 03:17:23 +00:00
GetPARPageInfo_0xb4
Initial commit
2017-11-19 04:11:07 +00:00
rlwinm r16, r9, 0, 0, 19
crclr cr4_lt
rlwinm r9, r9, 0, 22, 19
rlwimi r16, r9, 1, 25, 25
rlwimi r16, r9, 31, 26, 26
xori r16, r16, 0x20
rlwimi r16, r9, 29, 27, 27
common sense reform to v1 for v2 for v1 large vm diff getting shape correct Local_Panic -> VMPanic kdp revert to v1 teensy fix byte-perfect
2018-07-02 16:12:09 +00:00
rlwimi r16, r9, 28, 28, 28
Initial commit
2017-11-19 04:11:07 +00:00
rlwimi r16, r9, 2, 29, 29
ori r16, r16, 0x01
mtcrf 0x07, r16
blr
Reverse some VM functions (Daniel) 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.
2018-02-18 03:17:23 +00:00
;updates stored PTE and HTAB entry for PTE
;r16 is PTE value
;r15 is address of stored PTE
;r8 is lower word of HTAB entry
;r9 is upper word of HTAB entry
;r14 is address of HTAB entry
EditPTEInHTAB ; OUTSIDE REFERER
Initial commit
2017-11-19 04:11:07 +00:00
stw r16, 0x0000(r15)
Reverse some VM functions (Daniel) 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.
2018-02-18 03:17:23 +00:00
;just updates HTAB entry
common sense reform to v1 for v2 for v1 large vm diff getting shape correct Local_Panic -> VMPanic kdp revert to v1 teensy fix byte-perfect
2018-07-02 16:12:09 +00:00
EditLowerPTEOnlyInHTAB
stw r8, 0x0000(r14)
Reverse some VM functions (Daniel) 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.
2018-02-18 03:17:23 +00:00
EditPTEOnlyInHTAB ; OUTSIDE REFERER
stw r9, 0x0004(r14);upper word of HTAB entry contains valid bit
common sense reform to v1 for v2 for v1 large vm diff getting shape correct Local_Panic -> VMPanic kdp revert to v1 teensy fix byte-perfect
2018-07-02 16:12:09 +00:00
slwi r8, r4, 12
sync
tlbie r8
Initial commit
2017-11-19 04:11:07 +00:00
sync
Reverse some VM functions (Daniel) 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.
2018-02-18 03:17:23 +00:00
blr
Initial commit
2017-11-19 04:11:07 +00:00
Reverse some VM functions (Daniel) 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.
2018-02-18 03:17:23 +00:00
;Removes a page from the HTAB.
;Called right after GetPARPageInfo, with either a bl or a bltl cr5
;
;also updates NK statistics?
;r9 is low word of HTAB entry
;r14 ia address of HTAB entry
;r15 is address of stored PTE
;r16 is PTE value
RemovePTEFromHTAB ; OUTSIDE REFERER
intelligent structures
2018-07-09 08:13:00 +00:00
lwz r8, KDP.NKInfo.HashTableDeleteCount(r1);update a value in NanoKernelInfo
Reverse some VM functions (Daniel) 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.
2018-02-18 03:17:23 +00:00
rlwinm r16, r16, 0, 21, 19 ;update PTE flags to indicate not in HTAB
Initial commit
2017-11-19 04:11:07 +00:00
addi r8, r8, 0x01
intelligent structures
2018-07-09 08:13:00 +00:00
stw r8, KDP.NKInfo.HashTableDeleteCount(r1)
Reverse some VM functions (Daniel) 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.
2018-02-18 03:17:23 +00:00
rlwimi r16, r9, 0, 0, 19 ;move page# back into PTE
Reverse PPC-68k context switching (incomplete)
2018-03-31 08:17:23 +00:00
_InvalNCBPointerCache scratch=r8
Reverse some VM functions (Daniel) 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.
2018-02-18 03:17:23 +00:00
li r8, 0x00 ;0 upper HTAB word
li r9, 0x00 ;0 lower HTAB word
b EditPTEInHTAB ;update stored PTE and invalidate HTAB entry
Initial commit
2017-11-19 04:11:07 +00:00
VMSecondLastExportedFunc ; OUTSIDE REFERER
Start to reverse the legacy VM subsystem
2018-02-03 12:56:13 +00:00
lwz r8, KDP.PTEGMask(r1)
Initial commit
2017-11-19 04:11:07 +00:00
; VMLastExportedFunc
VMLastExportedFunc
Start to reverse the legacy VM subsystem
2018-02-03 12:56:13 +00:00
lwz r14, KDP.HTABORG(r1)
Initial commit
2017-11-19 04:11:07 +00:00
slwi r9, r4, 12
mfsrin r6, r9
xor r9, r6, r4
slwi r7, r9, 6
and r8, r8, r7
lwzux r7, r14, r8
lwz r8, 0x0008(r14)
lwz r9, 0x0010(r14)
lwz r5, 0x0018(r14)
cmpwi r7, 0x00
cmpwi cr1, r8, 0x00
cmpwi cr2, r9, 0x00
cmpwi cr3, r5, 0x00
Remove unnecessary static branch hints These + and - characters in a branch mnemonic can cause the assembler to produce conditional branch instructions with that hint the branch predictor. The default for forward branches is -, and for backward branches is +. If a mnemonic is issued with the opposite sign, then bit 10 of the instruction (the LSB of the BO field) is set. My long-retired "ppcdisasm" script inserted these hints unconditionally, despite 98% of them not being required. The code is much cleaner now. I read in some old MPW release notes that PPCAsm and PPCLink together exhibit a quirk when linking conditional branches to imported symbols. PPCAsm always assembles these conditional branches as if they were forward branches (that is, a + hint will always set the hint bit, and a - hint will never). I hoped to use this property to divine whether the NanoKernel was linked from one or many assembly files, but I was frustrated by the lack of conditional branches between files.
2018-04-15 07:05:02 +00:00
bge VMLastExportedFunc_0x87
bge cr1, VMLastExportedFunc_0x83
bge cr2, VMLastExportedFunc_0x7f
bge cr3, VMLastExportedFunc_0x7b
Initial commit
2017-11-19 04:11:07 +00:00
lwzu r7, 0x0020(r14)
lwz r8, 0x0008(r14)
lwz r9, 0x0010(r14)
lwz r5, 0x0018(r14)
cmpwi r7, 0x00
cmpwi cr1, r8, 0x00
cmpwi cr2, r9, 0x00
cmpwi cr3, r5, 0x00
Remove unnecessary static branch hints These + and - characters in a branch mnemonic can cause the assembler to produce conditional branch instructions with that hint the branch predictor. The default for forward branches is -, and for backward branches is +. If a mnemonic is issued with the opposite sign, then bit 10 of the instruction (the LSB of the BO field) is set. My long-retired "ppcdisasm" script inserted these hints unconditionally, despite 98% of them not being required. The code is much cleaner now. I read in some old MPW release notes that PPCAsm and PPCLink together exhibit a quirk when linking conditional branches to imported symbols. PPCAsm always assembles these conditional branches as if they were forward branches (that is, a + hint will always set the hint bit, and a - hint will never). I hoped to use this property to divine whether the NanoKernel was linked from one or many assembly files, but I was frustrated by the lack of conditional branches between files.
2018-04-15 07:05:02 +00:00
bge VMLastExportedFunc_0x87
bge cr1, VMLastExportedFunc_0x83
bge cr2, VMLastExportedFunc_0x7f
blt cr3, VMLastExportedFunc_0xd7
Initial commit
2017-11-19 04:11:07 +00:00
VMLastExportedFunc_0x7b
addi r14, r14, 0x08
VMLastExportedFunc_0x7f
addi r14, r14, 0x08
VMLastExportedFunc_0x83
addi r14, r14, 0x08
VMLastExportedFunc_0x87
intelligent structures
2018-07-09 08:13:00 +00:00
lwz r9, KDP.NKInfo.HashTableCreateCount(r1)
Initial commit
2017-11-19 04:11:07 +00:00
rlwinm r8, r6, 7, 1, 24
addi r9, r9, 0x01
intelligent structures
2018-07-09 08:13:00 +00:00
stw r9, KDP.NKInfo.HashTableCreateCount(r1)
Initial commit
2017-11-19 04:11:07 +00:00
rlwimi r8, r4, 22, 26, 31
Start to reverse the legacy VM subsystem
2018-02-03 12:56:13 +00:00
lwz r9, KDP.PageAttributeInit(r1)
Initial commit
2017-11-19 04:11:07 +00:00
oris r8, r8, 0x8000
rlwimi r9, r16, 0, 0, 19
common sense reform to v1 for v2 for v1 large vm diff getting shape correct Local_Panic -> VMPanic kdp revert to v1 teensy fix byte-perfect
2018-07-02 16:12:09 +00:00
rlwimi r9, r16, 5, 23, 23
Initial commit
2017-11-19 04:11:07 +00:00
rlwimi r9, r16, 3, 24, 24
rlwimi r9, r16, 31, 26, 26
rlwimi r9, r16, 1, 25, 25
xori r9, r9, 0x40
rlwimi r9, r16, 30, 31, 31
Start to reverse the legacy VM subsystem
2018-02-03 12:56:13 +00:00
lwz r7, KDP.HTABORG(r1)
Initial commit
2017-11-19 04:11:07 +00:00
ori r16, r16, 0x801
subf r7, r7, r14
rlwimi r16, r7, 9, 0, 19
blr
VMLastExportedFunc_0xd7
mr r7, r27
mr r8, r29
mr r9, r30
mr r5, r31
mr r16, r28
mr r14, r26
mflr r6
slwi r27, r4, 12
memretry in some shape
2018-07-24 04:56:38 +00:00
bl PutPTE
fixes
2018-07-15 09:34:52 +00:00
bnel SystemCrash
Initial commit
2017-11-19 04:11:07 +00:00
mr r27, r7
mr r29, r8
mr r30, r9
mr r31, r5
mr r28, r16
mr r26, r14
mtlr r6
common sense reform to v1 for v2 for v1 large vm diff getting shape correct Local_Panic -> VMPanic kdp revert to v1 teensy fix byte-perfect
2018-07-02 16:12:09 +00:00
lwz r9, KDP.VMLogicalPages(r1)
b GetPARPageInfo
Initial commit
2017-11-19 04:11:07 +00:00
; major_0x09c9c
major_0x09c9c ; OUTSIDE REFERER
happy
2018-07-06 13:30:48 +00:00
addi r8, r1, KDP.PARPerSegmentPLEPtrs
Start to reverse the legacy VM subsystem
2018-02-03 12:56:13 +00:00
lwz r9, KDP.TotalPhysicalPages(r1)
common sense reform to v1 for v2 for v1 large vm diff getting shape correct Local_Panic -> VMPanic kdp revert to v1 teensy fix byte-perfect
2018-07-02 16:12:09 +00:00
rlwimi r8, r7, 18, 28, 29
Initial commit
2017-11-19 04:11:07 +00:00
cmplw r7, r9
lwz r8, 0x0000(r8)
rlwinm r7, r7, 2, 14, 29
Remove unnecessary static branch hints These + and - characters in a branch mnemonic can cause the assembler to produce conditional branch instructions with that hint the branch predictor. The default for forward branches is -, and for backward branches is +. If a mnemonic is issued with the opposite sign, then bit 10 of the instruction (the LSB of the BO field) is set. My long-retired "ppcdisasm" script inserted these hints unconditionally, despite 98% of them not being required. The code is much cleaner now. I read in some old MPW release notes that PPCAsm and PPCLink together exhibit a quirk when linking conditional branches to imported symbols. PPCAsm always assembles these conditional branches as if they were forward branches (that is, a + hint will always set the hint bit, and a - hint will never). I hoped to use this property to divine whether the NanoKernel was linked from one or many assembly files, but I was frustrated by the lack of conditional branches between files.
2018-04-15 07:05:02 +00:00
bge VMReturnMinus1
Initial commit
2017-11-19 04:11:07 +00:00
lwzx r9, r8, r7
rlwinm r9, r9, 0, 0, 19
blr
Reference in New Issue Copy Permalink