- 21 Dec, 2018 1 commit
-
-
Lioncash authored
-
- 19 Dec, 2018 4 commits
-
-
bunnei authored
kernel/svc: Implement svcSetMemoryAttribute
-
Lioncash authored
With all the basic backing functionality implemented, we can now unstub svcSetMemoryAttribute.
-
Lioncash authored
This puts the backing functionality for svcSetMemoryAttribute in place, which will be utilized in a following change.
-
Lioncash authored
vm_manager: Add member function for checking a memory range adheres to certain attributes, permissions and states
-
- 18 Dec, 2018 8 commits
-
-
bunnei authored
kernel/thread: Set default fpcr
-
bunnei authored
arm_dynarmic: Set CNTFRQ value
-
MerryMage authored
-
MerryMage authored
-
bunnei authored
shader_bytecode: Fixup half float's operator B encoding
-
bunnei authored
applets: Correct usage of SignalStateChanged event
-
ReinUsesLisp authored
-
bunnei authored
Implement postfactor multiplication/division for fmul instructions
-
- 17 Dec, 2018 1 commit
-
-
heapo authored
-
- 16 Dec, 2018 2 commits
-
-
Lioncash authored
This is shorter and more concise. This also removes the now-innaccurate comment, as it's not returned wholesale to svcQueryMemory anymore.
-
Lioncash authored
Adds the barebones enumeration constants and functions in place to handle memory attributes, while also essentially leaving the attribute itself non-functional.
-
- 15 Dec, 2018 5 commits
- 14 Dec, 2018 3 commits
- 13 Dec, 2018 2 commits
-
-
Lioncash authored
We can hide the direct array from external view and instead provide functions to retrieve the necessary info. This has the benefit of completely hiding the makeup of the SinkDetails structure from the rest of the code. Given that this makes the array hidden, we can also make the array constexpr by altering the members slightly. This gets rid of several static constructor calls related to std::vector and std::function. Now we don't have heap allocations here that need to occur before the program can even enter main(). It also has the benefit of saving a little bit of heap space, but this doesn't matter too much, since the savings in that regard are pretty tiny.
-
Jens Schmer authored
Services created with the ServiceFramework base class install themselves as HleHandlers with an owning shared_ptr in the ServerPort ServiceFrameworkBase::port member variable, creating a cyclic ownership between ServiceFrameworkBase and the ServerPort, preventing deletion of the service objects. Fix that by removing the ServiceFrameworkBase::port member because that was only used to detect multiple attempts at installing a port. Instead store a flag if the port was already installed to achieve the same functionality.
-
- 12 Dec, 2018 14 commits
-
-
Mat M authored
Fix Process object leak on emulation stop
-
Lioncash authored
svcQueryProcessMemory is trivial to implement, given all the behavior necessary for it is present, it just needs a handler for it.
-
Lioncash authored
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.
-
Lioncash authored
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.
-
Lioncash authored
These should be swapped.
-
Lioncash authored
This would result in svcSetMemoryAttribute getting the wrong value for its third parameter. This is currently fine, given the service function is stubbed, however this will be unstubbed in a future change, so this needs to change.
-
Lioncash authored
The kernel returns a memory info instance with the base address set to the end of the address space, and the size of said block as 0 - address_space_end, it doesn't set both of said members to zero.
-
Lioncash authored
Gets rid of the need to directly access the managed VMAs outside of the memory manager itself just for querying memory.
-
Lioncash authored
Gets the two structures out of an unrelated header and places them with the rest of the memory management code. This also corrects the structures. PageInfo appears to only contain a 32-bit flags member, and the extra padding word in MemoryInfo isn't necessary.
-
Lioncash authored
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.
-
Jens Schmer authored
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.
-
Mat M authored
fsp_srv: Implement IStorage::GetSize
-
bunnei authored
gl_shader_cache: Resolve truncation compiler warning
-
bunnei authored
patch_manager: Prevent use of a dangling pointer within PatchRomFS
-