DarkFire01 · 2026-01-20T20:14:29Z

We barely have enough space in system PTEs for more than one 3rd party driver to be loaded in the system, on top of this some drivers (Intel) decide they want more than 32mb! And some (VboxWDDM) want to map a 256mb space!!

I’ve heard multiple times our x86 memory lay out is hard coded and not even sure what it wants to be. So here’s my pitch, because I surely cannot make it worse right?

This allows x86 to run more then 1 or 2 third party drivers. And allows the intel GPU driver to load at all.

Testbot runs (Filled in by Devs)

KVM x86: https://reactos.org/testman/compare.php?ids=106194,106196,106204
KVM x64: https://reactos.org/testman/compare.php?ids=105957,105964,105991
WHS: https://reactos.org/testman/compare.php?ids=106172,106191,106203
updated comparison chart with new PR rewrite:

	Before	After
MmNonPagedPoolStart	0xb1200000	0xb1d40000
MmNonPagedPoolEnd	0xffbe0000	0xffbe0000
MmSizeOfNonPagedPoolInBytes	0x3fd0000	0x6790000
MmPagedPoolStart	0xe1000000	0xe1000000
MmPagedPoolEnd	0xecbfffff	0xxf77fffff
MmSizeOfPagedPoolInBytes	0xbc00000	0x16800000
MmNumberOfSystemPtes	0xafdf	0x2bbff

DarkFire01 · 2026-01-20T20:20:07Z

Whoa GPUs!

HBelusca · 2026-01-20T21:09:52Z

I suppose you've seen this text?
https://git.reactos.org/?p=reactos.git;a=blob;f=ntoskrnl/mm/ARM3/mminit.c;hb=fc75870f1c127d7b5ffc51ba0c21571f1430f3ae#l44

ntoskrnl/mm/ARM3/i386/init.c

DarkFire01 · 2026-01-20T21:17:51Z

HBelusca reviewed

Jan 20, 2026

View reviewed changes

ntoskrnl/mm/ARM3/i386/init.c Show resolved Hide resolved

I suppose you've seen this text? https://git.reactos.org/?p=reactos.git;a=blob;f=ntoskrnl/mm/ARM3/mminit.c;hb=fc75870f1c127d7b5ffc51ba0c21571f1430f3ae#l44

I have and I don’t think this PR completely violates the root point that was made.

Out of curiosity, on your test system where the VboxWDDM would crash otherwise, what are the typical values of the following variables just before your fixup code is being run? :
MmNonPagedPoolStart, MmNonPagedSystemStart, MmNumberOfSystemPtes and NonPagedSystemSize, as well as your new PagedPoolEnd variable ?

DarkFire01 · 2026-01-20T21:33:19Z

Out of curiosity, on your test system where the VboxWDDM would crash otherwise, what are the typical values of the following variables just before your fixup code is being run? : MmNonPagedPoolStart, MmNonPagedSystemStart, MmNumberOfSystemPtes and NonPagedSystemSize, as well as your new PagedPoolEnd variable ?

I don't mind going and getting these, but id rather do it with the intel gpu driver which needs less extra stuff to make it work.

obsolete-is-better · 2026-01-23T23:41:40Z

The nvidia forceSW opengl bug appears to be resolved with this PR

Testing this did require an additional patch due to a regression effecting nvidia drivers
HBelusca@f9c1105

and a registry change to disable vsync
nvidia_opengl_disable_vsync.reg.txt

ntoskrnl/mm/ARM3/i386/init.c

tkreuzer · 2026-01-29T13:52:21Z

Btw, the memory layout(s) can be found here: https://reactos.org/wiki/Techwiki:Memory_Layout

DarkFire01 · 2026-01-30T21:54:39Z

This PR has been rewritten one more time.

(ntoskrnl\mm\mminit.c:139)           0x80000000 - 0x83000000	Boot Loaded Image
(ntoskrnl\mm\mminit.c:144)           0x83000000 - 0xB0000000	System PTE Space
(ntoskrnl\mm\mminit.c:148)           0xB0000000 - 0xB0083000	PFN Database
(ntoskrnl\mm\mminit.c:152)           0xB0083000 - 0xB0283000	ARM3 Non Paged Pool
(ntoskrnl\mm\mminit.c:156)           0xB9400000 - 0xBB400000	System View Space
(ntoskrnl\mm\mminit.c:160)           0xBB400000 - 0xC0000000	Session Space
(ntoskrnl\mm\mminit.c:163)           0xC0000000 - 0xC03FFFFF	Page Tables
(ntoskrnl\mm\mminit.c:166)           0xC0300000 - 0xC0300FFF	Page Directories
(ntoskrnl\mm\mminit.c:169)           0xC0400000 - 0xC07FFFFF	Hyperspace
(ntoskrnl\mm\mminit.c:172)           0xC1000000 - 0xE0FFFFFF	System Cache
(ntoskrnl\mm\mminit.c:176)           0xE1000000 - 0xE3800000	ARM3 Paged Pool
(ntoskrnl\mm\mminit.c:179)           0xFEB2E000 - 0xFFBE0000	Non Paged Pool Expansion PTE Space

