| Commit message (Collapse) | Author | Age | Files | Lines |
|
|
|
|
|
|
|
|
| |
Currently, the main memory management code is one of the remaining
places where we have global state. The next series of changes will aim
to rectify this.
This change simply introduces the main skeleton of the class that will
contain all the necessary state.
|
|
|
|
| |
This isn't used by anything in the header file, so it can be removed.
|
|
|
|
|
| |
Recent changes to memory-related code resulted in this being unused, so
we can remove it.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Our initialization process is a little wonky than one would expect when
it comes to code flow. We initialize the CPU last, as opposed to
hardware, where the CPU obviously needs to be first, otherwise nothing
else would work, and we have code that adds checks to get around this.
For example, in the page table setting code, we check to see if the
system is turned on before we even notify the CPU instances of a page
table switch. This results in dead code (at the moment), because the
only time a page table switch will occur is when the system is *not*
running, preventing the emulated CPU instances from being notified of a
page table switch in a convenient manner (technically the code path
could be taken, but we don't emulate the process creation svc handlers
yet).
This moves the threads creation into its own member function of the core
manager and restores a little order (and predictability) to our
initialization process.
Previously, in the multi-threaded cases, we'd kick off several threads
before even the main kernel process was created and ready to execute (gross!).
Now the initialization process is like so:
Initialization:
1. Timers
2. CPU
3. Kernel
4. Filesystem stuff (kind of gross, but can be amended trivially)
5. Applet stuff (ditto in terms of being kind of gross)
6. Main process (will be moved into the loading step in a following
change)
7. Telemetry (this should be initialized last in the future).
8. Services (4 and 5 should ideally be alongside this).
9. GDB (gross. Uses namespace scope state. Needs to be refactored into a
class or booted altogether).
10. Renderer
11. GPU (will also have its threads created in a separate step in a
following change).
Which... isn't *ideal* per-se, however getting rid of the wonky
intertwining of CPU state initialization out of this mix gets rid of
most of the footguns when it comes to our initialization process.
|
|\
| |
| | |
core/memory: Minor simplifications to page table management
|
| |
| |
| |
| |
| | |
Now that nothing actually touches the internal page table aside from the
memory subsystem itself, we can remove the accessor to it.
|
|/
|
|
| |
These are holdovers from Citra and can be removed.
|
|
|
|
|
|
|
| |
In 93da8e0abfcdcc6e3cb5488a0db12373429f1377, the page table construct
was moved to the common library (which utilized these inclusions). Since
the move, nothing requires these headers to be included within the
memory header.
|
| |
|
| |
|
|
|
|
|
|
|
|
| |
The locations of these can actually vary depending on the address space
layout, so we shouldn't be using these when determining where to map
memory or be using them as offsets for calculations. This keeps all the
memory ranges flexible and malleable based off of the virtual memory
manager instance state.
|
|
|
|
|
| |
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.
|
| |
|
| |
|
|
|
|
| |
Keeps the code consistent.
|
|
|
|
|
| |
Previously, the prototype wasn't matching the definition, which has a
Processor parameter before the destination address.
|
|
|
|
|
| |
These aren't necessary, as value-wise const only matters in the
definition.
|
|
|
|
| |
Removes leftover code from citra that isn't needed.
|
| |
|
| |
|
| |
|
| |
|
|\
| |
| | |
Tegra progress 2
|
| | |
|
| | |
|
|/ |
|
| |
|
| |
|
| |
|
| |
|
| |
|
| |
|
| |
|
| |
|
|\
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
# 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
|
| | |
|
| | |
|
| |
| |
| |
| | |
There is still an overload of IsValidVirtualAddress that only takes the VAddr and will default to the current process.
|
| | |
|
| |
| |
| |
| | |
Don't expose Memory::current_page_table as a global.
|
| | |
|
| |
| |
| |
| | |
The loader is in charge of setting the newly created process's page table as the main one during the loading process.
|
| | |
|
|/ |
|
|
|
|
|
|
| |
This is slightly more ergonomic to use, correctly handles virtual
regions which are disjoint in physical addressing space, and checks only
regions which can be cached by the rasterizer.
|
| |
|
|
|
|
| |
And fix a few places in the code to take advantage of that.
|
| |
|
|
|
|
| |
This is 4MB of extra, separate memory that was added on the New 3DS.
|
| |
|
|
|
|
|
|
|
| |
This makes clang-format useful on those.
Also add a bunch of forgotten transitive includes, which otherwise
prevented compilation.
|
| |
|
| |
|
| |
|
| |
|
| |
|
| |
|
| |
|
|\
| |
| | |
Kernel/Threads: Dynamically allocate the TLS region for threads.
|
| |
| |
| |
| |
| |
| | |
Each thread gets a 0x200-byte area from the 0x1000-sized page, when all 8 thread slots in a single page are used up, the kernel allocates a new page to hold another 8 entries.
This is consistent with what the real kernel does.
|
|/ |
|
| |
|
|
|
|
|
| |
This also adds some basic memory usage accounting. These two types are
used by Super Smash Bros. during startup.
|
|
|
|
|
|
| |
This adds some structures necessary to support multiple memory regions
in the future. It also adds support for different system memory types
and the new linear heap mapping at 0x30000000.
|
|
|
|
|
| |
These helpers aren't really part of the kernel, and mem_map.cpp/h is
going to be moved there next.
|
| |
|
| |
|
| |
|
| |
|
|
memory.cpp/h contains definitions related to acessing memory and
configuring the address space
mem_map.cpp/h contains higher-level definitions related to configuring
the address space accoording to the kernel and allocating memory.
|