Commit graph

133 commits

Author SHA1 Message Date
Fernando Sahmkow
46bb609981 Kernel: Optimize condition variable threads management. 2019-11-21 11:13:29 -04:00
Fernando Sahmkow
2d16507f9f Kernel: Correct behavior of Condition Variables to be more similar to real hardware.
This commit ensures cond var threads act exactly as they do in the real
console. The original implementation uses an RBTree and the behavior of
cond var threads is that at the same priority level they act like a
FIFO.
2019-11-21 10:46:55 -04:00
Fernando Sahmkow
b8b7ebcece Correct compiling errors and addapt to the new interface. 2019-10-15 11:55:09 -04:00
Fernando Sahmkow
9bede4eeed VM_Manager: Align allocated memory to 256bytes
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.
2019-07-19 10:06:08 -04:00
bunnei
5d369112d9
Merge pull request #2687 from lioncash/tls-process
kernel/process: Allocate the process' TLS region during initialization
2019-07-18 13:53:04 -04:00
Michael Scire
b901cd584e clang-format fixes 2019-07-07 12:08:29 -07:00
Michael Scire
1689784c19 address review commentary 2019-07-07 11:48:11 -07:00
Michael Scire
13a8fde3ad Implement MapPhysicalMemory/UnmapPhysicalMemory
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.
2019-07-07 11:45:53 -07:00
Lioncash
56c7912159 kernel/process: Allocate the process' TLS region during initialization
Prior to execution within a process beginning, the process establishes
its own TLS region for uses (as far as I can tell) related to exception
handling.

Now that TLS creation was decoupled from threads themselves, we can add
this behavior to our Process class. This is also good, as it allows us
to remove a stub within svcGetInfo, namely querying the address of that
region.
2019-07-07 14:08:28 -04:00
Lioncash
eb6f55d880 kernel/process: Move main thread stack allocation to its own function
Keeps this particular set of behavior isolated to its own function.
2019-07-07 14:08:25 -04:00
Lioncash
abdce723eb kernel/process: Decouple TLS handling from threads
Extracts out all of the thread local storage management from thread
instances themselves and makes the owning process handle the management
of the memory. This brings the memory management slightly more in line
with how the kernel handles these allocations.

Furthermore, this also makes the TLS page management a little more
readable compared to the lingering implementation that was carried over
from Citra.
2019-07-03 20:31:40 -04:00
Zach Hilman
fc0bf91a96 kernel: Differentiate kernel and user processes when picking ID
This allows kernel internal type processes to be assigned IDs in the KIP range while userland processes are assigned in the user range.
2019-06-10 00:28:33 -04:00
Zach Hilman
364932df3a
Merge pull request #2571 from lioncash/ref
kernel/process: Make Create()'s name parameter be taken by value
2019-06-09 20:43:57 -04:00
Lioncash
fea6568955 kernel/process: Make Create()'s name parameter be taken by value
Makes the interface more flexible in terms of how Create() may be
called, while still allowing the parameter itself to be moved into.
2019-06-09 18:47:37 -04:00
Lioncash
3f87664d8f kernel/svc: Implement TotalMemoryUsedWithoutMmHeap/TotalMemoryAvailableWithoutMmHeap
Given we don't currently implement the personal heap yet, the existing
memory querying functions are essentially doing what the memory querying
types introduced in 6.0.0 do.

So, we can build the necessary machinery over the top of those and just
use them as part of info types.
2019-06-09 18:22:30 -04:00
bunnei
2be32eb3d2
Merge pull request #2412 from lioncash/system
kernel/vm_manager: Remove usages of global system accessors
2019-04-28 22:27:14 -04:00
bunnei
78574e7a47
Merge pull request #2416 from lioncash/wait
kernel/svc: Clean up wait synchronization related functionality
2019-04-24 22:56:08 -04:00
bunnei
40dc893c37
Merge pull request #2374 from lioncash/pagetable
core: Reorganize boot order
2019-04-19 19:09:20 -04:00
Lioncash
c268ffd831 kernel/thread: Unify wait synchronization types
This is a holdover from Citra, where the 3DS has both
WaitSynchronization1 and WaitSynchronizationN. The switch only has one
form of wait synchronizing (literally WaitSynchonization). This allows
us to throw out code that doesn't apply at all to the Switch kernel.

Because of this unnecessary dichotomy within the wait synchronization
utilities, we were also neglecting to properly handle waiting on
multiple objects.

