It now seems to fail on ENTER 1,0 not page faulting, as far as the comment just before it tells? But no page fault is thrown? It's logical address is 21000h(at SS:E$P=17:1000)?

Edit: When loading the PDE and PTE, they are loaded as 2027(PDE) and 21007(PTE). Those are both user-level privileges, with full write access and being present? But the PTE should have been updated immediately before that with:

1	updPageFlags 0x1000|(TEST_BASE>>12), PTE_SUPER_W

So it should have become a supervisor page? But somehow it isn't a supervisor page?

Edit: The enter instruction itself references said address as:
PDE=2027
PTE=21007

So clearly, the PTE flags aren't updated correctly.
So 9475(EIP with DEBUG set to 1) onwards isn't doing it's job correctly(making the PTE flags supervisor, writable).

Anyone can see what's going wrong?
Assembler generated ROM of test386.asm assembly output(segment 10h in running):

Code running:

$dit: Luckily the L*S instruction disassembly is just incorrect, not updating the modrm parameter disassembly correctly due to getting 0 instead of 16/32 on it's second parameter(operand size for modr/m disassembly). %he instruction executes correctly, as can be seen by the resultant register values and segment desceiptor loaded(pointing segment to 1000h(the PDBR base address).

Edit: It's updating the entry at logical and physical location 2080h(seems to be direct-mapped?)...
Edit: Looking at the page table initialozation, I can see that 0x1000 has the PDE, whkle 0x2000 has the only PTE(only 1MB mapped).
The PDE is correctly pointing to the PTE at 0x2000, so that's fine.
Now it's updating the PTE at 2080, so the 80h/4=20h PTE(logical memory 0x20000). So the table update works fine, it properly updates the entry for 0x20000?

But wasn't the enter instruction trying to use 21000(20000+1000) for it's PUSH EBP? ESP was 1004, decremented to 1000h for the pushed EBP. That address is written. Then, it just substracts 1 from ESP(bringing ESP to the changed page) and finishing the instruction? Said location isn't accessed or checked against paging, is it?

Just added the paging check for writes to the byte at SS:[SP] after ENTER finishes on 80386+. Now test386.asm continues to EE again1 😁

Also noticed missing EBP state save durimg faults. Now EBP is properly restored during ENTER faulting.

Edit: All tests are passing without errors, including EE. So the only problems left are with protected mode itself?

Just found a bug in the BIU TLB: it was handling TLB translation requests for writes as reads instead. Although that shouldn't cause huge problems(since it's cached as writes already during earlier stages). But it's still incorrect.

Edit: Yay:/ Now the TLB translation hangs because of infinite TLB fetches on a kernel privilege write access? (W=0, U=0, D=1 when written into the TLB, W=1, U=0, D=1 when trying to tranzlate(which fails, repeating the TLB fetch)).

After fixing the CPL checks to work properly, I now see test386.asm crashing on some strange stuff: it tries to execute a non-faulting test:

1   384                              <1> .write_nofault:
2   385 0000766F C70500F04900EFBEAD- <1> 	mov   [TESTPAGE_LIN], dword 0xdeadbeef
3   385 00007678 DE                  <1>
4   386 00007679 EB00                <1> 	jmp  .continue
5   387                              <1> 
6   388                              <1> .continue:
7   389                              <1> 
8   390                              <1> 	; if the fault happened in user mode switch back to ring0
9   391 0000767B F7C204000000        <1> 	test  edx, PF_USER
10   392 00007681 7408                <1> 	jz   .verify_bits
11   393 00007683 E876AAFFFF          <1> 	call  switchToRing0
12   394 00007688 5A                  <1> 	pop   edx ; restore edx
13   395 00007689 59                  <1> 	pop   ecx ; restore ecx
14   396 0000768A 5E                  <1> 	pop   esi ; restore esi

But the PDE(0x3005) and PTE(9F005) are both user-level, read-only, present pages. Thus the resulting privileges are: user privilege, read-only. The present bit faults first, so that passes it's test. Then it checks the read-only user privilege against CPL(0) and access(a write). CPL(supervisor) isn't checked against anything else than the U/S bit(which passes always in Supervisor mode). Then the read-only attribute is verified against the access(a write), which page faults(which shouldn't happen according to the source code)???

Anyone? What effect does the privilege level have on the read-only user privilege pages?

Thinking about it, I can find the problematic one looking at the last reported EAX,EBX,EDX registers at 0010:7639.

The last one that's reported is test PDE=5,PTE=5,PF=82. So that's matching the following row:

1   212 000074C0 050582              <1> db	PTE_USER_R,   PTE_USER_R,   PF_NOFAULT|PF_WRITE

But that's saying that a write to an user-mode page doesn't fault when executing a write? That doesn't match documentation, which says user-mode pages DO fault on writes when the combined rights are read-only?

Just tried Windows 3.0 with only HIMEM loaded on the 80386 emulation in real mode(/r switch). It errors out to hang with a Divide error now?
Edit: Turns out Windows 3.0 was just corrupted due to old CPU bugs when installing it. After reinstalling, it runs like a charm again(real mode checked only).
Standard mode gives the loading screen, then a permanent black screen(Black Screen of Death?)?