Commit Graph

116 Commits

Author SHA1 Message Date
Scott Schuster f38408ef5c fix(libkernel): keep stack protection inside the stack and never throw while restoring it
Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
2026-10-11 02:28:03 -05:00
Scott Schuster 24ae0a98d0 fix(libkernel): check the requested stack range and restore guard pages at thread exit
A stack base need not be page aligned (it is not on Linux), so rounding the
range down first could leave the stack and miss the stack path. The range the
guest asked for is now checked against the guest stack, and the rounded
pages are protected, as FreeBSD rounds the address down.

A thread that exits with part of its stack protected left those pages to the
next thread that reused the stack. Protected stack pages are recorded, and a
thread's stack is made readable and writable again when it is unregistered at
exit.

AI-assisted (Claude Code).

Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
2026-10-11 02:28:03 -05:00
Scott Schuster 67bccf6dd4 fix(libkernel): change the protection of guest thread stack pages
On Windows a guest thread runs on its host thread's stack, which is not a
registered guest allocation, so mprotect on any of its pages failed with
EINVAL. A guest that guards the bottom of its own stack (Dolphin's JIT
read-protects 64 KiB there to catch stack overflows) got an error where the
PS5 changes the protection.

A range that lies inside a live guest thread stack, with no GPU access
requested, now takes the native protection directly. Ranges that cross the
stack's bounds are still rejected.

AI-assisted (Claude Code).

Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
2026-10-11 02:28:03 -05:00
xXPBSXx aace6a3f38 fix(libkernel): report the largest free direct memory block from sceKernelAvailableDirectMemorySize
The call returned the first free gap in the range instead of the largest free block.

Co-Authored-By: Claude Sonnet 5.5 <noreply@anthropic.com>
2026-10-11 00:58:28 +02:00
raghav314 be1f501525 fix(agc): import GPU-mapped guest memory when it is mapped
The registry calls an observer on the mapping thread, after the registry
lock is released, with the ranges a kernel mapping gave GPU access:
direct and flexible maps with it, and fixed remaps with it over a
registered range (a reservation). The mutation looks them up while it
still holds the lock and hands them over weakly, with the registry
generation it ended at, so the observer does not keep a range alive.
The driver imports those ranges on its current device, so an
address-based build finds the import instead of pinning the memory on
the queue that first uses it. A range that gains GPU access through
sceKernelMprotect, and AnyPS5's own libc heap, are still imported on
first use.

