aboutsummaryrefslogtreecommitdiff
path: root/src/core/hle/kernel/svc.cpp
AgeCommit message (Collapse)Author
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.
2019-03-05core/hle/ipc: Remove unnecessary includesLioncash
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).
2019-03-04svc: Migrate address range checking functions to VMManagerLioncash
Provides a bit of a more proper interface for these functions.
2019-02-15core_timing: Convert core timing into a classLioncash
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-12core_timing: Rename CoreTiming namespace to Core::TimingLioncash
Places all of the timing-related functionality under the existing Core namespace to keep things consistent, rather than having the timing utilities sitting in its own completely separate namespace.
2019-01-26kernel/svc: Log out uncaught C++ exceptions from svcBreakLioncash
Looking into the implementation of the C++ standard facilities that seem to be within all modules, it appears that they use 7 as a break reason to indicate an uncaught C++ exception. This was primarily found via the third last function called within Horizon's equivalent of libcxxabi's demangling_terminate_handler(), which passes the value 0x80000007 to svcBreak.
2018-12-30kernel/svc: Correct misleading error message within CreateThread()Lioncash
This is a bounds check to ensure that the thread priority is within the valid range of 0-64. If it exceeds 64, that doesn't necessarily mean that an actual priority of 64 was expected (it actually means whoever called the function screwed up their math). Instead clarify the message to indicate the allowed range of thread priorities.
2018-12-30kernel/svc: Sanitize core number and thread priorities in CreateThread()Lioncash
Now that we handle the kernel capability descriptors we can correct CreateThread to properly check against the core and priority masks like the actual kernel does.
2018-12-30kernel/process: Rename GetAllowedProcessorMask() and ↵Lioncash
GetAllowedThreadPriorityMask() Makes them consistent with their kernel capability counterparts.
2018-12-30kernel/svc: Simplify thread core ID sanitizing in CreateThreadLioncash
Rather than use a switch here, this can be collapsed into a simple range check, which is a little easier on the eyes.
2018-12-30Merge pull request #1956 from lioncash/process-threadSebastian Valle
kernel/process: Start the main thread using the specified ideal core
2018-12-29Merge pull request #1847 from ogniK5377/backtrace-breakbunnei
Print backtrace on svcBreak
2018-12-27kernel: Rename 'default' CPU core to 'ideal' coreLioncash
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-27kernel/process: Remove most allocation functions from Process' interfaceLioncash
In all cases that these functions are needed, the VMManager can just be retrieved and used instead of providing the same functions in Process' interface. This also makes it a little nicer dependency-wise, since it gets rid of cases where the VMManager interface was being used, and then switched over to using the interface for a Process instance. Instead, it makes all accesses uniform and uses the VMManager instance for all necessary tasks. All the basic memory mapping functions did was forward to the Process' VMManager instance anyways.
2018-12-26Merge pull request #1849 from encounter/svcSetThreadActivitybunnei
svc: Implement SetThreadActivity (thread suspension)
2018-12-21Merge pull request #1925 from lioncash/pidbunnei
kernel/{process, thread}: Amend behavior related to IDs
2018-12-19kernel/svc: Handle thread handles within GetProcessIdLioncash
If a thread handle is passed to svcGetProcessId, the kernel attempts to access the process ID via the thread's instance's owning process. Technically, this function should also be handling the kernel debug objects as well, however we currently don't handle those kernel objects yet, so I've left a note via a comment about it to remind myself when implementing it in the future.
2018-12-19svc: Implement svcSetMemoryAttributeLioncash
With all the basic backing functionality implemented, we can now unstub svcSetMemoryAttribute.
2018-12-18kernel/svc: Correct output parameter for svcGetThreadIdLioncash
The service call uses a 64-bit value, just like svcGetProcessId. This amends the function signature accordingly.
2018-12-18kernel/svc: Correct output parameter for svcGetProcessIdLioncash
svcGetProcessId's out parameter is a pointer to a 64-bit value, not a 32-bit one.
2018-12-19Moved backtrace to ArmInterfaceDavid Marcec
2018-12-15Merge pull request #1732 from DarkLordZach/yield-typesbunnei
svc: Implement yield types 0 and -1
2018-12-14Merge pull request #1899 from lioncash/statebunnei
vm_manager/svc: Modify MemoryState enum, and correct error handling for svcQueryMemory
2018-12-12svc: Enable svcQueryProcessMemoryLioncash
svcQueryProcessMemory is trivial to implement, given all the behavior necessary for it is present, it just needs a handler for it.
2018-12-12svc: Write out the complete MemoryInfo structure in QueryProcessMemoryLioncash
In the previous change, the memory writing was moved into the service function itself, however it still had a problem, in that the entire MemoryInfo structure wasn't being written out, only the first 32 bytes of it were being written out. We still need to write out the trailing two reference count members and zero out the padding bits. Not doing this can result in wrong behavior in userland code in the following scenario: MemoryInfo info; // Put on the stack, not quaranteed to be zeroed out. svcQueryMemory(&info, ...); if (info.device_refcount == ...) // Whoops, uninitialized read. This can also cause the wrong thing to happen if the user code uses std::memcmp to compare the struct, with another one (questionable, but allowed), as the padding bits are not guaranteed to be a deterministic value. Note that the kernel itself also fully zeroes out the structure before writing it out including the padding bits.
2018-12-12svc: Handle memory writing explicitly within QueryProcessMemoryLioncash
Moves the memory writes directly into QueryProcessMemory instead of letting the wrapper function do it. It would be inaccurate to allow the handler to do it because there's cases where memory shouldn't even be written to. For example, if the given process handle is invalid. HOWEVER, if the memory writing is within the wrapper, then we have no control over if these memory writes occur, meaning in an error case, 68 bytes of memory randomly get trashed with zeroes, 64 of those being written to wherever the memory info address points to, and the remaining 4 being written wherever the page info address points to. One solution in this case would be to just conditionally check within the handler itself, but this is kind of smelly, given the handler shouldn't be performing conditional behavior itself, it's a behavior of the managed function. In other words, if you remove the handler from the equation entirely, does the function still retain its proper behavior? In this case, no. Now, we don't potentially trash memory from this function if an invalid query is performed.
2018-12-12vm_manager: Migrate memory querying to the VMManager interfaceLioncash
Gets rid of the need to directly access the managed VMAs outside of the memory manager itself just for querying memory.
2018-12-12vm_manager: Amend MemoryState enum membersLioncash
Amends the MemoryState enum to use the same values like the actual kernel does. Also provides the necessary operators to operate on them. This will be necessary in the future for implementing svcSetMemoryAttribute, as memory block state is checked before applying the attribute.
2018-12-12Fix Process object leak on emulation stopJens Schmer
The Process object kept itself alive indefinitely because its handle_table contains a SharedMemory object which owns a reference to the same Process object, creating a circular ownership scenario. Break that up by storing only a non-owning pointer in the SharedMemory object.