12 Commits

Author	SHA1	Message	Date
Stephen Miller	528a060709	Core: Memory code cleanup and further direct memory fixes (#3655) ... * Remove mapped dmem type Since physical addresses can be mapped multiple times, tracking mapped pages is not necessary. This also allows me to significantly simplify the MapMemory physical address validation logic. * Proper implementation for sceKernelMtypeprotect I've rewritten SetDirectMemoryType to use virtual addresses instead of physical addresses, allowing it to be used in sceKernelMtypeprotect. To accommodate this change, I've also moved address and size alignment out of MemoryManager::Protect * Apply memory type in sceKernelMemoryPoolCommit * Organization Some potentially important missing mutexes, removed some unnecessary mutexes, moved some mutexes after early error returns, and updated copyright dates * Iterator logic cleanup Missing end check in ClampRangeSize, and adjusted VirtualQuery and DirectMemoryQuery. * Clang * Adjustments * Properly account for behavior differences in MapDirectMemory2 Undid the changes to direct memory areas, added more robust logic for changing dma types, and fixed DirectMemoryQuery to return hardware-accurate direct memory information in cases where dmas split here, but not on real hardware. I've also changed MapMemory's is_exec flag to a validate_dmem flag, used to handle alternate behavior in MapDirectMemory2. is_exec is now determined by the use of MemoryProt::CpuExec instead. * Clang * Add execute permissions to physical backing Needed for executable mappings to work properly on Windows, fixes regression in RE2 with prior commit. * Minor variable cleanup * Update memory.h * Prohibit direct memory mappings with exec protections Did a quick hardware test to confirm, only seems to be prohibited for dmem mappings though. * Update memory.cpp	2025-09-26 02:28:32 -07:00
Stephen Miller	eeee6ad0ee	Memory: Implement sceKernelMemoryPoolGetBlockStats (#3646) ... * Implement sceKernelMemoryPoolGetBlockStats Not entirely sure on the logic behind the cached blocks work, but flushed blocks seems to just be based on committed direct memory. * Fix comment	2025-09-24 02:40:26 -07:00
Stephen Miller	419ea140ab	Core: physical backing for flexible and pooled memory allocations (#3639) ... * Fix isDevKit Previously, isDevKit could increase the physical memory used above the length we reserve in the backing file. * Physical backing for flexible allocations I took the simple approach here, creating a separate map for flexible allocations and pretty much just copying over the logic used in the direct memory map. * Various fixups * Fix mistake #1 * Assert + clang * Fix 2 * Clang * Fix CanMergeWith Validate physical base for flexible mappings * Clang * Physical backing for pooled memory * Allow VMA splitting in NameVirtualRange This should be safe, since with the changes in this PR, the only issues that come from discrepancies between address space and vma_map are issues related to vmas being larger than address space mappings. NameVirtualRange will only ever shrink VMAs by naming part of one. * Fix * Fix NameVirtualRange * Revert NameVirtualRange changes Seems like it doesn't play nice for Windows * Clean up isDevKit logic We already log both isNeo and isDevKit in Emulator::Run, so the additional logging in MemoryManager::SetupMemoryRegions isn't really necessary. I've also added a separate constant for non-pro devkit memory, as suggested. Finally I've changed a couple constants to use the ORBIS prefix we generally follow here, instead of the SCE prefix. * Erase flexible memory contents from physical memory on unmap Flexible memory should not be preserved on unmap, so erase flexible contents from the physical backing when unmapping. * Expand flexible memory map Some games will end up fragmenting the physical backing space used for flexible memory. To reduce the frequency of this happening under normal circumstances, allocate the entirety of the remaining physical backing to the flexible memory map. This is effectively a workaround to the problem, but at the moment I think this should suffice. * Clang	2025-09-23 17:24:37 +03:00
Stephen Miller	d9dac05db2	Core: MapMemory fixes (#3142) ... * Validate requested dmem range in MapMemory Handles a rare edge case that only comes up when modding Driveclub * Specify type auto has failed us once again. * Types cleanup Just some basic tidying up. * Clang	2025-06-21 19:22:03 -07:00
Stephen Miller	5edd9ff54b	Improved sceKernelMapNamedFlexibleMemory logging (#3050) ... * More descriptive sceKernelMapNamedFlexibleMemory logging * Misc exports These functions are used by Overwatch: Origins Edition * Clang * Function parameter cleanup Changes the parameters on our sceKernelMapNamedFlexibleMemory and sceKernelMapFlexibleMemory functions to better align with our current standards.	2025-06-08 00:17:45 +03:00
Stephen Miller	6cdc52cdde	Core: More Memory Cleanup & Fixes (#2997) ... * Only perform GPU memory mapping when GPU can access it This better aligns with hardware observations, and should also speed up unmaps and decommits, since they don't need to be compared with the GPU max address anymore. * Reserve fixes ReserveVirtualRange seems to follow the 0x200000000 base address like MemoryPoolReserve does. Both also need checks in their flags Fixed path to ensure we're mapping in-bounds. If we're not in mapping to our address space, we'll end up reserving and returning the wrong address, which could lead to weird memory issues in games. I'll need to test on real hardware to verify if such changes are appropriate. * Better sceKernelMmap Handles errors where we would previously throw exceptions. Also moves the file logic to MapFile, since that way all the possible errors are in one place. Also fixes some function parameters to align with our current standards. * Major refactor MapDirectMemory, MapFlexibleMemory, ReserveVirtualRange, and MemoryPoolReserve all internally use mmap to perform their mappings. Naturally, this means that all functions have similar behaviors, and a lot of duplicate code. This add necessary conditional behavior to MapMemory so MemoryPoolReserve and ReserveVirtualRange can use it, without disrupting the behavior of MapDirectMemory or MapFlexibleMemory calls. * Accurate phys_addr for non-direct mappings * Properly handle GPU access rights Since my first commit restricts GPU mappings to memory areas with GPU access permissions, we also need to be updating the GPU mappings appropriately during Protect calls too. * Update memory.cpp * Update memory.h * Update memory.cpp * Update memory.cpp * Update memory.cpp * Revert "Update memory.cpp" This reverts commit 2c55d014c0. * Coalesce dmem map Aligns with hardware observations, hopefully shouldn't break anything since nothing should change hardware-wise when release dmem calls and unmap calls are performed? Either that or Windows breaks because Windows, will need to test. * Implement posix_mprotect Unity calls this Also fixes the names of sceKernelMprotect and sceKernelMtypeprotect, though that's more of a style change and can be reverted if requested. * Fix sceKernelSetVirtualRangeName Partially addresses a "regression" introduced when I fixed up some asserts. As noted in the code, this implementation is still slightly inaccurate, as handling this properly could cause regressions on Windows. * Unconditional assert in MapFile * Remove protect warning This is expected behavior, shouldn't need any logging. * Respect alignment Forgot to properly do this when updating ReserveVirtualRange and MemoryPoolReserve * Fix Mprotect on free memory On real hardware, this just does nothing. If something did get protected, there's no way to query that information. Therefore, it seems pretty safe to just behave like munmap and return size here. * Minor tidy-up No functional difference, but looks better.	2025-05-29 18:56:03 +03:00
Marcin Mikołajczyk	1832ec2ac2	Implement sceKernelIsStack (#2917)	2025-05-13 13:54:22 -07:00
Stephen Miller	6206986914	libkernel: Implement sceKernelMemoryPoolBatch (#2909) ... * Implement sceKernelMemoryPoolBatch I've tested Commit and Decommit on real hardware, haven't tested Protect or TypeProtect yet. Implementation is primarily based on our sceKernelBatchMap implementation. * Clang	2025-05-11 19:51:03 -07:00
Stephen Miller	6ece91c763	sceKernelVirtualQuery Fixes VI (#2904) ... * Reduce bitfield size Linux compilers automatically convert this, Windows not so much. * Static assert for VirtualQueryInfo struct size Since compilers can be weird, having a static assert for this will be helpful. Granted, this probably wont need changing after this PR.	2025-05-10 20:02:00 -07:00
Stephen Miller	6477dc4f1e	Core: Memory Fixes (#2872) ... * Fix VirtualQuery behavior on low addresses. * Fix VirtualQuery struct Somewhere in our BitField and array use, the size of our VirtualQuery struct became larger than the struct used on real hardware. Fixing this fixes some data corruption visible in the name parameter during my tests. * Default name to anon On real hardware, nameless mappings are given the name "anon:address" where address appears to be the address that made the memory call. For simplicity sake, I'll stick to the name "anon" for now. * Place an upper bound on returns from SearchFree Right now, this upper bound is set based on the limitations of our GPU buffer cache and page table. Someone with more experience in that area of code should probably fix that at some point. * More anons * Clang * Fix name in sceKernelMapNamedDirectMemory * strncpy instead of strcpy Hardcoded the constant size for now, I need to review how real hardware behaves here to determine if anything else is necessary for this to be accurate. * Fix name behavior All memory naming functions restrict the name size to a 31 character limit, and return `ORBIS_KERNEL_ERROR_ENAMETOOLONG` if that limit is exceeded. Since this value is constant for all functions involving names, I've defined it as a constant in kernel's memory.h, and used that in place of any hardcoded 32 character limits. * Error logging Hopefully this helps in catching the UFC regression? * Increase address space upper bound Probably needs heavy testing, especially on Mac/Windows. This increases the address space, as needed to accommodate strange memory behaviors seen in UFC. * VirtualQuery fix Due to limitations of certain platforms, we initialize our vma_map with 3 separate free mappings. As such, we need to use a while loop here to accurately query mappings with high addresses * Fix mappings to high addresses The PS4's GPU can only handle 40bit addresses. Our texture cache and buffer cache were designed around these limits, and mapping to higher addresses would cause segmentation faults and access violations. To fix these crashes, only map to the GPU if the mapping is fully contained within the address space the GPU should access. I'm open to suggestions on how to make this cleaner * Revert "Increase address space upper bound" This reverts commit 3d50eeeebb. * Revert VirtualQuery while loop Windows wasn't happy with this, again. Will try to debug and properly fix this when I have a good chance. * Fix asserts FindVMA, due to the way it's programmed, never actually returns vma_map.end(), the furthest it ever returns is the last valid memory area. All those asserts we involving vma_map.end() never actually trigger due to this. This commit removes redundant asserts, adds messages to asserts that were lacking them, and fixes all asserts designed to detect out of bounds memory accesses so they actually trigger. I've also fixed some potential memory safety issues. * Proper error behavior in QueryProtection Might as well handle this properly while I'm here. * Clang * More information about ReserveVirtualRange results Should help debug issues like the one in The Order: 1886 (CUSA00076) * Fix assert message * Update assert message Extra space * Fix my bug Oh hey, finally something that's my fault. * Fix rasterizer unmaps Should use adjusted_size here, otherwise we could unmap too much. Thanks to diegolix29 for spotting this. * Fix edge case in MapMemory Code comments explain everything. This should fix some memory asserts. * Fix fix Avoid running the code path if it's unnecessary, since there are many additional edge cases to handle when the VMA map is small. * Fix fix fix Should prevent infinite loops, haven't tested properly yet though. * Split logging for inputs and out_addr in ReserveVirtualRange Addresses review comments.	2025-05-09 12:33:04 -07:00
polybiusproxy	817a62468e	core: better memory configuration (#1896)	2024-12-28 12:03:00 +01:00
TheTurtle	c4506da0ae	kernel: Rewrite pthread emulation (#1440) ... * libkernel: Cleanup some function places * kernel: Refactor thread functions * kernel: It builds * kernel: Fix a bunch of bugs, kernel thread heap * kernel: File cleanup pt1 * File cleanup pt2 * File cleanup pt3 * File cleanup pt4 * kernel: Add missing funcs * kernel: Add basic exceptions for linux * gnmdriver: Add workload functions * kernel: Fix new pthreads code on macOS. (#1441) * kernel: Downgrade edeadlk to log * gnmdriver: Add sceGnmSubmitCommandBuffersForWorkload * exception: Add context register population for macOS. (#1444) * kernel: Pthread rewrite touchups for Windows * kernel: Multiplatform thread implementation * mutex: Remove spamming log * pthread_spec: Make assert into a log * pthread_spec: Zero initialize array * Attempt to fix non-Windows builds * hotfix: change incorrect NID for scePthreadAttrSetaffinity * scePthreadAttrSetaffinity implementation * Attempt to fix Linux * windows: Address a bunch of address space problems * address_space: Fix unmap of region surrounded by placeholders * libs: Reduce logging * pthread: Implement condvar with waitable atomics and sleepqueue * sleepq: Separate and make faster * time: Remove delay execution * Causes high cpu usage in Tohou Luna Nights * kernel: Cleanup files again * pthread: Add missing include * semaphore: Use binary_semaphore instead of condvar * Seems more reliable * libraries/sysmodule: log module on `sceSysmoduleIsLoaded` * libraries/kernel: implement `scePthreadSetPrio` --------- Co-authored-by: squidbus <175574877+squidbus@users.noreply.github.com> Co-authored-by: Daniel R. <47796739+polybiusproxy@users.noreply.github.com>	2024-11-21 22:59:38 +02:00