The import at map does not reconcile the other imports with the
registry, so its cost does not grow with the number of imports. It skips
a range that is gone, and any range when the imports were reconciled
with a newer registry since; the next lookup imports those as before.
It installs the pin waiter as the other import paths do, so unmapping a
range imported at map retires its import. The live import bytes are kept as a
running total instead of being summed over every import. Once the import
table belongs to the current device the import takes only the table's
lock; the first import on a device (which runs the write-watch probe)
and a device that was just replaced go through the GPU lock. Clearing
the observer waits for calls already running.

Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
2026-10-11 00:23:23 +02:00
Dean 262c031692
Merge pull request #2907 from oneandonlydean/carry/libkernel-reserved-range-hint
fix(libkernel): map non-fixed hints inside a reserved range in place
2026-10-11 09:26:41 +13:00
ps54all 3444ebf5cd fix(libkernel): map non-fixed hints inside a reserved range in place
A map without MAP_FIXED whose hint lies wholly inside a range still
reserved by sceKernelReserveVirtualRange is placed at the hint, as a fixed
map into the reservation would be. Hints outside reservations and ranges
that are partly mapped keep their hint behaviour. The reservation is
checked under the registry mutation, so it cannot be released and its
address reused between the check and the map (MarcZX100, #2687).

Fixes #2687

Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01A2cY3SsTYnh4u4ZtEr2Adx
2026-10-11 07:10:29 +13:00
Scott Schuster 58e871cf2a fix(libkernel): place sceKernelReserveVirtualRange at its address hint
Without MAP_FIXED the address is a hint, as for FreeBSD's mmap: the reservation goes at the hint when that range is free, else at the first free range above it. The hint was dropped, so every hinted reservation landed at the lowest free address.

RetroArch (PPSA99169) reserves its cores' direct-memory heap near 0x2000000000 outside the GPU window (0x200000000-0x300000000) and refuses a range inside it; with every reservation at 0x200400000 the heap was never made, and Dolphin's first aligned allocation returned null.

AI-assisted (Claude Code).

Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
2026-10-10 07:59:00 -05:00
Dean Galvin d9f8400351 fix(libkernel): answer munlock from the guest mapping state on Linux
An unmapped range inside the guest arena stays a PROT_NONE host
reservation, so host munlock succeeds on it. Check the guest mapping
state first, as msync does, and return ENOMEM for ranges the guest
has not mapped or reserved.
2026-10-10 22:56:07 +13:00
jeffrey12cali e4e0702946 fix(guest-arena): place guest address space in the PS5 window on Linux
The arena constructor was Windows-only, so on Linux Available() was false: the guest heap fell back to the host allocator and direct memory landed wherever the kernel pleased. Titles that require a low virtual address rejected the mapping and re-issued the identical request, which surfaced as a start-up assert inside their own allocator.

Seed the window from the mappings that already exist instead of reserving it up front, because a PROT_NONE reservation of the whole range starves the kernel's own top-down mmap, which picks addresses just below the stack inside that range. Commit, reset and set-protection become portable so the arena owns its used ranges on both platforms, and fixed mappings are checked against the arena's used ranges rather than against EEXIST from a reservation.

The window-placement and no-overwrite checks in guest_memory were compiled only for Windows; they now run on Linux too, and the window check fails without this change.

Fixes #692
2026-10-10 22:56:07 +13:00
raghav314 c11a9cb59f fix(agc): address-based builds map only memory mapped for the GPU
The registry records whether a range was mapped or protected with GPU
access (0x10/0x20), and an address-based build leaves out ranges without
it, as the console's GPU page tables do. The main image is registered
without GPU access; the title's own mprotect with GPU bits adds it.

Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
2026-10-10 14:34:34 +05:30
Adrià 8fded89e6b
Merge pull request #1803 from tv7/fix/mprotect-guest-module-images
fix(libkernel): reprotect bundled guest module images on Windows
2026-10-10 10:45:37 +02:00
Adrià 874c144712
Merge pull request #1909 from TheAggie/feat/libkernel-mmap-aligned-super
feat(libkernel): accept MAP_ALIGNED_SUPER in mmap
2026-10-10 10:44:57 +02:00
Lexroid 9f1d7b0516 fix(libkernel): reprotect bundled guest module images on Windows
On Windows, sceKernelMprotect accepted only the executable's image and threw
"Memory protection of a foreign image is not supported" for every other
image. Bundled title modules are relinked into DLLs named <module>.guest.prx,
so a title that reprotects its own module pages failed. Dying Light 2's
bundled libNRD does this at start-up (#1794).

DoMprotect now also accepts images whose file name ends in .guest.prx, and
registers their committed pages like the executable's. Other images are
still refused.

Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
2026-10-10 10:23:42 +02:00
Pouare514 03d975af3c fix(libkernel): reject malformed ranges in sceKernelReleaseDirectMemory
A zero, unaligned, overflowing or out-of-range length reached the physical pool, where a sub-page length silently freed a whole page and fragmented the block map, and an out-of-range length walked the page table past the backing store. Validate alignment and bounds up front and return EINVAL instead.
2026-10-10 08:22:59 +02:00
Adrià 40aeb97d57
Merge pull request #1152 from alfalfa-star/perf/linux-direct-memory-import-chunks
perf(agc): share one dma-buf import per 64 MiB of Linux direct memory
2026-10-10 08:14:40 +02:00
Scott Schuster 456dc87879 feat(libkernel): accept MAP_ALIGNED_SUPER in mmap
An anonymous private mapping with MAP_ALIGNED_SUPER (FreeBSD MAP_ALIGNED(1))
is placed on a 2 MiB superpage boundary. Yamagi Quake II requests it for its
hunk allocations of 2 MiB and more.

Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
2026-10-10 00:47:40 -05:00
Dean 698254f048
Merge pull request #2236 from mrk1987/fix/release-direct-memory-unmaps-views
fix(libkernel): unmap direct memory views when the memory is released
2026-10-10 17:45:32 +13:00
Dean b860fa0c9f
Merge pull request #1929 from MarcZX100/fix/virtualquery-partial-unmap
fix(libkernel): query non-readable live mappings
2026-10-10 17:42:50 +13:00
Hannah Lyons d7e52cb295 feat(libkernel): implement madvise 2026-10-09 21:22:44 -04:00
alfalfa-star b7443c4424 perf(agc): share one dma-buf import per 64 MiB of Linux direct memory
Every direct memory allocation had a memfd of its own, so each one the
GPU used became its own udmabuf and its own imported buffer object. An
imported buffer object cannot be always valid in the GPU VM: amdgpu
validates every one of them at every command submission. PPSA14632
(LEGO Horizon Adventures) imports about 7000 allocations, 5800 of them
64 KiB, and each vkQueueSubmit took about 2.3 ms (5 s per 10 s, held
under the GPU mutex). A standalone test shows the cost follows the
count of imported dma-buf buffer objects, not their size or the count
of ordinary allocations.

- libkernel: on Linux all direct memory lives in one sparse memfd of
  DIRECT_MEMORY_SIZE, at file offset = physical address
  (PhysicalBacking keeps the file and its offset; SharedBacking returns
  that offset). A range allocated again is zeroed through a temporary
  mapping, as the old per-allocation memfd was.
- Driver: an import of shared direct memory that lies inside one
  64 MiB chunk of the file binds its own VkBuffer into that chunk's
  memory, one udmabuf import per chunk (HostImport::chunk holds it, so
  it lives until the last buffer bound to it retires). Ranges that
  cross a chunk or do not meet the buffer alignment are imported alone
  as before.

On PPSA14632 vkQueueSubmit drops from about 2400 us to 46 us on
average, the GPU idles 36 ms instead of 172 ms per present, and
presents go from about 40 to 80-97 per 10 s.

Released direct memory stays committed in the file (see
TechnicalDebt.md): a live chunk import pins its pages.

Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
2026-10-10 03:21:53 +02:00
Adrià Franch 0e32f3662b fix(memory): throw when the direct memory write view cannot be mapped 2026-10-10 00:53:38 +02:00
TibixDev e7f4b1a1fd perf(memory): write tracked direct memory through backing views
Retain host backing views for emulator writes and completion labels. Validate full spans, preserve write versions and GPU ordering, and keep the fallback for other mappings. Test remaps, aliases, access checks, partial failures, tracking, view lifetime, and completion ordering.

Written with AI assistance.
2026-10-10 00:53:29 +02:00
MarcZX100 eb1e6b22a9 test(libkernel): assert virtual query lease ordering 2026-10-09 22:10:33 +00:00
MarcZX100 f7de40f9bb fix(libkernel): query non-readable live guest ranges 2026-10-09 22:10:33 +00:00
Praveen Kumar 6f62ec6a6f fix(libkernel): query current guest mapping extents
Use the current registered range after protection splits and partial unmaps, including FIND_NEXT lookups. Add a regression covering extents, protection and surviving contents.

AI-assisted: yes
2026-10-09 22:10:32 +00:00
hikazey 0bff6da3d3 feat(libkernel): implement msync
msync follows FreeBSD 11's kern_msync and vm_map_sync over the guest's
mappings as sceKernelVirtualQuery reports them: the address is rounded
down to the page, a range that wraps and MS_ASYNC with MS_INVALIDATE are
EINVAL, an unmapped start or page is ENOMEM, and length 0 checks the
mapping that holds the address. The guest has no file mappings, so a
successful call has nothing to write back. MS_INVALIDATE on a mapped
range throws, since FreeBSD's EBUSY for mlocked pages needs lock state
that is not tracked.

EVO-PLAYER PPSA99039 v0.11.0 imports it.

Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
2026-10-09 23:38:58 +02:00
Jan Šlégl 1078608783 feat(libkernel): implement munlock beside mlock
sceKernelMunlock and the POSIX munlock unlock the page-rounded range with
FreeBSD's results: 0 for a mapped range whether or not it is locked, EINVAL
for a range that wraps around zero, ENOMEM for an unmapped range. On Linux
the host munlock gives them. On Windows a reserved placeholder counts as
mapped only while the guest reservation or protection registry covers it,
and a region VirtualUnlock refuses as not fully locked is unlocked page by
page, as VirtualUnlock is all-or-nothing. sceKernelMlock shares the range
rounding.

Co-Authored-By: Claude Fable 5.1 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_012GLfKH7Sqe51wX254k1XsV
2026-10-09 15:14:57 +02:00
Jan Šlégl 892aa8b5ee feat(libkernel): implement mlock
The POSIX form of sceKernelMlock: 0 on success, -1 with errno (EINVAL,
ENOMEM, EPERM, EAGAIN) where the sce form returns the kernel error, as
munmap and mprotect do beside it.

Co-Authored-By: Claude Fable 5.1 <noreply@anthropic.com>
2026-10-09 14:47:29 +02:00
Andreas 24474e3d28 fix(libkernel): unmap direct memory views when the memory is released
Releasing direct memory left the virtual ranges that mapped it registered,
so sceKernelVirtualQuery reported them as flexible memory at offset 0 and
titles walking a range with FIND_NEXT released physical page 0.

Collect every view of the released pages before freeing them and unmap
them through UnmapRegistered, as shadPS4's MemoryManager::Free does.

Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
2026-10-09 14:42:17 +02:00
Dean 8763483811
Merge pull request #1370 from gjonn/fix/kernel-fixed-map-replaces-overlap
fix(libkernel): replace partly overlapped allocations with a fixed mapping
2026-10-08 22:35:53 +13:00
kjhq 35ae8742a9 feat(libkernel): implement POSIX mprotect
mprotect changes the protection of guest memory through the same path
as sceKernelMprotect and reports failures through errno: EINVAL for a
null or overflowing range or a range the allocation tracker rejects,
ENOMEM when allocation fails. A zero length succeeds.

Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
2026-10-08 08:24:06 +02:00
Adrià 311c0493bd
Merge pull request #957 from JAB-dev/feat/kernel-flexible-internal-hint
feat(libkernel): accept flag 0x8000 in sceKernelMapNamedFlexibleMemoryInternal
2026-10-08 07:42:56 +02:00
Gjon Gojcevic 5cf013a299 fix(libkernel): replace partly overlapped allocations with a fixed mapping
A fixed mapping without no-overwrite unmaps the registered pieces it overlaps before mapping, as it already did when the range lay inside registered allocations.
2026-10-07 20:31:08 -04:00
alfalfa-star 815d274736 feat(agc): import shared direct memory through udmabuf on Linux
On Linux, direct memory is a memfd mapped MAP_SHARED. amdgpu accepts only
private anonymous memory for a host pointer import (libdrm sets
AMDGPU_GEM_USERPTR_ANONONLY), so every import of direct memory failed with
VK_ERROR_INVALID_EXTERNAL_HANDLE and its ranges were copied.

When a host pointer import fails, the range's memfd slice is turned into a
dma-buf through /dev/udmabuf and imported with VK_EXT_external_memory_dma_buf.
The direct memory backing is sealed against shrinking and growing, as
udmabuf requires. libkernel reports the backing of a guest range through
GuestArenaSharedBacking. Without /dev/udmabuf, or past its size limit, the
range is copied as before. APS5_TRACE_HOST_IMPORT now prints the mappings
behind a failed import on Linux too.

Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
2026-10-07 23:09:16 +02:00
alfalfa-star b567bb8eed feat(libkernel): accept the audio coprocessor memory protection bits
A title maps direct memory with protection 0x3f2, which adds bits
0x100 and 0x200 to the CPU, GPU and AMPR bits, and the mapping threw.
They are the audio coprocessor (ACP) read and write bits, as named in
the KytyPS5 and etaHEN headers. The coprocessor work runs on the host
CPU, so they map to host read and read/write access like the GPU bits.

Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
2026-10-07 07:09:42 +02:00
JAB-dev 2dc53674f5 Merge branch 'main' of https://github.com/boykopovar/AnyPS5 into feat/kernel-flexible-internal-hint 2026-10-07 07:09:08 +02:00
Dean 0c952fe574
Merge pull request #994 from CnRJay/fix/map-no-overwrite-enomem
fix(libkernel): refuse fixed no-overwrite mappings over live memory with ENOMEM
2026-10-07 15:31:12 +13:00
Dean f6f47bf1de
Merge pull request #880 from adriadam10/feat/kernel-mtypeprotect-type
feat(kernel): apply the memory type in sceKernelMtypeprotect
2026-10-07 15:28:25 +13:00
Dean fc5341aca2
Merge pull request #872 from Fishybeing/fix/guard-nominmax
build(windows): guard NOMINMAX before including windows.h
2026-10-07 15:24:47 +13:00
Dean 97a6604f81
Merge pull request #883 from Fishybeing/fix/memorypool-header-guard
fix(libkernel): correct the MemoryPool.hpp include guard
2026-10-07 11:05:38 +13:00
Chad e9c8664d43 fix(libkernel): refuse fixed no-overwrite mappings over live memory with ENOMEM
MAP_FIXED | MAP_NO_OVERWRITE over a range that already holds an
allocation fails with ENOMEM and leaves the mapping in place, as in
fpPS4's TVirtualManager.check_fixed. UFC 6 (PPSA23566) relies on it to
probe for a free address and aborted on the throw.

Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
2026-10-06 17:04:06 -05:00
CnR 7e3dcbc27e
feat(libkernel): implement sceKernelReleaseFlexibleMemory (#952)
* feat(libkernel): implement sceKernelReleaseFlexibleMemory

Unmaps the range through sceKernelMunmap, which returns its pages to
the flexible memory budget, as fpPS4 and prosper do.

Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>

* test(libkernel): keep the flexible memory release check apart from the batch map checks

Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>

---------

Co-authored-by: Claude Opus 5.5 <noreply@anthropic.com>
2026-10-07 10:20:07 +13:00
Dean 2b049e3ef6
Merge pull request #879 from adriadam10/feat/kernel-batchmap-invalid-entry
feat(kernel): reject invalid sceKernelBatchMap2 entries with EINVAL
2026-10-07 10:12:23 +13:00
Dean 2d0bbbfb4a
Merge pull request #702 from merwie/feat/kernel-is-stack
feat(libkernel): implement sceKernelIsStack
2026-10-07 10:00:46 +13:00
JAB-dev 2093e74661 feat(libkernel): accept flag 0x8000 in sceKernelMapNamedFlexibleMemoryInternal
The SDK 9 libc.prx heap maps its arenas with flag 0x8000, which threw as
an unsupported flag. The flag is ignored for this function, as sharpemu
does; other unknown flags still throw.

Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
2026-10-06 22:21:25 +02:00
Fishybeing 5f1c45c223 fix(libkernel): correct the MemoryPool.hpp include guard
The guard tested CORE_LIBS_PRX_LIBKERNEL_... but defined CORE_LIBS_PRX_LINKERNEL_..., so it never took effect and GCC reports -Wheader-guard.
2026-10-06 14:57:51 +02:00
Fishybeing 5a04d3cc9e build(windows): guard NOMINMAX before including windows.h
Four sources defined NOMINMAX unconditionally, which redefines the macro the build already passes and warns on every MinGW build. Use the #ifndef guard the rest of the tree uses.
2026-10-06 14:57:48 +02:00
Adrià Franch 109f120595 feat(kernel): apply the memory type in sceKernelMtypeprotect
Co-Authored-By: Claude <noreply@anthropic.com>
2026-10-06 14:32:47 +02:00
Adrià Franch ca6557aed1 feat(kernel): reject invalid sceKernelBatchMap2 entries with EINVAL
Co-Authored-By: Claude <noreply@anthropic.com>
2026-10-06 14:27:48 +02:00