On Linux kernels without PROCMAP_QUERY (before 6.11, which includes the
stock Ubuntu 24.04 kernel), every guest range check that misses the page
cache reads and parses /proc/self/maps up to the covering mapping. The
cache only covers the guest arena and the image, so ranges in the host
heap always miss. ASTRO BOT (PPSA21564) checks 96-byte shader headers
there from RegisteredHeader (through SameHeader) on every
sceAgcCreatePrimState and interpolant mapping, about 3,700 times per
second while it loads.
A read-only check of at most 4 KiB on such a kernel now first reads the
range into a scratch buffer with process_vm_readv on the own process.
If every byte is read, the range is readable. Anything else (a fault,
a partial read, a refused call, a write check or a larger range) takes
the path it took before, which also builds the failure message.
agc_driver_graphics runs a second time with APS5_NO_PROCMAP_QUERY=1, so
the fallback path is covered on kernels that have PROCMAP_QUERY too, and
LiveStack gains read-only checks: a readable range, and ranges that end
in a guard page.
Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
A title can hand the GPU a buffer or descriptor V# based at an address above the
Windows user-mode address space (Kena: Bridge of Spirits, PPSA01746, bases a V#
at 0xf00000000000). VirtualQuery fails for any address above
lpMaximumApplicationAddress, so describePages returned "not queried" and the
driver aborted with "AGC driver: cannot query guest memory", although nothing can
ever be mapped there and the shader never dereferences it.
Above the user address limit, report the range as unmapped (as the Linux
procmap/maps path already does for an uncovered range) instead of failing the
query. The limit is read once from GetSystemInfo.
Tested: Windows 11, MinGW-w64 GCC 15.2.0, Release, agc_driver_graphics_tests
passes with the change and fails without it ("cannot query guest memory").
GPUs tested: NVIDIA GeForce RTX 4070 SUPER.
Driver::Submit checks the title's submission packet, which the title
passes on its own thread stack. Host thread stacks are neither registry
mappings nor write-watched, so no page-state cache covers them and on
Linux every check scans /proc/self/maps line by line: about 1.5 ms per
submission on the render thread of PPSA21564 (66% of that thread's
samples in perf at the title).
A range between the calling thread's current frame and its stack's top
holds the frames of every caller, so it is mapped readable and writable
for as long as the call lasts; verify() now accepts it without a query.
A thread on another stack (a fiber's, a signal stack) has its frame
outside the thread's bounds and still gets the page query, as does any
range that runs past the stack's top or starts below the frame.
GetCurrentThreadStackLimits needs _WIN32_WINNT 0x0602 on MinGW, as
libkernel already sets; GuestMemory.cpp is compiled by several targets,
so the definition is a property of the source file.
