aboutsummaryrefslogtreecommitdiff
path: root/src/core/hle/kernel/svc.cpp
AgeCommit message (Collapse)Author
2019-06-09kernel/svc: Implement ↵Lioncash
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-09kernel/svc: Amend naming for TotalMemoryUsage in svcGetInfo()Lioncash
Disambiguates and makes the name a little more consistent with TotalPhysicalMemoryUsed.
2019-06-09kernel/svc: Remove duplicate enum entry in svcGetInfo()Lioncash
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-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-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-24Merge pull request #2416 from lioncash/waitbunnei
kernel/svc: Clean up wait synchronization related functionality
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-15svc: Specify handle value in thread's nameLioncash
Allows the handle to be seen alongside the entry point.
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-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-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-03Merge pull request #2305 from lioncash/sharedbunnei
kernel/shared_memory: Sanitize supplied size when unmapping
2019-04-02kernel/svc: Implement svcGetThreadListLioncash
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-02kernel/svc: Implement svcGetProcessListLioncash
This service function simply copies out a specified number of kernel process IDs, while simultaneously reporting the total number of processes.
2019-04-01general: Use deducation guides for std::lock_guard and std::unique_lockLioncash
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.
2019-03-30Merge pull request #2304 from lioncash/memsizebunnei
kernel/process: Report total physical memory used to svcGetInfo slightly better
2019-03-29kernel/shared_memory: Sanitize supplied size when unmappingLioncash
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).
2019-03-28kernel/process: Report total physical memory used to svcGetInfoLioncash
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-28Merge pull request #2266 from FernandoS27/arbitrationbunnei
Kernel: Fixes to Arbitration and SignalProcessWideKey Management
2019-03-28Merge pull request #2284 from lioncash/heap-allocbunnei
kernel/vm_manager: Unify heap allocation/freeing functions
2019-03-24kernel/vm_manager: Rename HeapAllocate to SetHeapSizeLioncash
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.
2019-03-24kernel/vm_manager: Remove unnecessary heap_used data memberLioncash
This isn't required anymore, as all the kernel ever queries is the size of the current heap, not the total usage of it.
2019-03-24kernel/vm_manager: Tidy up heap allocation codeLioncash
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.
2019-03-24Merge pull request #2232 from lioncash/transfer-memorybunnei
core/hle/kernel: Split transfer memory handling out into its own class
2019-03-21Merge pull request #2234 from lioncash/mutexbunnei
core/hle/kernel: Make Mutex a per-process class.
2019-03-19Fix small bug that kept a thread as a condvar thread after being signalled.Fernando Sahmkow
2019-03-19Add CondVar Thread State.Fernando Sahmkow
2019-03-19Small fixes to address_arbiter to better match the IDB.Fernando Sahmkow
2019-03-15kernel/thread: Move thread exiting logic from ExitCurrentThread to svcExitThreadLioncash
Puts the operation on global state in the same places as the rest of the svc calls.
2019-03-15kernel/thread: Migrate WaitCurrentThread_Sleep into the Thread interfaceLioncash
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.
2019-03-14core/hle/kernel: Make Mutex a per-process class.Lioncash
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-13core/hle/kernel/svc: Implement svcUnmapTransferMemoryLioncash
Similarly, like svcMapTransferMemory, we can also implement svcUnmapTransferMemory fairly trivially as well.
2019-03-13core/hle/kernel/svc: Implement svcMapTransferMemoryLioncash
Now that transfer memory handling is separated from shared memory, we can implement svcMapTransferMemory pretty trivially.
2019-03-13core/hle/kernel: Split transfer memory handling out into its own classLioncash
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.
2019-03-07kernel: Make the address arbiter instance per-processLioncash
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-07kernel/svc: Move address arbiter signaling behind a unified API functionLioncash
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.
2019-03-07kernel/svc: Move address arbiter waiting behind a unified API functionLioncash
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.
2019-03-06Merge pull request #2197 from lioncash/includebunnei
core/hle/ipc: Remove unnecessary includes
2019-03-06Merge pull request #2199 from lioncash/arbiterbunnei
kernel/address_arbiter: Convert the address arbiter into a class
2019-03-05kernel/address_arbiter: Convert the address arbiter into a classLioncash
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.