Message-ID: <1458148234-4456-1-git-send-email-Olu.Ogunbowale@imgtec.com>
Date:	Wed, 16 Mar 2016 17:10:33 +0000
From:	Olu Ogunbowale <Olu.Ogunbowale@...tec.com>
To:	<linux-mm@...ck.org>
CC:	<linux-kernel@...r.kernel.org>,
	Linus Torvalds <torvalds@...ux-foundation.org>,
	Michel Lespinasse <walken@...gle.com>,
	Andrew Morton <akpm@...ux-foundation.org>,
	Rik van Riel <riel@...hat.com>,
	Hugh Dickins <hughd@...gle.com>,
	Russell King <linux@....linux.org.uk>,
	Ralf Baechle <ralf@...ux-mips.org>,
	Paul Mundt <lethal@...ux-sh.org>,
	"David S. Miller" <davem@...emloft.net>,
	Chris Metcalf <cmetcalf@...era.com>,
	Ingo Molnar <mingo@...e.hu>,
	Thomas Gleixner <tglx@...utronix.de>,
	"H. Peter Anvin" <hpa@...or.com>,
	Olu Ogunbowale <Olu.Ogunbowale@...tec.com>
Subject: Mirroring process address space on device

In a nutshell:

Export the memory management functions, unmapped_area() &
unmapped_area_topdown(), as GPL symbols; this allows the kernel to
better support process address space mirroring on both CPU and device
for out-of-tree drivers by allowing the use of vm_unmapped_area() in a
driver's file operation get_unmapped_area().

This is required by drivers that want to control or limit a process VMA
range into which shared-virtual-memory (SVM) buffers are mapped during
an mmap() call in order to ensure that said SVM VMA does not collide
with any pre-existing VMAs used by non-buffer regions on the device
because SVM buffers must have identical VMAs on both CPU and device.

Exporting these functions is particularly useful for graphics devices as
SVM support is required by the OpenCL & HSA specifications and also SVM
support for 64-bit CPUs where the useable device SVM address range
is/maybe a subset of the full 64-bit range of the CPU. Exporting also
avoids the need to duplicate the VMA search code in such drivers.

Why do this:

The OpenCL API & Heterogeneous System Architecture (HSA) specifications
requires mirroring a process address space on both the CPU and GPU, a so
called shared-virtual-memory (SVM) support wherein the same virtual
address is used to address the same content on both the CPU and GPU.

There are different levels of support from coarse to fine-grained with
slightly different semantics (1: coarse-grained buffer SVM, 2:
fine-grained buffer SVM & 3: fine-grained system SVM); furthermore
support for the highest level, fine-grained system SVM, is optional and
this fact is central to the need for this requirement as explained
below.

For hardware & drivers implementing support for SVM up to the second
level only, i.e. fine-grained buffer SVM level, this mirroring is
effectively at a buffer allocation level and therefore excludes the need
for any heterogeneous memory management (HMM) like functionality which
is required to support SVM up to the highest level, i.e. fine-grained
system SVM (see http://lwn.net/Articles/597289/ for details). In this
case, drivers would benefit from being able to specify/control the SVM
VMA range during a mmap() call especially if the device SVM VMA range is
a subset of the full 32-bit/64-bit CPU (process/mmap) range.

As the kernel already provides a char driver
file->f_op->get_unmapped_area() entry point for this, the backend of
such a call would require a constrained search for an unmapped address
range using vm_unmapped_area() which currently calls into either
unmapped_area() or  unmapped_area_topdown() both of which are not
currently exported symbols. Therefore, exporting these symbols allows
the kerne to provide better support this type of process address space
and it also avoids duplicating the VMA search code in these drivers.

As always, comments are welcome and many thanks in advance for
consideration.

Olu Ogunbowale (1):
  mm: Export symbols unmapped_area() & unmapped_area_topdown()

 mm/mmap.c | 4 ++++
 1 file changed, 4 insertions(+)

-- 
2.7.1

Powered by blists - more mailing lists