previously, the task of managing RM-managed memory handles was split
between nvos (OS page allocation), the RM (heap management for
carveout & IRAM heaps, and handle life-time management), nvreftrack
(abnormal process termination) and nvmap (user-space read/write/map
of memory handles). this resulted in an opaque system that was wasteful
of kernel virtual address space, didn't support CPU cache attributes for
kernel mappings and couldn't fully unwind leaked handles (e.g., if the
application leaked a pinned handle the memory might never be reclaimed).
nvmap is now a full re-implementation of the RM memory manager, unifying all
of the functionality from nvreftrack, nvos, nvmap and nvrm into one
driver used by both user and kernel-space clients.
add configs to control paranoid operation. when paranoid is enabled,
every handle reference passed into the kernel is verified to actually
have been created by nvmap; furthermore, handles which are not global
(the GET_ID ioctl has not been called for it) will fail validation
if they are referenced by any process other than the one which created
them, or a super-user process (opened via /dev/knvmap).
each file descriptor maintains its own table of nvmap_handle_ref
references, so the handle value returned to each process is unique;
furthermore, nvmap_handle_ref objects track how many times they have
been pinned, to ensure that processes which abnormally terminate with
pinned handles can be unwound correctly.
as a compile-time option, fully-unpinned handles which require IOVMM
mappings may be stored in a segmented (by size) MRU (most-recently
unpinned) eviction cache; if IOVMM space is over-committed across
multiple processes, a pin operation may reclaim any or all of the IOVMM
areas in the MRU cache. MRU is used as the eviction policy since
graphics operations frequently operate cyclically, and the least-recently
used entry may be needed almost immediately if the higher-level client
starts (e.g.) rendering the next frame.
introduce a concept of "secure" handles. secure handles may only
be mapped into IOVMM space, and when unpinned their mapping in IOVMM
space will be zapped immediately, to prevent malicious processes from
being able to access the handle.
expose carveout heap attributes for each carveout heap in sysfs,
under the nvmap device with sub-device name heap-<heap name>
* total size
* free size
* total block count
* free block count
* largest block
* largest free block
* base address
* name
* heap usage bitmask
carveout heaps may be split at run-time, if sufficient memory is available
in the heap. the split heap can be (should be) assigned a different name
and usage bitmask than the original heap. this allows a large initial
carveout to be split into smaller carveouts, to reserve sections of carveout
memory for specific usages (e.g., camera and/or video clients).
add a split entry in the sysfs tree for each carveout heap, to support
run-time splitting of carveout heaps into reserved regions. format is:
<size>,<usage>,<name>
* size should be parsable with memparse (suffixes k/K and m/M are legal)
* usage is the new heap's usage bitmask
* name is the name of the new heap (must be unique)
carveout heaps are managed using a first-fit allocator with an explicit
free list, all blocks are kept in a dynamically-sized array (doubles
in size every time all blocks are exhausted); to reduce fragmentation
caused by allocations with different alignment requirements, the
allocator will compare left-justifying and right-justifying the
allocation within the first-fit block, and choose the justification
that results in the largest remaining free block (this is particularly
important for 1M-aligned split heaps).
other code which duplicated functionality subsumed by this changelist
(RM memory manager, NvOs carveout command line parser, etc.) is deleted;
implementations of the RM memory manager on top of nvmap are provided
to support backwards compatibility
bug 634812
Change-Id: Ic89d83fed31b4cadc68653d0e825c368b9c92f81
Reviewed-on: http://git-master/r/590
Reviewed-by: Gary King <gking@nvidia.com>
Tested-by: Gary King <gking@nvidia.com>