opting for the system PTE region being placed in the unused space after Boot Loaded Image
this means another look is appreciated :) as that's a bit more complicated of a change and we want to make sure I didn't do something wrong.

Of course before anyone asks 58MBs of ram still boots

DarkFire01 · 2026-02-04T01:08:52Z

finally squeezed an updated ttest run out of the bots
https://reactos.org/testman/compare.php?ids=105882,105895,105920

ntoskrnl/mm/ARM3/i386/init.c

HBelusca · 2026-02-16T15:25:46Z

Not sure I'm fully understanding your table right:

	Before	After
MmNonPagedPoolStart	0xb1200000	0xb1d40000
MmNonPagedPoolEnd	0xffbe0000	0xffbe0000
MmSizeOfNonPagedPoolInBytes	0x3fd0000	0x6790000

So, in the "After" case, the nonpaged pool starts at an higher address than in the "Before" case, yet at the same time they both end up at the same address (thus, the nonpaged pool range in the "After" case is slightly smaller). And yet, in the "After" case, the size of the nonpaged pool is larger ?! Something is fishy.

ntoskrnl/include/internal/amd64/mm.h

ntoskrnl/mm/mminit.c

ntoskrnl/mm/ARM3/i386/init.c

ntoskrnl/mm/ARM3/mminit.c

HBelusca · 2026-02-16T15:50:30Z

For extra reference I'm linking some literature on the x86 memory map and the "known" (from public debugger symbols) global Mm variables that are also used by WinDbg for diagnostics:
https://techcommunity.microsoft.com/blog/askperf/memory-management---x86-virtual-address-space/372536
https://flylib.com/books/en/4.491.1.61/1/
https://www.cs.miami.edu/home/burt/journal/NT/memory.html

DarkFire01 · 2026-02-25T04:39:40Z

Not sure I'm fully understanding your table right:
Before After
MmNonPagedPoolStart 0xb1200000 0xb1d40000
MmNonPagedPoolEnd 0xffbe0000 0xffbe0000
MmSizeOfNonPagedPoolInBytes 0x3fd0000 0x6790000

So, in the "After" case, the nonpaged pool starts at an higher address than in the "Before" case, yet at the same time they both end up at the same address (thus, the nonpaged pool range in the "After" case is slightly smaller). And yet, in the "After" case, the size of the nonpaged pool is larger ?! Something is fishy.

Now that i got a brain, uh
So MmSizeOfNonPagedPoolInBytes is not supposed to equal MmNonPagedPoolEnd - MmNonPagedPoolStart i thought.
https://git.reactos.org/?p=reactos.git;a=blob;f=ntoskrnl/mm/ARM3/mminit.c;hb=fc75870f1c127d7b5ffc51ba0c21571f1430f3ae#l44

    //
    // Non paged pool comes after the PFN database
    //
    MmNonPagedPoolStart = (PVOID)((ULONG_PTR)MmPfnDatabase +
                                  (MxPfnAllocation << PAGE_SHIFT));

Unless I'm misunderstanding something here?

This gets assigned twice.
Don't me wrong, Not a lot of our memory manager's regions on x86 makes sense. and the codes documentation doesn't do a good job of explaining WHY imo, but i THINK this is fine?

HBelusca · 2026-02-26T18:50:05Z

This gets assigned twice. Don't me wrong, Not a lot of our memory manager's regions on x86 makes sense. and the codes documentation doesn't do a good job of explaining WHY imo, but i THINK this is fine?

I'll see. In the meantime, could you check this other question? -> #8613 (comment)

DarkFire01 · 2026-02-26T18:52:50Z

This gets assigned twice. Don't me wrong, Not a lot of our memory manager's regions on x86 makes sense. and the codes documentation doesn't do a good job of explaining WHY imo, but i THINK this is fine?

I'll see. In the meantime, could you check this other question? -> #8613 (comment)

I added an initialization for it.

HBelusca · 2026-02-26T19:28:42Z

ntoskrnl/mm/ARM3/i386/init.c

+     * Keep MmNonPagedSystemStart initialized for debugger (KD/Windbg) use.
+     * On x86 ARM3, the System PTE space is placed in the loader-gap region.
+     */
+    MmNonPagedSystemStart = MmSystemPteSpaceStart;


