aboutsummaryrefslogtreecommitdiff
path: root/src/core/hle/kernel
AgeCommit message (Collapse)Author
2019-05-24Merge pull request #2489 from FearlessTobi/port-4716bunnei
Port citra-emu/citra#4716: "HLE/IPC: HLEContext can memorize the client thread and use it for SleepClientThread"
2019-05-19Merge pull request #2410 from lioncash/affinitybunnei
kernel/svc: Reorganize and fix up the initial handling of svcSetThreadCoreMask()
2019-05-19Merge pull request #2486 from lioncash/resetnameSebastian Valle
core/kernel/object: Rename ResetType enum members for clarity
2019-05-19Address review commentTobias
Co-Authored-By: Mat M. <mathew1800@gmail.com>
2019-05-18kernel/svc: Mark GetThreadList() and UnmapProcessCodeMemory() as internally ↵Lioncash
linked These are only used from within this translation unit, so they don't need to have external linkage. They were intended to be marked with this anyways to be consistent with the other service functions.
2019-05-18core/kernel/object: Rename ResetType enum membersLioncash
Renames the members to more accurately indicate what they signify. "OneShot" and "Sticky" are kind of ambiguous identifiers for the reset types, and can be kind of misleading. Automatic and Manual communicate the kind of reset type in a clearer manner. Either the event is automatically reset, or it isn't and must be manually cleared. The "OneShot" and "Sticky" terminology is just a hold-over from Citra where the kernel had a third type of event reset type known as "Pulse". Given the Switch kernel only has two forms of event reset types, we don't need to keep the old terminology around anymore.
2019-05-18HLE/IPC: HLEContext can memorize the client thread and use it for ↵Weiyi Wang
SleepClientThread This reduces the boilerplate that services have to write out the current thread explicitly. Using current thread instead of client thread is also semantically incorrect, and will be a problem when we implement multicore (at which time there will be multiple current threads)
2019-04-29kernel/svc: Make svcCreateThread/svcStartThread/svcSleepThread/svcExitThread ↵Lioncash
calls show up in the debug log These are actually quite important indicators of thread lifetimes, so they should be going into the debug log, rather than being treated as misc info and delegated to the trace log.
2019-04-29kernel/svc: Reorganize svcSetThreadCoreMask()Lioncash
Makes the code much nicer to follow in terms of behavior and control flow. It also fixes a few bugs in the implementation. Notably, the thread's owner process shouldn't be accessed in order to retrieve the core mask or ideal core. This should be done through the current running process. The only reason this bug wasn't encountered yet is because we currently only support running one process, and thus every owner process will be the current process. We also weren't checking against the process' CPU core mask to see if an allowed core is specified or not. With this out of the way, it'll be less noisy to implement proper handling of the affinity flags internally within the kernel thread instances.
2019-04-29kernel/thread: Update thread processor ID flagsLioncash
Adds the missing flags to the enum and documents them.
2019-04-28Merge pull request #2412 from lioncash/systembunnei
kernel/vm_manager: Remove usages of global system accessors
2019-04-24Merge pull request #2416 from lioncash/waitbunnei
kernel/svc: Clean up wait synchronization related functionality
2019-04-19Merge pull request #2415 from lioncash/constbunnei
kernel/wait_object: Make GetHighestPriorityReadyThread() a const member function
2019-04-19Merge pull request #2421 from lioncash/svc-callbunnei
kernel/svc: Name supervisor call 0x36
2019-04-19Merge pull request #2374 from lioncash/pagetablebunnei
core: Reorganize boot order
2019-04-19kernel/svc: Name supervisor call 0x36Lioncash
This call was added to the SVC handlers in the 8.0.0 kernel, so we can finally give it a name.
2019-04-17Merge pull request #2397 from lioncash/thread-unusedbunnei
kernel/thread: Remove unused guest_handle member variable
2019-04-17kernel/thread: Unify wait synchronization typesLioncash
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-17kernel/svc: Migrate svcCancelSynchronization behavior to a thread functionLioncash
The actual behavior of this function is slightly more complex than what we're currently doing within the supervisor call. To avoid dumping most of this behavior in the supervisor call itself, we can migrate this to another function.
2019-04-17kernel/wait_object: Make GetHighestPriorityReadyThread() a const member functionLioncash
This doesn't actually modify internal state of a wait object, so it can be const qualified.
2019-04-16kernel/vm_manager: Remove usages of global system accessorsLioncash
Makes the dependency on the system instance explicit within VMManager's interface.
2019-04-15Merge pull request #2393 from lioncash/svcbunnei
kernel/svc: Implement svcMapProcessCodeMemory/svcUnmapProcessCodeMemory
2019-04-15svc: Specify handle value in thread's nameLioncash
Allows the handle to be seen alongside the entry point.
2019-04-15kernel/thread: Remove BoostPriority()Lioncash
This is a holdover from Citra that currently remains unused, so it can be removed from the Thread interface.
2019-04-14kernel/thread: Remove unused guest_handle member variableLioncash
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-12kernel/svc: Implement svcUnmapProcessCodeMemoryLioncash
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.
2019-04-12kernel/svc: Implement svcMapProcessCodeMemoryLioncash
This is utilized for mapping code modules into memory. Notably, the ldr service would call this in order to map objects into memory.
2019-04-11core/core: Move process execution start to System's Load()Lioncash
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-11core/process: Remove unideal page table setting from LoadFromMetadata()Lioncash
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-11core/cpu_core_manager: Create threads separately from initialization.Lioncash
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-11Merge pull request #2360 from lioncash/svc-globalbunnei
kernel/svc: Deglobalize the supervisor call handlers
2019-04-11Merge pull request #2388 from lioncash/constexprbunnei
kernel: Make handle type declarations constexpr
2019-04-11kernel: Make handle type declarations constexprLioncash
Some objects declare their handle type as const, while others declare it as constexpr. This makes the const ones constexpr for consistency, and prevent unexpected compilation errors if these happen to be attempted to be used within a constexpr context.
2019-04-09kernel/server_session: Remove obsolete TODOsLioncash
These are holdovers from Citra.
2019-04-09kernel/process: Set page table when page table resizes occur.Lioncash
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-07kernel/svc: Deglobalize the supervisor call handlersLioncash
Adjusts the interface of the wrappers to take a system reference, which allows accessing a system instance without using the global accessors. This also allows getting rid of all global accessors within the supervisor call handling code. While this does make the wrappers themselves slightly more noisy, this will be further cleaned up in a follow-up. This eliminates the global system accessors in the current code while preserving the existing interface.
2019-04-07Merge pull request #2361 from lioncash/pagetablebunnei
core/memory: Minor simplifications to page table management
2019-04-07kernel: Handle page table switching within MakeCurrentProcess()Lioncash
Centralizes the page table switching to one spot, rather than making calling code deal with it everywhere.
2019-04-06kernel/server_session: Return a std::pair from CreateSessionPair()Lioncash
Keeps the return type consistent with the function name. While we're at it, we can also reduce the amount of boilerplate involved with handling these by using structured bindings.
2019-04-06kernel/server_port: Return a std::pair from CreatePortPair()Lioncash
Returns the same type that the function name describes.
2019-04-05Merge pull request #2325 from lioncash/namebunnei
kernel/server_session: Provide a GetName() override
2019-04-05Merge pull request #2329 from lioncash/sanitizebunnei
kernel/svc: Properly sanitize mutex address in WaitProcessWideKeyAtomic
2019-04-03Merge pull request #2328 from lioncash/transferbunnei
service/am: Correct behavior of CreateTransferMemoryStorage()
2019-04-03Merge pull request #2324 from lioncash/enum-unusedbunnei
kernel/object: Remove unused handle type entry
2019-04-03kernel/svc: Properly sanitize mutex address in WaitProcessWideKeyAtomicLioncash
We need to be checking whether or not the given address is within the kernel address space or if the given address isn't word-aligned and bail in these scenarios instead of trashing any kernel state.
2019-04-03kernel/transfer_memory: Add accessors to data and sizesLioncash
Also amend erroneous use of size_t. We should be using u64 here.
2019-04-03Merge pull request #2305 from lioncash/sharedbunnei
kernel/shared_memory: Sanitize supplied size when unmapping
2019-04-03Merge pull request #2314 from lioncash/constbunnei
kernel/thread: Minor interface cleanup
2019-04-03kernel/server_session: Provide a GetName() overrideLioncash
Given server sessions can be given a name, we should allow retrieving it instead of using the default implementation of GetName(), which would just return "[UNKNOWN KERNEL OBJECT]".
2019-04-03kernel/object: Remove unused handle type entryLioncash
The AddressArbiter type isn't actually used, given the arbiter itself isn't a direct kernel object (or object that implements the wait object facilities). Given this, we can remove the enum entry entirely.