aboutsummaryrefslogtreecommitdiff
path: root/src/core/hle/kernel/svc.cpp
Commit message (Collapse)AuthorAgeFilesLines
* Merge pull request #2410 from lioncash/affinitybunnei2019-05-191-36/+43
|\ | | | | kernel/svc: Reorganize and fix up the initial handling of svcSetThreadCoreMask()
| * kernel/svc: Make svcCreateThread/svcStartThread/svcSleepThread/svcExitThread ↵Lioncash2019-04-291-4/+4
| | | | | | | | | | | | | | | | 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.
| * kernel/svc: Reorganize svcSetThreadCoreMask()Lioncash2019-04-291-32/+39
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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.
| * kernel/thread: Update thread processor ID flagsLioncash2019-04-291-1/+1
| | | | | | | | Adds the missing flags to the enum and documents them.
* | Merge pull request #2486 from lioncash/resetnameSebastian Valle2019-05-191-1/+1
|\ \ | | | | | | core/kernel/object: Rename ResetType enum members for clarity
| * | core/kernel/object: Rename ResetType enum membersLioncash2019-05-181-1/+1
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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.
* | | kernel/svc: Mark GetThreadList() and UnmapProcessCodeMemory() as internally ↵Lioncash2019-05-181-4/+4
|/ / | | | | | | | | | | | | | | 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.
* | Merge pull request #2416 from lioncash/waitbunnei2019-04-241-6/+4
|\ \ | | | | | | kernel/svc: Clean up wait synchronization related functionality
| * | kernel/thread: Unify wait synchronization typesLioncash2019-04-171-2/+2
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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).
| * | kernel/svc: Migrate svcCancelSynchronization behavior to a thread functionLioncash2019-04-171-4/+2
| | | | | | | | | | | | | | | | | | | | | 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.
* | | kernel/svc: Name supervisor call 0x36Lioncash2019-04-191-1/+1
| | | | | | | | | | | | | | | This call was added to the SVC handlers in the 8.0.0 kernel, so we can finally give it a name.
* | | Merge pull request #2397 from lioncash/thread-unusedbunnei2019-04-171-8/+10
|\ \ \ | |/ / |/| | kernel/thread: Remove unused guest_handle member variable
| * | svc: Specify handle value in thread's nameLioncash2019-04-151-2/+5
| | | | | | | | | | | | Allows the handle to be seen alongside the entry point.
| * | kernel/thread: Remove unused guest_handle member variableLioncash2019-04-141-6/+5
| |/ | | | | | | | | | | 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.
* | kernel/svc: Implement svcUnmapProcessCodeMemoryLioncash2019-04-121-1/+69
| | | | | | | | | | | | | | | | | | | | | | | | 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.
* | kernel/svc: Implement svcMapProcessCodeMemoryLioncash2019-04-121-1/+69
|/ | | | | This is utilized for mapping code modules into memory. Notably, the ldr service would call this in order to map objects into memory.
* kernel/svc: Deglobalize the supervisor call handlersLioncash2019-04-071-162/+175
| | | | | | | | | | | 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.
* kernel/svc: Properly sanitize mutex address in WaitProcessWideKeyAtomicLioncash2019-04-031-0/+14
| | | | | | 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.
* Merge pull request #2305 from lioncash/sharedbunnei2019-04-031-1/+1
|\ | | | | kernel/shared_memory: Sanitize supplied size when unmapping
| * kernel/shared_memory: Sanitize supplied size when unmappingLioncash2019-03-291-1/+1
| | | | | | | | | | | | | | | | The kernel makes sure that the given size to unmap is always the same size as the entire region managed by the shared memory instance, otherwise it returns an error code signifying an invalid size. This is similarly done for transfer memory (which we already check for).
* | kernel/svc: Implement svcGetThreadListLioncash2019-04-021-1/+41
| | | | | | | | | | | | | | | | | | | | | | | | | | 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.
* | kernel/svc: Implement svcGetProcessListLioncash2019-04-021-1/+38
| | | | | | | | | | | | This service function simply copies out a specified number of kernel process IDs, while simultaneously reporting the total number of processes.
* | general: Use deducation guides for std::lock_guard and std::unique_lockLioncash2019-04-011-1/+1
| | | | | | | | | | | | | | Since C++17, the introduction of deduction guides for locking facilities means that we no longer need to hardcode the mutex type into the locks themselves, making it easier to switch mutex types, should it ever be necessary in the future.
* | Merge pull request #2304 from lioncash/memsizebunnei2019-03-301-4/+4
|\ \ | |/ |/| kernel/process: Report total physical memory used to svcGetInfo slightly better
| * kernel/process: Report total physical memory used to svcGetInfoLioncash2019-03-281-4/+4
| | | | | | | | | | | | | | 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.
* | Merge pull request #2266 from FernandoS27/arbitrationbunnei2019-03-281-9/+10
|\ \ | |/ |/| Kernel: Fixes to Arbitration and SignalProcessWideKey Management
| * Fix small bug that kept a thread as a condvar thread after being signalled.Fernando Sahmkow2019-03-191-5/+6
| |
| * Add CondVar Thread State.Fernando Sahmkow2019-03-191-2/+2
| |
| * Small fixes to address_arbiter to better match the IDB.Fernando Sahmkow2019-03-191-2/+2
| |
* | Merge pull request #2284 from lioncash/heap-allocbunnei2019-03-281-6/+3
|\ \ | | | | | | kernel/vm_manager: Unify heap allocation/freeing functions
| * | kernel/vm_manager: Rename HeapAllocate to SetHeapSizeLioncash2019-03-241-2/+1
| | | | | | | | | | | | | | | | | | | | | | | | | | | 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.
| * | kernel/vm_manager: Remove unnecessary heap_used data memberLioncash2019-03-241-1/+1
| | | | | | | | | | | | | | | This isn't required anymore, as all the kernel ever queries is the size of the current heap, not the total usage of it.
| * | kernel/vm_manager: Tidy up heap allocation codeLioncash2019-03-241-4/+2
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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.
* | | Merge pull request #2232 from lioncash/transfer-memorybunnei2019-03-241-6/+114
|\ \ \ | |/ / |/| | core/hle/kernel: Split transfer memory handling out into its own class
| * | core/hle/kernel/svc: Implement svcUnmapTransferMemoryLioncash2019-03-131-1/+48
| | | | | | | | | | | | | | | Similarly, like svcMapTransferMemory, we can also implement svcUnmapTransferMemory fairly trivially as well.
| * | core/hle/kernel/svc: Implement svcMapTransferMemoryLioncash2019-03-131-1/+57
| | | | | | | | | | | | | | | Now that transfer memory handling is separated from shared memory, we can implement svcMapTransferMemory pretty trivially.
| * | core/hle/kernel: Split transfer memory handling out into its own classLioncash2019-03-131-4/+9
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Within the kernel, shared memory and transfer memory facilities exist as completely different kernel objects. They also have different validity checking as well. Therefore, we shouldn't be treating the two as the same kind of memory. They also differ in terms of their behavioral aspect as well. Shared memory is intended for sharing memory between processes, while transfer memory is intended to be for transferring memory to other processes. This breaks out the handling for transfer memory into its own class and treats it as its own kernel object. This is also important when we consider resource limits as well. Particularly because transfer memory is limited by the resource limit value set for it. While we currently don't handle resource limit testing against objects yet (but we do allow setting them), this will make implementing that behavior much easier in the future, as we don't need to distinguish between shared memory and transfer memory allocations in the same place.
* | | Merge pull request #2234 from lioncash/mutexbunnei2019-03-211-6/+11
|\ \ \ | |_|/ |/| | core/hle/kernel: Make Mutex a per-process class.
| * | core/hle/kernel: Make Mutex a per-process class.Lioncash2019-03-141-6/+11
| |/ | | | | | | | | | | | | 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.
* | kernel/thread: Move thread exiting logic from ExitCurrentThread to svcExitThreadLioncash2019-03-151-3/+7
| | | | | | | | | | Puts the operation on global state in the same places as the rest of the svc calls.
* | kernel/thread: Migrate WaitCurrentThread_Sleep into the Thread interfaceLioncash2019-03-151-11/+11
|/ | | | | | Rather than make a global accessor for this sort of thing. We can make it a part of the thread interface itself. This allows getting rid of a hidden global accessor in the kernel code.
* kernel: Make the address arbiter instance per-processLioncash2019-03-071-2/+4
| | | | | | | | | | 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.
* kernel/svc: Move address arbiter signaling behind a unified API functionLioncash2019-03-071-15/+2
| | | | | | | Similar to how WaitForAddress was isolated to its own function, we can also move the necessary conditional checking into the address arbiter class itself, allowing us to hide the implementation details of it from public use.
* kernel/svc: Move address arbiter waiting behind a unified API functionLioncash2019-03-071-14/+2
| | | | | | Rather than let the service call itself work out which function is the proper one to call, we can make that a behavior of the arbiter itself, so we don't need to directly expose those implementation details.
* Merge pull request #2197 from lioncash/includebunnei2019-03-061-0/+1
|\ | | | | core/hle/ipc: Remove unnecessary includes
| * core/hle/ipc: Remove unnecessary includesLioncash2019-03-051-0/+1
| | | | | | | | | | | | | | | | | | | | | | Removes a few inclusion dependencies from the headers or replaces existing ones with ones that don't indirectly include the required headers. This allows removing an inclusion of core/memory.h, meaning that if the memory header is ever changed in the future, it won't result in rebuilding the entirety of the HLE services (as the IPC headers are used quite ubiquitously throughout the HLE service implementations).
* | Merge pull request #2199 from lioncash/arbiterbunnei2019-03-061-6/+8
|\ \ | | | | | | kernel/address_arbiter: Convert the address arbiter into a class
| * | kernel/address_arbiter: Convert the address arbiter into a classLioncash2019-03-051-6/+8
| |/ | | | | | | | | | | Places all of the functions for address arbiter operation into a class. This will be necessary for future deglobalizing efforts related to both the memory and system itself.
* / svc: Migrate address range checking functions to VMManagerLioncash2019-03-041-21/+4
|/ | | | Provides a bit of a more proper interface for these functions.
* core_timing: Convert core timing into a classLioncash2019-02-151-4/+6
| | | | | | | | | | | 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.
generated by cgit v1.2.3 (git 2.39.1) at 2026-11-06 11:23:35 +0000