DarkFire01 requested review from HeisSpiter, ThFabba and tkreuzer as code owners January 20, 2026 20:14

github-actions bot added the kernel&hal Code changes to the ntoskrnl and HAL label Jan 20, 2026

binarymaster added the enhancement For PRs with an enhancement/new feature. label Jan 20, 2026

SigmaTel71 reviewed Jan 20, 2026

View reviewed changes

ntoskrnl/mm/ARM3/i386/init.c Outdated Show resolved Hide resolved
8000

SigmaTel71 reviewed Jan 20, 2026

View reviewed changes

ntoskrnl/mm/ARM3/i386/init.c Outdated Show resolved Hide resolved

HBelusca reviewed Jan 20, 2026

View reviewed changes

ntoskrnl/mm/ARM3/i386/init.c Outdated Show resolved Hide resolved

ntoskrnl/mm/ARM3/i386/init.c Outdated Show resolved Hide resolved

ntoskrnl/mm/ARM3/i386/init.c Outdated Show resolved Hide resolved

DarkFire01 force-pushed the PR-MoreSystemPTEs branch from d3bd973 to 3088e4f Compare January 28, 2026 01:10

tkreuzer requested changes Jan 28, 2026

View reviewed changes

ntoskrnl/mm/ARM3/i386/init.c Outdated Show resolved Hide resolved

ntoskrnl/mm/ARM3/i386/init.c Outdated Show resolved Hide resolved

ntoskrnl/mm/ARM3/i386/init.c Outdated Show resolved Hide resolved

ntoskrnl/mm/ARM3/i386/init.c Outdated Show resolved Hide resolved

DarkFire01 force-pushed the PR-MoreSystemPTEs branch 2 times, most recently from f669d66 to 0c759a5 Compare January 30, 2026 21:49

DarkFire01 requested a review from tkreuzer January 30, 2026 21:54

DarkFire01 force-pushed the PR-MoreSystemPTEs branch from 8589a58 to 369337f Compare January 30, 2026 21:56

DarkFire01 requested a review from HBelusca February 2, 2026 08:56

tkreuzer reviewed Feb 7, 2026

View reviewed changes

ntoskrnl/mm/ARM3/i386/init.c Outdated Show resolved Hide resolved

ntoskrnl/mm/ARM3/i386/init.c Outdated Show resolved Hide resolved

729A

ntoskrnl/mm/ARM3/i386/init.c Outdated Show resolved Hide resolved

ntoskrnl/mm/ARM3/i386/init.c Outdated Show resolved Hide resolved

DarkFire01 force-pushed the PR-MoreSystemPTEs branch 2 times, most recently from cdf0155 to 670c91e Compare February 9, 2026 03:53

DarkFire01 changed the title ~~[NTOS:ARM3] i386 specific: Change calculation for more system PTEs~~ [NTOS:ARM3] Change calculation for more system PTEs Feb 11, 2026

DarkFire01 requested a review from tkreuzer February 11, 2026 14:49

cbialorucki approved these changes Feb 13, 2026

View reviewed changes

tkreuzer approved these changes Feb 16, 2026

View reviewed changes

HBelusca reviewed Feb 16, 2026

View reviewed changes

DarkFire01 force-pushed the PR-MoreSystemPTEs branch from 6f0cb5b to 8af0471 Compare February 25, 2026 04:52

Doug-Lyons approved these changes Feb 26, 2026

View reviewed changes

HBelusca reviewed Feb 26, 2026

View reviewed changes

HBelusca approved these changes Feb 26, 2026

View reviewed changes

DarkFire01 force-pushed the PR-MoreSystemPTEs branch 2 times, most recently from 63e8d97 to 53933d0 Compare March 5, 2026 05:04

github-actions bot added the ROSTESTS Label for ROS testcases PRs. label Mar 5, 2026

DarkFire01 added 3 commits March 5, 2026 02:27

[NTOSKRNL] Increase MI_NUMBER_SYSTEM_PTES for AMD64

931b627

[NTOS:MM] Move the system PTE space on x86 to a different spot

cc53fe3

[KMTESTS] Adjust KmTest

87360cd

DarkFire01 force-pushed the PR-MoreSystemPTEs branch from 53933d0 to 87360cd Compare March 5, 2026 10:28

DarkFire01 merged commit 4cba65d into reactos:master Mar 5, 2026
66 of 67 checks passed

DarkFire01 deleted the PR-MoreSystemPTEs branch March 8, 2026 16:41

Uh oh!

Conversation

Uh oh!

Testbot runs (Filled in by Devs)

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Uh oh!

Reviewers

Assignees

Labels

Projects

Milestone

Development

Uh oh!

8 participants