While we're at it, we can also scrub out any lingering references to
WaitSynchronization1/WaitSynchronizationN in comments, and change them
to WaitSynchronization (or remove them if the mention no longer
applies).
2019-04-17 09:30:56 -04:00
Lioncash
b6a87b422e kernel/vm_manager: Remove usages of global system accessors
Makes the dependency on the system instance explicit within VMManager's
interface.
2019-04-16 20:02:50 -04:00
Lioncash
09caf8a756 kernel/thread: Remove unused guest_handle member variable
This member variable is entirely unused. It was only set but never
actually utilized. Given that, we can remove it to get rid of noise in
the thread interface.
2019-04-14 06:06:06 -04:00
Lioncash
612e1388df core/core: Move process execution start to System's Load()
This gives us significantly more control over where in the
initialization process we start execution of the main process.

Previously we were running the main process before the CPU or GPU
threads were initialized (not good). This amends execution to start
after all of our threads are properly set up.
2019-04-11 22:11:41 -04:00
Lioncash
32a6ceb4e5 core/process: Remove unideal page table setting from LoadFromMetadata()
Initially required due to the split codepath with how the initial main
process instance was initialized. We used to initialize the process
like:

Init() {
    main_process = Process::Create(...);
    kernel.MakeCurrentProcess(main_process.get());
}

Load() {
    const auto load_result = loader.Load(*kernel.GetCurrentProcess());
    if (load_result != Loader::ResultStatus::Success) {
        // Handle error here.
    }
    ...
}

which presented a problem.

Setting a created process as the main process would set the page table
for that process as the main page table. This is fine... until we get to
the part that the page table can have its size changed in the Load()
function via NPDM metadata, which can dictate either a 32-bit, 36-bit,
or 39-bit usable address space.

Now that we have full control over the process' creation in load, we can
simply set the initial process as the main process after all the loading
is done, reflecting the potential page table changes without any
special-casing behavior.

We can also remove the cache flushing within LoadModule(), as execution
wouldn't have even begun yet during all usages of this function, now
that we have the initialization order cleaned up.
2019-04-11 22:11:41 -04:00
Lioncash
f2331a804a core/cpu_core_manager: Create threads separately from initialization.
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.
2019-04-11 22:11:40 -04:00
Lioncash
2abf979c35 kernel/process: Set page table when page table resizes occur.
We need to ensure dynarmic gets a valid pointer if the page table is
resized (the relevant pointers would be invalidated in this scenario).

In this scenario, the page table can be resized depending on what kind
of address space is specified within the NPDM metadata (if it's
present).
2019-04-09 13:00:56 -04:00
Lioncash
e779686a76 kernel: Handle page table switching within MakeCurrentProcess()
Centralizes the page table switching to one spot, rather than making
calling code deal with it everywhere.
2019-04-07 01:12:54 -04:00
bunnei
74a4a50470
Merge pull request #2314 from lioncash/const
kernel/thread: Minor interface cleanup
2019-04-03 11:46:17 -04:00
Lioncash
28719ee3b4 kernel/svc: Implement svcGetThreadList
Similarly like svcGetProcessList, this retrieves the list of threads
from the current process. In the kernel itself, a process instance
maintains a list of threads, which are used within this function.

Threads are registered to a process' thread list at thread
initialization, and unregistered from the list upon thread destruction
(if said thread has a non-null owning process).

We assert on the debug event case, as we currently don't implement
kernel debug objects.
2019-04-02 00:48:40 -04:00
ReinUsesLisp
592a24ae53 process: Fix up compilation 2019-04-02 01:44:32 -03:00
bunnei
29df6bbbd3
Merge pull request #2281 from lioncash/memory
kernel/codeset: Make CodeSet's memory data member a regular std::vector
2019-04-01 22:20:05 -04:00
Lioncash
20cc0b8d3c kernel/wait_object: Make ShouldWait() take thread members by pointer-to-const
Given this is intended as a querying function, it doesn't make sense to
allow the implementer to modify the state of the given thread.
2019-04-01 18:19:45 -04:00
Lioncash
3a846aa80f kernel/process: Report total physical memory used to svcGetInfo
Reports the (mostly) correct size through svcGetInfo now for queries to
total used physical memory. This still doesn't correctly handle memory
allocated via svcMapPhysicalMemory, however, we don't currently handle
that case anyways.
2019-03-28 22:59:20 -04:00
Lioncash
2289e895aa kernel/process: Store the total size of the code memory loaded
This will be necessary to properly report the used memory size in
svcGetInfo.
2019-03-28 22:51:17 -04:00
Lioncash
5d4ab5ec2f kernel/process: Store the main thread stack size to a data member
This will be necessary in order to properly report memory usage within
svcGetInfo.
2019-03-28 18:45:06 -04:00
Lioncash
427f1e3e3d kernel/process: Make Run's stack size parameter a u64
This will make operating with the process-related SVC commands much
nicer in the future (the parameter representing the stack size in
svcStartProcess is a 64-bit value).
2019-03-28 18:26:12 -04:00
Lioncash
2aca7b9e1e kernel/process: Ensure that given stack size is always page-aligned
The kernel always makes sure that the given stack size is aligned to
page boundaries.
2019-03-28 18:25:00 -04:00
Lioncash
c0a01f3adc kernel/codeset: Make CodeSet's memory data member a regular std::vector
The use of a shared_ptr is an implementation detail of the VMManager
itself when mapping memory. Because of that, we shouldn't require all
users of the CodeSet to have to allocate the shared_ptr ahead of time.
It's intended that CodeSet simply pass in the required direct data, and
that the memory manager takes care of it from that point on.

