| Commit message (Collapse) | Author | Age | Files | Lines |
| |
|
| |
|
|
|
|
| |
This allows us to create a fastmem arena within the memory.cpp helpers.
|
| |
|
|
|
|
|
|
| |
Migrates all of the direct mapping facilities over to the new memory
class. In the process, this also obsoletes the need for memory_setup.h,
so we can remove it entirely from the project.
|
|
|
|
|
|
|
|
|
| |
Uncovered a bug within Thread's SetCoreAndAffinityMask() where an
unsigned variable (ideal_core) was being compared against "< 0", which
would always be a false condition.
We can also get rid of an unused function (GetNextProcessorId) which contained a sign
mismatch warning.
|
|
|
|
| |
Narrows the scope of variables down to where they're only necessary.
|
|
|
|
|
|
| |
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.
|
|
|
|
|
|
|
| |
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.
|
|
|
|
| |
Avoids an unnecessary atomic reference count increment and decrement.
|
|
|
|
|
|
| |
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.
|
|
|
|
| |
Same behavior, one less magic constant to read.
|
|
|
|
|
| |
Assertions already log out the function name, so there's no need to
manually include the function name in the assertion strings.
|
|
|
|
|
|
| |
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.
|
|\
| |
| | |
Implement MapPhysicalMemory/UnmapPhysicalMemory
|
| | |
|
| |
| |
| |
| |
| |
| |
| | |
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.
|
| | |
|
| | |
|
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
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.
|
|/
|
|
|
|
|
|
| |
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.
|
|
|
|
|
|
| |
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.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
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.
|
|
|
|
|
|
|
|
|
|
| |
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.
|
|
|
|
|
|
|
|
|
| |
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.
|
|
|
|
|
| |
Disambiguates and makes the name a little more consistent with
TotalPhysicalMemoryUsed.
|
|
|
|
|
| |
Makes the dependency on the system instance explicit within VMManager's
interface.
|
|
|
|
|
|
|
|
|
|
|
|
| |
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.
|
|
|
|
|
| |
This is utilized for mapping code modules into memory. Notably, the
ldr service would call this in order to map objects into memory.
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
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.
|
|
|
|
|
|
|
|
|
| |
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.
|
|
|
|
|
|
|
|
| |
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.
|
|
|
|
|
| |
This isn't required anymore, as all the kernel ever queries is the size
of the current heap, not the total usage of it.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
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.
|
|
|
|
|
|
|
| |
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.
|
| |
|
|
|
|
| |
Significantly tidies up two guard conditionals.
|
|
|
|
|
| |
Makes the interface uniform when it comes to checking various memory
regions.
|
|
|
|
| |
Provides a bit of a more proper interface for these functions.
|
|
|
|
|
| |
Like the other members related to memory regions, the attributes need to
be reset back to their defaults as well.
|
|
|
|
|
| |
This puts the backing functionality for svcSetMemoryAttribute in place,
which will be utilized in a following change.
|
| |
|
|
|
|
|
| |
This is shorter and more concise. This also removes the now-innaccurate
comment, as it's not returned wholesale to svcQueryMemory anymore.
|
|
|
|
|
|
| |
Adds the barebones enumeration constants and functions in place to
handle memory attributes, while also essentially leaving the attribute
itself non-functional.
|
|
|
|
|
|
| |
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.
|
|
|
|
|
| |
Gets rid of the need to directly access the managed VMAs outside of the
memory manager itself just for querying memory.
|
|
|
|
|
|
|
|
| |
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.
|
|
|
|
|
|
|
|
|
|
|
| |
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.
|
| |
|
|
|
|
|
|
| |
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.
|
|
|
|
|
| |
Avoids a breach of responsibilities in the interface and keeps the
direct code for memory management within the VMManager class.
|
| |
|
|
|
|
|
|
|
|
| |
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.
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
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.
|
|
|
|
|
|
| |
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.
|
|
|
|
|
| |
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.
|
|
|
|
|
|
|
|
|
| |
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.
|
| |
|
| |
|
|
|
|
| |
Makes our immutable state explicit.
|
|
|
|
| |
These two variables correspond to address ranges.
|
|\
| |
| | |
core/memory, core/hle/kernel: Use std::move where applicable
|
| |
| |
| |
| | |
Avoids pointless copies
|
|/
|
|
|
| |
Without these, this would perform concatenation, which is definitely not
what we want here.
|
| |
|
| |
|
| |
|
|
|
|
|
|
| |
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).
|
| |
|
| |
|
| |
|
|
|
|
| |
- Gets Binding of Isaac running.
|
| |
|
| |
|
| |
|
| |
|
| |
|
| |
|
|\
| |
| | |
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
|
| | |
|
|/ |
|
| |
|
|\
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
# 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
|
| |
| |
| |
| | |
The loader is in charge of setting the newly created process's page table as the main one during the loading process.
|
|/ |
|
| |
|
| |
|
|
|
|
|
|
|
| |
This makes clang-format useful on those.
Also add a bunch of forgotten transitive includes, which otherwise
prevented compilation.
|
| |
|
| |
|
| |
|
| |
|
| |
|
| |
|
| |
|
|
|
|
|
|
| |
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.
|
| |
|
|
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.
|