summaryrefslogtreecommitdiffstats
path: root/src/core/hle/kernel/transfer_memory.cpp (follow)
Commit message (Collapse)AuthorAgeFilesLines
* VM_Manager: Align allocated memory to 256bytesFernando Sahmkow2019-07-191-1/+1
| | | | | | This commit ensures that all backing memory allocated for the Guest CPU is aligned to 256 bytes. This due to how gpu memory works and the heavy constraints it has in the alignment of physical memory.
* kernel/transfer_memory: Add accessors to data and sizesLioncash2019-04-031-7/+15
| | | | Also amend erroneous use of size_t. We should be using u64 here.
* core/hle/kernel: Split transfer memory handling out into its own classLioncash2019-03-131-0/+73
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.