summaryrefslogtreecommitdiffstats
path: root/src/core/hle/kernel/vm_manager.cpp (follow)
Commit message (Collapse)AuthorAgeFilesLines
* kernel/vm_manager: Move variables closer to usage spots in MapPhysicalMemory/UnmapPhysicalMemoryLioncash2019-09-051-16/+10
| | | | Narrows the scope of variables down to where they're only necessary.
* kernel/vm_manager: Correct behavior in failure case of UnmapPhysicalMemory()Lioncash2019-08-301-0/+2
| | | | | | If an unmapping operation fails, we shouldn't be decrementing the amount of memory mapped and returning that the operation was successful. We should actually be returning the error code in this case.
* kernel/vm_manager: Reserve memory ahead of time for slow path in MergeAdjacentVMALioncash2019-08-301-1/+4
| | | | | | | Avoids potentially expensive (depending on the size of the memory block) allocations by reserving the necessary memory before performing both insertions. This avoids scenarios where the second insert may cause a reallocation to occur.
* kernel/vm_manager: std::move shared_ptr instance in MergeAdjacentVMALioncash2019-08-301-1/+1
| | | | Avoids an unnecessary atomic reference count increment and decrement.
* kernel/vm_manager: Deduplicate iterator creation in MergeAdjacentVMALioncash2019-08-301-7/+10
| | | | | | Avoids needing to read the same long sequence of code in both code paths. Also makes it slightly nicer to read and debug, as the locals will be able to be shown in the debugger.
* kernel/vm_manager: Simplify some std::vector constructor callsLioncash2019-08-301-2/+2
| | | | Same behavior, one less magic constant to read.
* kernel/vm_manager: Simplify some assertion messagesLioncash2019-08-301-10/+10
| | | | | Assertions already log out the function name, so there's no need to manually include the function name in the assertion strings.
* VM_Manager: Align allocated memory to 256bytesFernando Sahmkow2019-07-191-7/+8
| | | | | | This commit ensures that all backing memory allocated for the Guest CPU is aligned to 256 bytes. This due to how gpu memory works and the heavy constraints it has in the alignment of physical memory.
* Merge pull request #2690 from SciresM/physmem_fixesFernando Sahmkow2019-07-141-7/+283
|\ | | | | Implement MapPhysicalMemory/UnmapPhysicalMemory
| * Remove unicorn mappings/unmappingsMichael Scire2019-07-121-19/+0
| |
| * Prevent merging of device mapped memory blocks.Michael Scire2019-07-091-0/+5
| | | | | | | | | | | | | | This sets the DeviceMapped attribute for GPU-mapped memory blocks, and prevents merging device mapped blocks. This prevents memory mapped from the gpu from having its backing address changed by block coalesce.
| * physmem: add helpers, cleanup logic.Michael Scire2019-07-071-171/+154
| |
| * address review commentaryMichael Scire2019-07-071-1/+4
| |
| * Implement MapPhysicalMemory/UnmapPhysicalMemoryMichael Scire2019-07-071-8/+312
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | This implements svcMapPhysicalMemory/svcUnmapPhysicalMemory for Yuzu, which can be used to map memory at a desired address by games since 3.0.0. It also properly parses SystemResourceSize from NPDM, and makes information available via svcGetInfo. This is needed for games like Super Smash Bros. and Diablo 3 -- this PR's implementation does not run into the "ASCII reads" issue mentioned in the comments of #2626, which was caused by the following bugs in Yuzu's memory management that this PR also addresses: * Yuzu's memory coalescing does not properly merge blocks. This results in a polluted address space/svcQueryMemory results that would be impossible to replicate on hardware, which can lead to game code making the wrong assumptions about memory layout. * This implements better merging for AllocatedMemoryBlocks. * Yuzu's implementation of svcMirrorMemory unprotected the entire virtual memory range containing the range being mirrored. This could lead to games attempting to map data at that unprotected range/attempting to access that range after yuzu improperly unmapped it. * This PR fixes it by simply calling ReprotectRange instead of Reprotect.
* | core/arm: Remove obsolete Unicorn memory mappingLioncash2019-07-111-20/+0
|/ | | | | | | | This was initially necessary when AArch64 JIT emulation was in its infancy and all memory-related instructions weren't implemented. Given the JIT now has all of these facilities implemented, we can remove these functions from the CPU interface.
* kernel/vm_manager: Rename 'new map' to 'stack'Lioncash2019-07-061-17/+17
| | | | | | Provides a more accurate name for the memory region and also disambiguates between the map and new map regions of memory, making it easier to understand.
* kernel/vm_manager: Handle stack/TLS IO region placement betterLioncash2019-07-061-2/+13
| | | | | | | | | | | | | | | Handles the placement of the stack a little nicer compared to the previous code, which was off in a few ways. e.g. The stack (new map) region, shouldn't be the width of the entire address space if the size of the region calculation ends up being zero. It should be placed at the same location as the TLS IO region and also have the same size. In the event the TLS IO region contains a size of zero, we should also be doing the same thing. This fixes our memory layout a little bit and also resolves some cases where assertions can trigger due to the memory layout being incorrect.
* kernel/vm_manager: Add overload of FindFreeRegion() that operates on a boundaryLioncash2019-07-041-10/+21
| | | | | | | | | | This will be necessary for making our TLS slot management slightly more straightforward. This can also be utilized for other purposes in the future. We can implement the existing simpler overload in terms of this one anyways, we just pass the beginning and end of the ASLR region as the boundaries.
* kernel/vm_manager: Remove redundant Reset call in destructorLioncash2019-06-121-3/+1
| | | | | | | | | This is performing more work than would otherwise be necessary during VMManager's destruction. All we actually want to occur in this scenario is for any allocated memory to be freed, which will happen automatically as the VMManager instance goes out of scope. Anything else being done is simply unnecessary work.
* kernel/svc: Amend naming for TotalMemoryUsage in svcGetInfo()Lioncash2019-06-101-1/+1
| | | | | Disambiguates and makes the name a little more consistent with TotalPhysicalMemoryUsed.
* kernel/vm_manager: Remove usages of global system accessorsLioncash2019-04-171-5/+2
| | | | | Makes the dependency on the system instance explicit within VMManager's interface.
* kernel/svc: Implement svcUnmapProcessCodeMemoryLioncash2019-04-131-0/+51
| | | | | | | | | | | | Essentially performs the inverse of svcMapProcessCodeMemory. This unmaps the aliasing region first, then restores the general traits of the aliased memory. What this entails, is: - Restoring Read/Write permissions to the VMA. - Restoring its memory state to reflect it as a general heap memory region. - Clearing the memory attributes on the region.
* kernel/svc: Implement svcMapProcessCodeMemoryLioncash2019-04-131-0/+29
| | | | | This is utilized for mapping code modules into memory. Notably, the ldr service would call this in order to map objects into memory.
* kernel/vm_manager: Handle shrinking of the heap size within SetHeapSize()Lioncash2019-03-241-21/+13
| | | | | | | | | | | | | One behavior that we weren't handling properly in our heap allocation process was the ability for the heap to be shrunk down in size if a larger size was previously requested. This adds the basic behavior to do so and also gets rid of HeapFree, as it's no longer necessary now that we have allocations and deallocations going through the same API function. While we're at it, fully document the behavior that this function performs.
* kernel/vm_manager: Rename HeapAllocate to SetHeapSizeLioncash2019-03-241-1/+1
| | | | | | | | | Makes it more obvious that this function is intending to stand in for the actual supervisor call itself, and not acting as a general heap allocation function. Also the following change will merge the freeing behavior of HeapFree into this function, so leaving it as HeapAllocate would be misleading.
* kernel/vm_manager: Handle case of identical calls to HeapAllocateLioncash2019-03-241-0/+5
| | | | | | | | In cases where HeapAllocate is called with the same size of the current heap, we can simply do nothing and return successfully. This avoids doing work where we otherwise don't have to. This is also what the kernel itself does in this scenario.
* kernel/vm_manager: Remove unnecessary heap_used data memberLioncash2019-03-241-6/+1
| | | | | This isn't required anymore, as all the kernel ever queries is the size of the current heap, not the total usage of it.
* kernel/vm_manager: Tidy up heap allocation codeLioncash2019-03-241-20/+22
| | | | | | | | | | | | | | | | Another holdover from citra that can be tossed out is the notion of the heap needing to be allocated in different addresses. On the switch, the base address of the heap will always be managed by the memory allocator in the kernel, so this doesn't need to be specified in the function's interface itself. The heap on the switch is always allocated with read/write permissions, so we don't need to add specifying the memory permissions as part of the heap allocation itself either. This also corrects the error code returned from within the function. If the size of the heap is larger than the entire heap region, then the kernel will report an out of memory condition.
* kernel/vm_manager: Rename CodeStatic/CodeMutable to Code and CodeData respectivelyLioncash2019-03-211-10/+10
| | | | | | | Makes it more evident that one is for actual code and one is for actual data. Mutable and static are less than ideal terms here, because read-only data is technically not mutable, but we were mapping it with that label.
* core: Move PageTable struct into Common.bunnei2019-03-171-3/+3
|
* vm_manager: Use range helpers in HeapAlloc() and HeapFree()Lioncash2019-03-041-4/+2
| | | | Significantly tidies up two guard conditionals.
* vm_manager: Provide address range checking functions for other memory regionsLioncash2019-03-041-0/+19
| | | | | Makes the interface uniform when it comes to checking various memory regions.
* svc: Migrate address range checking functions to VMManagerLioncash2019-03-041-2/+20
| | | | Provides a bit of a more proper interface for these functions.
* kernel/vm_manager: Reset region attributes when unmapping a VMALioncash2018-12-271-0/+1
| | | | | Like the other members related to memory regions, the attributes need to be reset back to their defaults as well.
* vm_manager: Add member function for setting memory attributes across an address rangeLioncash2018-12-191-0/+28
| | | | | This puts the backing functionality for svcSetMemoryAttribute in place, which will be utilized in a following change.
* vm_manager: Add member function for checking a memory range adheres to certain attributes, permissions and statesLioncash2018-12-191-0/+60
|
* vm_manager: Rename meminfo_state to stateLioncash2018-12-161-8/+8
| | | | | This is shorter and more concise. This also removes the now-innaccurate comment, as it's not returned wholesale to svcQueryMemory anymore.
* vm_manager: Add backing functionality for memory attributesLioncash2018-12-161-1/+2
| | | | | | Adds the barebones enumeration constants and functions in place to handle memory attributes, while also essentially leaving the attribute itself non-functional.
* vm_manager: Amend the returned values for invalid memory queries in QueryMemory()Lioncash2018-12-121-4/+4
| | | | | | The kernel returns a memory info instance with the base address set to the end of the address space, and the size of said block as 0 - address_space_end, it doesn't set both of said members to zero.
* vm_manager: Migrate memory querying to the VMManager interfaceLioncash2018-12-121-0/+19
| | | | | Gets rid of the need to directly access the managed VMAs outside of the memory manager itself just for querying memory.
* vm_manager: Amend MemoryState enum membersLioncash2018-12-121-2/+2
| | | | | | | | Amends the MemoryState enum to use the same values like the actual kernel does. Also provides the necessary operators to operate on them. This will be necessary in the future for implementing svcSetMemoryAttribute, as memory block state is checked before applying the attribute.
* vm_manager: Make vma_map privateLioncash2018-12-061-0/+4
| | | | | | | | | | | This was only ever public so that code could check whether or not a handle was valid or not. Instead of exposing the object directly and allowing external code to potentially mess with the map contents, we just provide a member function that allows checking whether or not a handle is valid. This makes all member variables of the VMManager class private except for the page table.
* ldr_ro: Add error check for memory allocation failureZach Hilman2018-11-181-3/+3
|
* vm_manager: Unstub GetTotalHeapUsage()Lioncash2018-11-131-2/+1
| | | | | | Now that we've moved all of the heap-related stuff to the VMManager class, we can unstub this function, as the necessary members are visible now.
* kernel/process: Migrate heap-related memory management out of the process class and into the vm managerLioncash2018-11-131-0/+79
| | | | | Avoids a breach of responsibilities in the interface and keeps the direct code for memory management within the VMManager class.
* Kernel/Memory: Added a function to first a suitable guest address at which to allocate a region of a given size.bunnei2018-10-261-0/+20
|
* svc: Add missing sanitizing checks for MapSharedMemory/UnmapSharedMemoryLioncash2018-10-181-0/+20
| | | | | | | | Now that the changes clarifying the address spaces has been merged, we can wrap the checks that the kernel performs when mapping shared memory (and other forms of memory) into its own helper function and then use those within MapSharedMemory and UnmapSharedMemory to complete the sanitizing checks that are supposed to be done.
* svc: Clarify enum values for AddressSpaceBaseAddr and AddressSpaceSize in svcGetInfo()Lioncash2018-10-151-9/+26
| | | | | | | | | | | | | So, one thing that's puzzled me is why the kernel seemed to *not* use the direct code address ranges in some cases for some service functions. For example, in svcMapMemory, the full address space width is compared against for validity, but for svcMapSharedMemory, it compares against 0xFFE00000, 0xFF8000000, and 0x7FF8000000 as upper bounds, and uses either 0x200000 or 0x8000000 as the lower-bounds as the beginning of the compared range. Coincidentally, these exact same values are also used in svcGetInfo, and also when initializing the user address space, so this is actually retrieving the ASLR extents, not the extents of the address space in general.
* svc: Report correct memory-related values within some of the cases in svcGetInfo()Lioncash2018-09-251-5/+7
| | | | | | Previously, these were reporting hardcoded values, but given the regions can change depending on the requested address spaces, these need to report the values that the memory manager contains.
* memory: Dehardcode the use of a 36-bit address spaceLioncash2018-09-251-5/+13
| | | | | Given games can also request a 32-bit or 39-bit address space, we shouldn't be hardcoding the address space range as 36-bit.
* process/vm_manager: Amend API to allow reading parameters from NPDM metadataLioncash2018-09-241-8/+146
| | | | | | | | | Rather than hard-code the address range to be 36-bit, we can derive the parameters from supplied NPDM metadata if the supplied exectuable supports it. This is the bare minimum necessary for this to be possible. The following commits will rework the memory code further to adjust to this.
* Port #4182 from Citra: "Prefix all size_t with std::"fearlessTobi2018-09-151-1/+1
|
* kernel/vm_manager: Convert loop into std::any_of()Lioncash2018-08-021-4/+4
|
* kernel/vm_manager: Use const where applicableLioncash2018-08-021-14/+14
| | | | Makes our immutable state explicit.
* kernel/vm_manager: Use the VAddr type alias in CarveVMA()Lioncash2018-08-021-2/+2
| | | | These two variables correspond to address ranges.
* Merge pull request #690 from lioncash/movebunnei2018-07-191-2/+3
|\ | | | | core/memory, core/hle/kernel: Use std::move where applicable
| * core/memory, core/hle/kernel: Use std::move where applicableLioncash2018-07-191-2/+3
| | | | | | | | Avoids pointless copies
* | vm_manager: Add missing commas to string literal array elements in GetMemoryStateName()Lioncash2018-07-191-22/+12
|/ | | | | Without these, this would perform concatenation, which is definitely not what we want here.
* Update clang formatJames Rowe2018-07-031-5/+5
|
* Rename logging macro back to LOG_*James Rowe2018-07-031-5/+5
|
* core: Implement multicore support.bunnei2018-05-111-4/+19
|
* general: Make formatting of logged hex values more straightforwardLioncash2018-05-021-4/+4
| | | | | | This makes the formatting expectations more obvious (e.g. any zero padding specified is padding that's entirely dedicated to the value being printed, not any pretty-printing that also gets tacked on).
* core: Replace usages of LOG_GENERIC with new fmt-capable equivalentsLioncash2018-04-271-4/+2
|
* general: Convert assertion macros over to be fmt-compatibleLioncash2018-04-271-4/+4
|
* kernel: Migrate logging macros to fmt-compatible onesLioncash2018-04-261-4/+4
|
* vm_manager: Increase GetTotalMemoryUsage value.bunnei2018-04-151-1/+1
| | | | - Gets Binding of Isaac running.
* arm_interface: Support unmapping previously mapped memory.bunnei2018-03-161-0/+3
|
* svc: Use more correct values for GetInfo MapRegion and NewMapRegion.bunnei2018-03-161-15/+0
|
* MemoryState: Add additional memory states and improve naming.bunnei2018-03-161-3/+21
|
* vm_manager: Silence formatting specifier warningsLioncash2018-02-141-5/+7
|
* memory: Replace all memory hooking with Special regionsMerryMage2018-01-271-3/+3
|
* svc: Fix svcGetInfo MapRegionBaseAddr.bunnei2018-01-191-0/+5
|
* Merge pull request #52 from ogniK5377/fspbunnei2018-01-171-2/+2
|\ | | | | added more svcGetInfo pairs for 3.0.0+ support, Changed HEAP_SIZE and TLS_AREA_VADDR. changed mem usage & heap usage stub added, ISelfController, IApplication function stubs. Added SetThreadCoreMask
| * Added more svcGetInfo pairsDavid Marcec2018-01-161-2/+2
| |
* | clang-formatMerryMage2018-01-161-2/+3
|/
* vm_manager: Stub out a bunch of interfaces used by svcGetInfo.bunnei2018-01-011-1/+33
|
* Merge remote-tracking branch 'upstream/master' into nxbunnei2017-10-101-4/+15
|\ | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | # Conflicts: # src/core/CMakeLists.txt # src/core/arm/dynarmic/arm_dynarmic.cpp # src/core/arm/dyncom/arm_dyncom.cpp # src/core/hle/kernel/process.cpp # src/core/hle/kernel/thread.cpp # src/core/hle/kernel/thread.h # src/core/hle/kernel/vm_manager.cpp # src/core/loader/3dsx.cpp # src/core/loader/elf.cpp # src/core/loader/ncch.cpp # src/core/memory.cpp # src/core/memory.h # src/core/memory_setup.h
| * Kernel/Memory: Give each Process its own page table.Subv2017-09-101-4/+9
| | | | | | | | The loader is in charge of setting the newly created process's page table as the main one during the loading process.
* | core: Various changes to support 64-bit addressing.bunnei2017-09-301-11/+11
|/
* Kernel: Centralize error definitions in errors.hYuri Kunde Schlesner2017-05-251-0/+1
|
* Use negative priorities to avoid special-casing the self-includeYuri Kunde Schlesner2016-09-211-1/+1
|
* Remove empty newlines in #include blocks.Emmanuel Gil Peyrot2016-09-211-3/+1
| | | | | | | This makes clang-format useful on those. Also add a bunch of forgotten transitive includes, which otherwise prevented compilation.
* Sources: Run clang-format on everything.Emmanuel Gil Peyrot2016-09-181-16/+20
|
* Memory: Added necessary headers and removed unnecessary headerMerryMage2016-05-261-0/+1
|
* Memory: Implement MMIOMerryMage2016-01-301-3/+4
|
* Kernel: Properly implement ControlMemory FREE and COMMITYuri Kunde Schlesner2015-08-161-10/+81
|
* VMManager: Introduce names for used ResultCodesYuri Kunde Schlesner2015-08-161-6/+3
|
* VMManager: Make LogLayout log level configurable as a parameterYuri Kunde Schlesner2015-08-161-3/+13
|
* VMManager: Change block offsets to size_tYuri Kunde Schlesner2015-08-161-1/+1
|
* Core: Properly configure address space when loading a binaryYuri Kunde Schlesner2015-07-121-0/+14
| | | | | | The code now properly configures the process image to match the loaded binary segments (code, rodata, data) instead of just blindly allocating a large chunk of dummy memory.
* Core: Cleanup core includes.Emmanuel Gil Peyrot2015-06-281-0/+2
|
* Kernel: Add VMManager to manage process address spacesYuri Kunde Schlesner2015-05-271-0/+245
This enables more dynamic management of the process address space, compared to just directly configuring the page table for major areas. This will serve as the foundation upon which the rest of the Kernel memory management functions will be built.
generated by cgit v1.2.3 (git 2.25.1) at 2024-07-19 22:01:37 +0200