This means we just do the shared pointer allocation in a single place,
when loading modules, as opposed to in each loader.
2019-03-22 18:43:46 -04:00
bunnei
7b6d516faa
Merge pull request #2234 from lioncash/mutex
core/hle/kernel: Make Mutex a per-process class.
2019-03-21 22:18:36 -04:00
Lioncash
18918f5f2f kernel/vm_manager: Rename CodeStatic/CodeMutable to Code and CodeData respectively
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.
2019-03-21 11:43:35 -04:00
Lioncash
8f454a5c68 kernel/process: Make MapSegment lambda reference parameter const
The segment itself isn't actually modified.
2019-03-20 13:07:09 -04:00
Lioncash
1b6bd9d6df kernel: Move CodeSet structure to its own source files
Given this is utilized by the loaders, this allows avoiding inclusion of
the kernel process definitions where avoidable.

This also keeps the loading format for all executable data separate from
the kernel objects.
2019-03-20 13:07:04 -04:00
bunnei
93da8e0abf core: Move PageTable struct into Common. 2019-03-16 22:05:40 -04:00
Lioncash
555cd26ec2 core/hle/kernel: Make Mutex a per-process class.
Makes it an instantiable class like it is in the actual kernel. This
will also allow removing reliance on global accessors in a following
change, now that we can encapsulate a reference to the system instance
in the class.
2019-03-14 20:55:52 -04:00
Lioncash
6eddb60db0 kernel/process: Remove use of global system accessors
Now that we pass in a reference to the system instance, we can utilize
it to eliminate the global accessors in Process-related code.
2019-03-12 19:03:28 -04:00
Lioncash
8e510d5afa kernel: Make the address arbiter instance per-process
Now that we have the address arbiter extracted to its own class, we can
fix an innaccuracy with the kernel. Said inaccuracy being that there
isn't only one address arbiter. Each process instance contains its own
AddressArbiter instance in the actual kernel.

This fixes that and gets rid of another long-standing issue that could
arise when attempting to create more than one process.
2019-03-07 23:27:51 -05:00
Lioncash
5167d1577d kernel/handle_table: Allow process capabilities to limit the handle table size
The kernel allows restricting the total size of the handle table through
the process capability descriptors. Until now, this functionality wasn't
hooked up. With this, the process handle tables become properly restricted.

In the case of metadata-less executables, the handle table will assume
the maximum size is requested, preserving the behavior that existed
before these changes.
2019-02-25 11:12:32 -05:00
Sebastian Valle
e5dfbe22ee
Merge pull request #1956 from lioncash/process-thread
kernel/process: Start the main thread using the specified ideal core
2018-12-30 20:32:41 -05:00
Lioncash
a81ff6f54c kernel/process: Start the main thread using the specified ideal core
This matches kernel behavior in that processes are started using their
specified ideal core, rather than always starting on core 0.
2018-12-27 21:50:16 -05:00
Lioncash
f80bc712ea kernel: Rename 'default' CPU core to 'ideal' core
This makes the naming more closely match its meaning. It's just a
preferred core, not a required default core. This also makes the usages
of this term consistent across the thread and process implementations.
2018-12-27 21:48:49 -05:00
Lioncash
771431f625 kernel/thread: Move process thread initialization into process.cpp
This function isn't a general purpose function that should be exposed to
everything, given it's specific to initializing the main thread for a
Process instance.

Given that, it's a tad bit more sensible to place this within
process.cpp, which keeps it visible only to the code that actually needs
it.
2018-12-27 20:32:30 -05:00