1/*
2 * Copyright 2014 Advanced Micro Devices, Inc.
3 *
4 * Permission is hereby granted, free of charge, to any person obtaining a
5 * copy of this software and associated documentation files (the "Software"),
6 * to deal in the Software without restriction, including without limitation
7 * the rights to use, copy, modify, merge, publish, distribute, sublicense,
8 * and/or sell copies of the Software, and to permit persons to whom the
9 * Software is furnished to do so, subject to the following conditions:
10 *
11 * The above copyright notice and this permission notice shall be included in
12 * all copies or substantial portions of the Software.
13 *
14 * THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, EXPRESS OR
15 * IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY,
16 * FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT.  IN NO EVENT SHALL
17 * THE COPYRIGHT HOLDER(S) OR AUTHOR(S) BE LIABLE FOR ANY CLAIM, DAMAGES OR
18 * OTHER LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE,
19 * ARISING FROM, OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR
20 * OTHER DEALINGS IN THE SOFTWARE.
21 *
22 */
23
24#include <linux/device.h>
25#include <linux/export.h>
26#include <linux/err.h>
27#include <linux/fs.h>
28#include <linux/sched.h>
29#include <linux/slab.h>
30#include <linux/uaccess.h>
31#include <linux/compat.h>
32#include <uapi/linux/kfd_ioctl.h>
33#include <linux/time.h>
34#include "kfd_priv.h"
35#include <linux/mm.h>
36#include <uapi/asm-generic/mman-common.h>
37#include <asm/processor.h>
38
39/*
40 * The primary memory I/O features being added for revisions of gfxip
41 * beyond 7.0 (Kaveri) are:
42 *
43 * Access to ATC/IOMMU mapped memory w/ associated extension of VA to 48b
44 *
45 * “Flat” shader memory access – These are new shader vector memory
46 * operations that do not reference a T#/V# so a “pointer” is what is
47 * sourced from the vector gprs for direct access to memory.
48 * This pointer space has the Shared(LDS) and Private(Scratch) memory
49 * mapped into this pointer space as apertures.
50 * The hardware then determines how to direct the memory request
51 * based on what apertures the request falls in.
52 *
53 * Unaligned support and alignment check
54 *
55 *
56 * System Unified Address - SUA
57 *
58 * The standard usage for GPU virtual addresses are that they are mapped by
59 * a set of page tables we call GPUVM and these page tables are managed by
60 * a combination of vidMM/driver software components.  The current virtual
61 * address (VA) range for GPUVM is 40b.
62 *
63 * As of gfxip7.1 and beyond we’re adding the ability for compute memory
64 * clients (CP/RLC, DMA, SHADER(ifetch, scalar, and vector ops)) to access
65 * the same page tables used by host x86 processors and that are managed by
66 * the operating system. This is via a technique and hardware called ATC/IOMMU.
67 * The GPU has the capability of accessing both the GPUVM and ATC address
68 * spaces for a given VMID (process) simultaneously and we call this feature
69 * system unified address (SUA).
70 *
71 * There are three fundamental address modes of operation for a given VMID
72 * (process) on the GPU:
73 *
74 *	HSA64 – 64b pointers and the default address space is ATC
75 *	HSA32 – 32b pointers and the default address space is ATC
76 *	GPUVM – 64b pointers and the default address space is GPUVM (driver
77 *		model mode)
78 *
79 *
80 * HSA64 - ATC/IOMMU 64b
81 *
82 * A 64b pointer in the AMD64/IA64 CPU architecture is not fully utilized
83 * by the CPU so an AMD CPU can only access the high area
84 * (VA[63:47] == 0x1FFFF) and low area (VA[63:47 == 0) of the address space
85 * so the actual VA carried to translation is 48b.  There is a “hole” in
86 * the middle of the 64b VA space.
87 *
88 * The GPU not only has access to all of the CPU accessible address space via
89 * ATC/IOMMU, but it also has access to the GPUVM address space.  The “system
90 * unified address” feature (SUA) is the mapping of GPUVM and ATC address
91 * spaces into a unified pointer space.  The method we take for 64b mode is
92 * to map the full 40b GPUVM address space into the hole of the 64b address
93 * space.
94
95 * The GPUVM_Base/GPUVM_Limit defines the aperture in the 64b space where we
96 * direct requests to be translated via GPUVM page tables instead of the
97 * IOMMU path.
98 *
99 *
100 * 64b to 49b Address conversion
101 *
102 * Note that there are still significant portions of unused regions (holes)
103 * in the 64b address space even for the GPU.  There are several places in
104 * the pipeline (sw and hw), we wish to compress the 64b virtual address
105 * to a 49b address.  This 49b address is constituted of an “ATC” bit
106 * plus a 48b virtual address.  This 49b address is what is passed to the
107 * translation hardware.  ATC==0 means the 48b address is a GPUVM address
108 * (max of 2^40 – 1) intended to be translated via GPUVM page tables.
109 * ATC==1 means the 48b address is intended to be translated via IOMMU
110 * page tables.
111 *
112 * A 64b pointer is compared to the apertures that are defined (Base/Limit), in
113 * this case the GPUVM aperture (red) is defined and if a pointer falls in this
114 * aperture, we subtract the GPUVM_Base address and set the ATC bit to zero
115 * as part of the 64b to 49b conversion.
116 *
117 * Where this 64b to 49b conversion is done is a function of the usage.
118 * Most GPU memory access is via memory objects where the driver builds
119 * a descriptor which consists of a base address and a memory access by
120 * the GPU usually consists of some kind of an offset or Cartesian coordinate
121 * that references this memory descriptor.  This is the case for shader
122 * instructions that reference the T# or V# constants, or for specified
123 * locations of assets (ex. the shader program location).  In these cases
124 * the driver is what handles the 64b to 49b conversion and the base
125 * address in the descriptor (ex. V# or T# or shader program location)
126 * is defined as a 48b address w/ an ATC bit.  For this usage a given
127 * memory object cannot straddle multiple apertures in the 64b address
128 * space. For example a shader program cannot jump in/out between ATC
129 * and GPUVM space.
130 *
131 * In some cases we wish to pass a 64b pointer to the GPU hardware and
132 * the GPU hw does the 64b to 49b conversion before passing memory
133 * requests to the cache/memory system.  This is the case for the
134 * S_LOAD and FLAT_* shader memory instructions where we have 64b pointers
135 * in scalar and vector GPRs respectively.
136 *
137 * In all cases (no matter where the 64b -> 49b conversion is done), the gfxip
138 * hardware sends a 48b address along w/ an ATC bit, to the memory controller
139 * on the memory request interfaces.
140 *
141 *	<client>_MC_rdreq_atc   // read request ATC bit
142 *
143 *		0 : <client>_MC_rdreq_addr is a GPUVM VA
144 *
145 *		1 : <client>_MC_rdreq_addr is a ATC VA
146 *
147 *
148 * “Spare” aperture (APE1)
149 *
150 * We use the GPUVM aperture to differentiate ATC vs. GPUVM, but we also use
151 * apertures to set the Mtype field for S_LOAD/FLAT_* ops which is input to the
152 * config tables for setting cache policies. The “spare” (APE1) aperture is
153 * motivated by getting a different Mtype from the default.
154 * The default aperture isn’t an actual base/limit aperture; it is just the
155 * address space that doesn’t hit any defined base/limit apertures.
156 * The following diagram is a complete picture of the gfxip7.x SUA apertures.
157 * The APE1 can be placed either below or above
158 * the hole (cannot be in the hole).
159 *
160 *
161 * General Aperture definitions and rules
162 *
163 * An aperture register definition consists of a Base, Limit, Mtype, and
164 * usually an ATC bit indicating which translation tables that aperture uses.
165 * In all cases (for SUA and DUA apertures discussed later), aperture base
166 * and limit definitions are 64KB aligned.
167 *
168 *	<ape>_Base[63:0] = { <ape>_Base_register[63:16], 0x0000 }
169 *
170 *	<ape>_Limit[63:0] = { <ape>_Limit_register[63:16], 0xFFFF }
171 *
172 * The base and limit are considered inclusive to an aperture so being
173 * inside an aperture means (address >= Base) AND (address <= Limit).
174 *
175 * In no case is a payload that straddles multiple apertures expected to work.
176 * For example a load_dword_x4 that starts in one aperture and ends in another,
177 * does not work.  For the vector FLAT_* ops we have detection capability in
178 * the shader for reporting a “memory violation” back to the
179 * SQ block for use in traps.
180 * A memory violation results when an op falls into the hole,
181 * or a payload straddles multiple apertures.  The S_LOAD instruction
182 * does not have this detection.
183 *
184 * Apertures cannot overlap.
185 *
186 *
187 *
188 * HSA32 - ATC/IOMMU 32b
189 *
190 * For HSA32 mode, the pointers are interpreted as 32 bits and use a single GPR
191 * instead of two for the S_LOAD and FLAT_* ops. The entire GPUVM space of 40b
192 * will not fit so there is only partial visibility to the GPUVM
193 * space (defined by the aperture) for S_LOAD and FLAT_* ops.
194 * There is no spare (APE1) aperture for HSA32 mode.
195 *
196 *
197 * GPUVM 64b mode (driver model)
198 *
199 * This mode is related to HSA64 in that the difference really is that
200 * the default aperture is GPUVM (ATC==0) and not ATC space.
201 * We have gfxip7.x hardware that has FLAT_* and S_LOAD support for
202 * SUA GPUVM mode, but does not support HSA32/HSA64.
203 *
204 *
205 * Device Unified Address - DUA
206 *
207 * Device unified address (DUA) is the name of the feature that maps the
208 * Shared(LDS) memory and Private(Scratch) memory into the overall address
209 * space for use by the new FLAT_* vector memory ops.  The Shared and
210 * Private memories are mapped as apertures into the address space,
211 * and the hardware detects when a FLAT_* memory request is to be redirected
212 * to the LDS or Scratch memory when it falls into one of these apertures.
213 * Like the SUA apertures, the Shared/Private apertures are 64KB aligned and
214 * the base/limit is “in” the aperture. For both HSA64 and GPUVM SUA modes,
215 * the Shared/Private apertures are always placed in a limited selection of
216 * options in the hole of the 64b address space. For HSA32 mode, the
217 * Shared/Private apertures can be placed anywhere in the 32b space
218 * except at 0.
219 *
220 *
221 * HSA64 Apertures for FLAT_* vector ops
222 *
223 * For HSA64 SUA mode, the Shared and Private apertures are always placed
224 * in the hole w/ a limited selection of possible locations. The requests
225 * that fall in the private aperture are expanded as a function of the
226 * work-item id (tid) and redirected to the location of the
227 * “hidden private memory”. The hidden private can be placed in either GPUVM
228 * or ATC space. The addresses that fall in the shared aperture are
229 * re-directed to the on-chip LDS memory hardware.
230 *
231 *
232 * HSA32 Apertures for FLAT_* vector ops
233 *
234 * In HSA32 mode, the Private and Shared apertures can be placed anywhere
235 * in the 32b space except at 0 (Private or Shared Base at zero disables
236 * the apertures). If the base address of the apertures are non-zero
237 * (ie apertures exists), the size is always 64KB.
238 *
239 *
240 * GPUVM Apertures for FLAT_* vector ops
241 *
242 * In GPUVM mode, the Shared/Private apertures are specified identically
243 * to HSA64 mode where they are always in the hole at a limited selection
244 * of locations.
245 *
246 *
247 * Aperture Definitions for SUA and DUA
248 *
249 * The interpretation of the aperture register definitions for a given
250 * VMID is a function of the “SUA Mode” which is one of HSA64, HSA32, or
251 * GPUVM64 discussed in previous sections. The mode is first decoded, and
252 * then the remaining register decode is a function of the mode.
253 *
254 *
255 * SUA Mode Decode
256 *
257 * For the S_LOAD and FLAT_* shader operations, the SUA mode is decoded from
258 * the COMPUTE_DISPATCH_INITIATOR:DATA_ATC bit and
259 * the SH_MEM_CONFIG:PTR32 bits.
260 *
261 * COMPUTE_DISPATCH_INITIATOR:DATA_ATC    SH_MEM_CONFIG:PTR32        Mode
262 *
263 * 1                                              0                  HSA64
264 *
265 * 1                                              1                  HSA32
266 *
267 * 0                                              X                 GPUVM64
268 *
269 * In general the hardware will ignore the PTR32 bit and treat
270 * as “0” whenever DATA_ATC = “0”, but sw should set PTR32=0
271 * when DATA_ATC=0.
272 *
273 * The DATA_ATC bit is only set for compute dispatches.
274 * All “Draw” dispatches are hardcoded to GPUVM64 mode
275 * for FLAT_* / S_LOAD operations.
276 */
277
278#define MAKE_GPUVM_APP_BASE(gpu_num) \
279	(((uint64_t)(gpu_num) << 61) + 0x1000000000000L)
280
281#define MAKE_GPUVM_APP_LIMIT(base) \
282	(((uint64_t)(base) & \
283		0xFFFFFF0000000000UL) | 0xFFFFFFFFFFL)
284
285#define MAKE_SCRATCH_APP_BASE(gpu_num) \
286	(((uint64_t)(gpu_num) << 61) + 0x100000000L)
287
288#define MAKE_SCRATCH_APP_LIMIT(base) \
289	(((uint64_t)base & 0xFFFFFFFF00000000UL) | 0xFFFFFFFF)
290
291#define MAKE_LDS_APP_BASE(gpu_num) \
292	(((uint64_t)(gpu_num) << 61) + 0x0)
293#define MAKE_LDS_APP_LIMIT(base) \
294	(((uint64_t)(base) & 0xFFFFFFFF00000000UL) | 0xFFFFFFFF)
295
296int kfd_init_apertures(struct kfd_process *process)
297{
298	uint8_t id  = 0;
299	struct kfd_dev *dev;
300	struct kfd_process_device *pdd;
301
302	/*Iterating over all devices*/
303	while ((dev = kfd_topology_enum_kfd_devices(id)) != NULL &&
304		id < NUM_OF_SUPPORTED_GPUS) {
305
306		pdd = kfd_create_process_device_data(dev, process);
307		if (pdd == NULL) {
308			pr_err("Failed to create process device data\n");
309			return -1;
310		}
311		/*
312		 * For 64 bit process aperture will be statically reserved in
313		 * the x86_64 non canonical process address space
314		 * amdkfd doesn't currently support apertures for 32 bit process
315		 */
316		if (process->is_32bit_user_mode) {
317			pdd->lds_base = pdd->lds_limit = 0;
318			pdd->gpuvm_base = pdd->gpuvm_limit = 0;
319			pdd->scratch_base = pdd->scratch_limit = 0;
320		} else {
321			/*
322			 * node id couldn't be 0 - the three MSB bits of
323			 * aperture shoudn't be 0
324			 */
325			pdd->lds_base = MAKE_LDS_APP_BASE(id + 1);
326
327			pdd->lds_limit = MAKE_LDS_APP_LIMIT(pdd->lds_base);
328
329			pdd->gpuvm_base = MAKE_GPUVM_APP_BASE(id + 1);
330
331			pdd->gpuvm_limit =
332					MAKE_GPUVM_APP_LIMIT(pdd->gpuvm_base);
333
334			pdd->scratch_base = MAKE_SCRATCH_APP_BASE(id + 1);
335
336			pdd->scratch_limit =
337				MAKE_SCRATCH_APP_LIMIT(pdd->scratch_base);
338		}
339
340		dev_dbg(kfd_device, "node id %u\n", id);
341		dev_dbg(kfd_device, "gpu id %u\n", pdd->dev->id);
342		dev_dbg(kfd_device, "lds_base %llX\n", pdd->lds_base);
343		dev_dbg(kfd_device, "lds_limit %llX\n", pdd->lds_limit);
344		dev_dbg(kfd_device, "gpuvm_base %llX\n", pdd->gpuvm_base);
345		dev_dbg(kfd_device, "gpuvm_limit %llX\n", pdd->gpuvm_limit);
346		dev_dbg(kfd_device, "scratch_base %llX\n", pdd->scratch_base);
347		dev_dbg(kfd_device, "scratch_limit %llX\n", pdd->scratch_limit);
348
349		id++;
350	}
351
352	return 0;
353}
354
355
356