Direct memory, flexible memory and pools
Guest addresses are real host addresses. Direct memory is a sparse shared physical pool mapped into that space, and MemoryPool adds reserve, commit and batch operations on top of the same backing.
Repository notes through October 10, 2026
The guest address is the host address
Guest x86-64 code runs natively and contains absolute addresses, so PS5PCEM cannot relocate the process into an arbitrary allocation. The memory module reserves the console layout before any module is loaded. The system-managed window starts at 0x40000 and runs to just under 32 GiB. System-reserved and device windows follow. The user window on Windows and Linux runs from 0x10_0000_0000 to 0xFC_0000_0000, 944 GiB of address space. macOS starts that window higher and gets 560 GiB.
Those ranges are reservations, not committed RAM. Pages are committed in 16 KiB units when a mapping is created, and unmapping decommits them while the outer reservation stays. Another host allocation cannot steal the guest address between uses.
Direct and flexible memory
Direct memory is the guest's name for physical video memory. The title reserves a physical range, then maps it. The two steps are separate. Mapping checks that the whole physical range was reserved, translates CPU and GPU protection, and either commits the exact fixed address or searches for an aligned hole. The same physical offset can be mapped at several virtual addresses, and those aliases are coherent because they share one sparse backing object.
A fixed map into a range the title already reserved commits inside the reservation. Releasing the reservation first would drop the title's claim on the pieces it has not mapped yet. Physical memory is released in the shape the title asks for, which may be a hole in the middle or a span of several reservations. Flexible memory uses the same address-space table, with a platform-default budget of 4 GiB, and searches the system-managed window from 0x02_0000_0000 before falling back to the user window.
MemoryPool and Windows commit
The six libkernel MemoryPool exports reserve a virtual arena, expand physical capacity, commit and decommit shared backing, run ordered batches, and report block statistics. Donated blocks cannot be mapped as ordinary direct memory or released while they are committed. Batch commit, decommit, protect and type changes work. Batch MOVE stays unsupported and returns an error rather than pretending the blocks moved.
On Windows, aligned direct-memory views share 64 KiB section views. Temporary uploads, readbacks and 16 KiB guest pages therefore do not each become their own ever-growing commit charge. Queries of a reservation use the guest's 72-byte virtual-query record and report half-open ranges with the original protection bits.
What is implemented
- Fixed guest address windows, committed in 16 KiB pages and released without giving up the reservation.
- Coherent aliases of one direct-memory physical offset.
- Flexible memory with the 4 GiB default budget and fixed, no-overwrite and partial unmaps.
- MemoryPool reserve, expand, commit, decommit, statistics and ordered batches except MOVE.
What is still missing
- MemoryPool batch MOVE is explicitly unsupported.
- A release of a range the title does not own is still an error.
- The reservations are virtual. Only pages the title maps consume host commit.
Related mechanisms
What these pages are