A range swapped for zero views now bumps the commit generation and calls the observer like a commit or a direct mapping, so the AGC write tracker stamps its blocks and a cached texture over it is not reused with the texels from before the swap.
Making an unbacked PRT page writable is unmeasured on the console and recorded as debt, so the AMM test no longer requires the throw. It still checks the read-only zero views and the VirtualProtect refusal.
Unbacked PRT pages were private read-only commits, so every page that was
read took its own host page. They are now views of one pagefile-backed
section created read-only, so the range costs one page however large and
no view of it can be made writable. Host imports treat such views as
read-only memory instead of asking for a read-write alias.
Allocate more pages for a PRT range than the pool holds and check the range still reads zero, then allocate one page, write it, and check the next allocation is refused the same way.
Fragment the pool into single free pages, map a range no single run holds, check each page keeps its own data, and check an exhausted pool still reports no free run.
_wstat64, the FindFirstFileExW listing and std::filesystem::file_size
report the size of a file symbolic link itself (0). stat therefore gave
0 for linked files, and APR resolved them as empty, so Unity treated a
linked globalgamemanagers as empty and never read it.
stat takes the size from the handle it already opens, which follows the
link. The APR listing skips reparse points, and names missing from it
are sized through stat.
Co-Authored-By: Claude Opus 5.5 <[email protected]>
One queue for APR and AMM buffers kept an AMM buffer behind an APR buffer
waiting on an address that the AMM buffer writes, so neither ran.
Marvel's Wolverine does this: an APR buffer waits on a counter that the
WriteAddress commands of later AMM buffers advance, and its loading
stopped. APR and AMM buffers now keep their order within their own queue.
Co-Authored-By: Claude Opus 5.5 <[email protected]>
The AMM ranges were reserved at the last 64 GiB of the guest arena and
the reservation threw when that window was not free. On Windows the
stacks of the threads that exist before the arena is reserved (the main
thread and the loader's workers) are placed at random addresses and are
left in the arena as host regions; when one fell in the last 64 GiB, the
first AMM use threw "fixed guest mapping ... overlaps a host region in
the guest arena". Reserve the highest free 64 GiB window instead: the
last 64 GiB when it is free, and the window just below an occupied part
of it otherwise.
sceKernelAprSubmitCommandBuffer ran the whole buffer on the submitting
thread, so a WaitOnAddress or WaitOnCounter that the submitter itself
satisfies after the submit returned never returned. A buffer now runs on
the submitting thread until such a wait; the rest of it, and every APR or
AMM buffer submitted after it, runs in order on one APR thread.
sceKernelAprWaitCommandBuffer and sceAmprAmmWaitCommandBufferCompletion
wait for that completion.
Co-Authored-By: Claude Opus 5.5 <[email protected]>
Claude-Session: https://claude.ai/code/session_01Wu3nuU87RJwjkkmxqft3sD
The AMM ranges were reserved address-less on first use, so they took the
lowest free address of the arena, directly after the title's last mapping,
where the title's next hinted maps go. They are now reserved at a fixed
place, the last 64 GiB of the guest arena, which maps without MAP_FIXED and
the hints derived from them do not reach; a reservation that cannot be made
there throws.
Fixes#3146
sceKernelAprSubmitCommandBuffer rejected a buffer object with EINVAL
unless sceAmprAprCommandBufferConstructor had tagged it. The tag is
AnyPS5's own: in the retail layout the type word only carries state
bits and the constructors zero the object, so a zero-filled object
bound with SetBuffer is a valid APR buffer.
CRI's file system in Sonic Origins (PPSA05324) lays out its
AprCommandBuffer objects in its own zeroed work memory and never calls
the constructors. Its first read submit failed with 0x80020016, and the
CRI file system stopped there.
Co-Authored-By: Claude Opus 5.5 <[email protected]>
memob