Commit graph

10 commits

Author SHA1 Message Date
Fernando Sahmkow e4a1ead897 Core: Refactor CpuCoreManager to CpuManager and Cpu to Core Manager.
This commit instends on better naming the new purpose of this classes.
2020-01-26 14:07:22 -04:00
Fernando Sahmkow 4d6a86b03f Core: Refactor CPU Management.
This commit moves ARM Interface and Scheduler handling into the kernel.
2020-01-25 18:55:32 -04:00
Lioncash e4c381b885 core/memory: Migrate over Write{8, 16, 32, 64, Block} to the Memory class
The Write functions are used slightly less than the Read functions,
which make these a bit nicer to move over.

The only adjustments we really need to make here are to Dynarmic's
exclusive monitor instance. We need to keep a reference to the currently
active memory instance to perform exclusive read/write operations.
2019-11-26 21:55:39 -05:00
Fernando Sahmkow 25f8606a6d Kernel Scheduler: Make sure the global scheduler shutdowns correctly. 2019-10-15 11:55:24 -04:00
Fernando Sahmkow e0650a2034 Core_Timing: Address Feedback and suppress warnings. 2019-10-11 14:44:14 -04:00
Fernando Sahmkow 555866f8dc Core Timing: Rework Core Timing to run all cores evenly. 2019-10-09 12:30:31 -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 fad20213e6 kernel/scheduler: Pass in system instance in constructor
Avoids directly relying on the global system instance and instead makes
an arbitrary system instance an explicit dependency on construction.

This also allows removing dependencies on some global accessor functions
as well.
2019-03-04 17:01:37 -05:00
Lioncash bd983414f6 core_timing: Convert core timing into a class
Gets rid of the largest set of mutable global state within the core.
This also paves a way for eliminating usages of GetInstance() on the
System class as a follow-up.

Note that no behavioral changes have been made, and this simply extracts
the functionality into a class. This also has the benefit of making
dependencies on the core timing functionality explicit within the
relevant interfaces.
2019-02-15 21:50:25 -05:00
Lioncash 232d95b56e core: Relocate CPU core management to its own class
Keeps the CPU-specific behavior from being spread throughout the main
System class. This will also act as the home to contain member functions
that perform operations on all cores. The reason for this being that the
following pattern is sort of prevalent throughout sections of the
codebase:

If clearing the instruction cache for all 4 cores is necessary:

Core::System::GetInstance().ArmInterface(0).ClearInstructionCache();
Core::System::GetInstance().ArmInterface(1).ClearInstructionCache();
Core::System::GetInstance().ArmInterface(2).ClearInstructionCache();
Core::System::GetInstance().ArmInterface(3).ClearInstructionCache();

This is kind of... well, silly to copy around whenever it's needed.
especially when it can be reduced down to a single line.

This change also puts the basics in place to begin "ungrafting" all of the
forwarding member functions from the System class that are used to
access CPU state or invoke CPU-specific behavior. As such, this change
itself makes no changes to the direct external interface of System. This
will be covered by another changeset.
2018-11-22 04:28:19 -05:00