summaryrefslogtreecommitdiff
path: root/drivers/gpu/drm/nouveau/nvkm/subdev/instmem/nv50.c
AgeCommit message (Collapse)Author
2025-05-19drm/nouveau: add support for GH100Ben Skeggs
This commit enables basic support for Hopper GPUs, and is intended primarily as a base supporting Blackwell GPUs, which reuse most of the code added here. Advanced features such as Confidential Compute are not supported. Beyond a few miscellaneous register moves and HW class ID plumbing, the bulk of the changes implemented here are to support the GSP-RM boot sequence used on Hopper/Blackwell GPUs, as well as a new page table layout. There should be no changes here that impact prior GPUs. Signed-off-by: Ben Skeggs <bskeggs@nvidia.com> Co-developed-by: Timur Tabi <ttabi@nvidia.com> Signed-off-by: Timur Tabi <ttabi@nvidia.com> Reviewed-by: Dave Airlie <airlied@redhat.com> Reviewed-by: Timur Tabi <ttabi@nvidia.com> Tested-by: Timur Tabi <ttabi@nvidia.com> Signed-off-by: Dave Airlie <airlied@redhat.com>
2025-05-19drm/nouveau: improve handling of 64-bit BARsBen Skeggs
GPUs exist now with a 64-bit BAR0, which mean that BAR1 and BAR2's indices (as passed to pci_resource_len() etc) are bumped up by one. Modify nvkm_device.resource_addr/size() to take an enum instead of an integer bar index, and take IORESOURCE_MEM_64 into account when translating to the "raw" bar id. [airlied: fixup ERR_PTR] Signed-off-by: Ben Skeggs <bskeggs@nvidia.com> Reviewed-by: Dave Airlie <airlied@redhat.com> Reviewed-by: Timur Tabi <ttabi@nvidia.com> Tested-by: Timur Tabi <ttabi@nvidia.com> Signed-off-by: Dave Airlie <airlied@redhat.com>
2025-05-19drm/nouveau/instmem: add hal for set_bar0_window_addr()Ben Skeggs
GH100/GBxxx have moved the register that controls where in VRAM the the BAR0 NV_PRAMIN window points. Add a HAL for this, as the BAR0 window is needed for BAR2 bootstrap. Signed-off-by: Ben Skeggs <bskeggs@nvidia.com> Reviewed-by: Dave Airlie <airlied@redhat.com> Reviewed-by: Timur Tabi <ttabi@nvidia.com> Tested-by: Timur Tabi <ttabi@nvidia.com> Signed-off-by: Dave Airlie <airlied@redhat.com>
2024-04-15nouveau: fix instmem race condition around ptr storesDave Airlie
Running a lot of VK CTS in parallel against nouveau, once every few hours you might see something like this crash. BUG: kernel NULL pointer dereference, address: 0000000000000008 PGD 8000000114e6e067 P4D 8000000114e6e067 PUD 109046067 PMD 0 Oops: 0000 [#1] PREEMPT SMP PTI CPU: 7 PID: 53891 Comm: deqp-vk Not tainted 6.8.0-rc6+ #27 Hardware name: Gigabyte Technology Co., Ltd. Z390 I AORUS PRO WIFI/Z390 I AORUS PRO WIFI-CF, BIOS F8 11/05/2021 RIP: 0010:gp100_vmm_pgt_mem+0xe3/0x180 [nouveau] Code: c7 48 01 c8 49 89 45 58 85 d2 0f 84 95 00 00 00 41 0f b7 46 12 49 8b 7e 08 89 da 42 8d 2c f8 48 8b 47 08 41 83 c7 01 48 89 ee <48> 8b 40 08 ff d0 0f 1f 00 49 8b 7e 08 48 89 d9 48 8d 75 04 48 c1 RSP: 0000:ffffac20c5857838 EFLAGS: 00010202 RAX: 0000000000000000 RBX: 00000000004d8001 RCX: 0000000000000001 RDX: 00000000004d8001 RSI: 00000000000006d8 RDI: ffffa07afe332180 RBP: 00000000000006d8 R08: ffffac20c5857ad0 R09: 0000000000ffff10 R10: 0000000000000001 R11: ffffa07af27e2de0 R12: 000000000000001c R13: ffffac20c5857ad0 R14: ffffa07a96fe9040 R15: 000000000000001c FS: 00007fe395eed7c0(0000) GS:ffffa07e2c980000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 0000000000000008 CR3: 000000011febe001 CR4: 00000000003706f0 DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000 DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400 Call Trace: ... ? gp100_vmm_pgt_mem+0xe3/0x180 [nouveau] ? gp100_vmm_pgt_mem+0x37/0x180 [nouveau] nvkm_vmm_iter+0x351/0xa20 [nouveau] ? __pfx_nvkm_vmm_ref_ptes+0x10/0x10 [nouveau] ? __pfx_gp100_vmm_pgt_mem+0x10/0x10 [nouveau] ? __pfx_gp100_vmm_pgt_mem+0x10/0x10 [nouveau] ? __lock_acquire+0x3ed/0x2170 ? __pfx_gp100_vmm_pgt_mem+0x10/0x10 [nouveau] nvkm_vmm_ptes_get_map+0xc2/0x100 [nouveau] ? __pfx_nvkm_vmm_ref_ptes+0x10/0x10 [nouveau] ? __pfx_gp100_vmm_pgt_mem+0x10/0x10 [nouveau] nvkm_vmm_map_locked+0x224/0x3a0 [nouveau] Adding any sort of useful debug usually makes it go away, so I hand wrote the function in a line, and debugged the asm. Every so often pt->memory->ptrs is NULL. This ptrs ptr is set in the nv50_instobj_acquire called from nvkm_kmap. If Thread A and Thread B both get to nv50_instobj_acquire around the same time, and Thread A hits the refcount_set line, and in lockstep thread B succeeds at refcount_inc_not_zero, there is a chance the ptrs value won't have been stored since refcount_set is unordered. Force a memory barrier here, I picked smp_mb, since we want it on all CPUs and it's write followed by a read. v2: use paired smp_rmb/smp_wmb. Cc: <stable@vger.kernel.org> Fixes: be55287aa5ba ("drm/nouveau/imem/nv50: embed nvkm_instobj directly into nv04_instobj") Signed-off-by: Dave Airlie <airlied@redhat.com> Signed-off-by: Danilo Krummrich <dakr@redhat.com> Link: https://patchwork.freedesktop.org/patch/msgid/20240411011510.2546857-1-airlied@gmail.com
2023-10-31drm/nouveau/mmu/r535: initial supportBen Skeggs
- Valid VRAM regions are read from GSP-RM, and used to construct our MM - BAR1/BAR2 VMMs modified to be shared with RM - Client VMMs have RM VASPACE objects created for them - Adds FBSR to backup system objects in VRAM across suspend Signed-off-by: Ben Skeggs <bskeggs@redhat.com> Signed-off-by: Dave Airlie <airlied@redhat.com> Link: https://patchwork.freedesktop.org/patch/msgid/20230918202149.4343-37-skeggsb@gmail.com
2023-10-31drm/nouveau/imem/tu102-: prepare for GSP-RMBen Skeggs
- move suspend/resume paths to HW-specific code - allow (future) RM paths to be based on nv50_instmem Signed-off-by: Ben Skeggs <bskeggs@redhat.com> Signed-off-by: Dave Airlie <airlied@redhat.com> Link: https://patchwork.freedesktop.org/patch/msgid/20230918202149.4343-15-skeggsb@gmail.com
2022-11-09drm/nouveau/imem: allow bar2 mapping of user allocationsBen Skeggs
Will be used to init client-allocated USERD to default values. Signed-off-by: Ben Skeggs <bskeggs@redhat.com> Reviewed-by: Lyude Paul <lyude@redhat.com>
2022-03-03drm/nouveau/instmem: fix uninitialized_var.cocci warningGuo Zhengkui
Fix following coccicheck warning: drivers/gpu/drm/nouveau/nvkm/subdev/instmem/nv50.c:316:11-12: WARNING this kind of initialization is deprecated. `void *map = map` has the same form of uninitialized_var() macro. I remove the redundant assignement. It has been tested with gcc (Debian 8.3.0-6) 8.3.0. The patch which removed uninitialized_var() is: https://lore.kernel.org/all/20121028102007.GA7547@gmail.com/ And there is very few "/* GCC */" comments in the Linux kernel code now. Signed-off-by: Guo Zhengkui <guozhengkui@vivo.com> Reviewed-by: Lyude Paul <lyude@redhat.com> Signed-off-by: Lyude Paul <lyude@redhat.com> Link: https://patchwork.freedesktop.org/patch/msgid/20220228142352.18006-1-guozhengkui@vivo.com
2021-02-11drm/nouveau/instmem: switch to instanced constructorBen Skeggs
Signed-off-by: Ben Skeggs <bskeggs@redhat.com> Reviewed-by: Lyude Paul <lyude@redhat.com>
2021-02-11drm/nouveau/instmem: protect mm/lru with private mutexBen Skeggs
nvkm_subdev.mutex is going away. Signed-off-by: Ben Skeggs <bskeggs@redhat.com> Reviewed-by: Lyude Paul <lyude@redhat.com>
2018-12-11drm/nouveau/imem/nv50: support pinning objects in BAR2 and returning addressBen Skeggs
Various structures are accessed by the GPU through BAR2 for some reason on newer GPUs. This commit makes it more convenient to handle. Will be used for GP100- fault buffers, and GV100- fault method buffers. Signed-off-by: Ben Skeggs <bskeggs@redhat.com>
2017-12-19drm/nouveau/imem/nv50: fix refcount_t warningBen Skeggs
Signed-off-by: Ben Skeggs <bskeggs@redhat.com>
2017-11-02drm/nouveau/imem/nv50-: use new interfaces for vmm operationsBen Skeggs
Signed-off-by: Ben Skeggs <bskeggs@redhat.com>
2017-11-02drm/nouveau/imem/nv50: allocate memory with nvkm_ram_get()Ben Skeggs
Signed-off-by: Ben Skeggs <bskeggs@redhat.com>
2017-11-02drm/nouveau/core/memory: change map interface to support upcoming mmu changesBen Skeggs
Map flags (access, kind, etc) are currently defined in either the VMA, or the memory object, which turns out to not be ideal for things like suballocated buffers, etc. These will become per-map flags instead, so we need to support passing these arguments in nvkm_memory_map(). Signed-off-by: Ben Skeggs <bskeggs@redhat.com>
2017-11-02drm/nouveau: separate buffer object backing memory from nvkm structuresBen Skeggs
Signed-off-by: Ben Skeggs <bskeggs@redhat.com>
2017-11-02drm/nouveau/imem: use fast-path for resume restoreBen Skeggs
Before: "imem: init completed in 299277us" After: "imem: init completed in 11574us" Suspend from Fedora 26 gnome desktop on GP102. Signed-off-by: Ben Skeggs <bskeggs@redhat.com>
2017-11-02drm/nouveau/imem: separate pre-BAR2-bootstrap objects from the restBen Skeggs
These will require slow-path access during suspend/resume. Signed-off-by: Ben Skeggs <bskeggs@redhat.com>
2017-11-02drm/nouveau/imem: remove now-unused wrapper for backend objectsBen Skeggs
Signed-off-by: Ben Skeggs <bskeggs@redhat.com>
2017-11-02drm/nouveau/imem/nv50: support eviction of BAR2 mappingsBen Skeggs
A good deal of the structures we map into here aren't accessed very often at all, and Fedora 26 has exposed an issue where after creating a heap of channels, BAR2 space would run out, and we'd need to make use of the slow path while accessing important structures like page tables. This implements an LRU on BAR2 space, which allows eviction of mappings that aren't currently needed, to make space for other objects. Signed-off-by: Ben Skeggs <bskeggs@redhat.com>
2017-11-02drm/nouveau/imem/nv50: prevent fast-path for mapped objects when BAR isn't readyBen Skeggs
Another piece of solving the "GP100 BAR2 VMM bootstrap" puzzle. Without doing this, we'd attempt to write PDEs for the lower page table levels through BAR2 before BAR2 access has been fully initialised. Signed-off-by: Ben Skeggs <bskeggs@redhat.com>
2017-11-02drm/nouveau/imem/nv50: map bar2 write-combinedBen Skeggs
Signed-off-by: Ben Skeggs <bskeggs@redhat.com>
2017-11-02drm/nouveau/imem/nv50: embed nvkm_instobj directly into nv04_instobjBen Skeggs
This is not as simple as it was for earlier GPUs, due to the need to swap accessor functions depending on whether BAR2 is usable or not. We were previously protected by nvkm_instobj's accessor functions keeping an object mapped permanently, with some unclear magic that managed to hit the slow-path where needed even if an object was marked as mapped. That's been replaced here by reference counting maps (some objects, like page tables can be accessed concurrently), and swapping the functions as necessary. Signed-off-by: Ben Skeggs <bskeggs@redhat.com>
2017-11-02drm/nouveau/imem/nv50: move slow-path locking into rd/wr functionsBen Skeggs
This is to simplify upcoming changes. The slow-path is something that currently occurs during bootstrap of the BAR2 VMM, while backing up an object during suspend/resume, or when BAR2 address space runs out. The latter is a real problem that can happen at runtime, and occurs in Fedora 26 already (due to some change that causes a lot of channels to be created at login), so ideally we'd prefer not to make it any slower. We'd also like suspend/resume speed to not suffer. Upcoming commits will solve those problems in a better way, making the extra overhead of moving the locking here a non-issue. Signed-off-by: Ben Skeggs <bskeggs@redhat.com>
2017-11-02drm/nouveau/imem/nv50: split object map out from api functionsBen Skeggs
acquire()/boot() will need different logic in addition to performing the actual mapping. Signed-off-by: Ben Skeggs <bskeggs@redhat.com>
2017-11-02drm/nouveau/core/memory: split info pointers from accessor pointersBen Skeggs
The accessor functions can change as a result of acquire()/release() calls, and are protected by any refcounting done there. Other functions must remain constant, as they can be called any time. Signed-off-by: Ben Skeggs <bskeggs@redhat.com>
2017-11-02drm/nouveau/bar: modify interface to bar2 vmm mappingBen Skeggs
Match API with the BAR1 version. Signed-off-by: Ben Skeggs <bskeggs@redhat.com>
2015-08-28drm/nouveau/device: cleaner abstraction for device resource functionsBen Skeggs
Signed-off-by: Ben Skeggs <bskeggs@redhat.com>
2015-08-28drm/nouveau/imem: convert to new-style nvkm_subdevBen Skeggs
Signed-off-by: Ben Skeggs <bskeggs@redhat.com>
2015-08-28drm/nouveau/bar: convert to new-style nvkm_subdevBen Skeggs
Signed-off-by: Ben Skeggs <bskeggs@redhat.com>
2015-08-28drm/nouveau/imem: improve management of instance memoryBen Skeggs
Signed-off-by: Ben Skeggs <bskeggs@redhat.com>
2015-08-28drm/nouveau/fb: transition nvkm_ram away from being based on nvkm_objectBen Skeggs
Signed-off-by: Ben Skeggs <bskeggs@redhat.com>
2015-08-28drm/nouveau/imem: switch to device pri macrosBen Skeggs
Signed-off-by: Ben Skeggs <bskeggs@redhat.com>
2015-08-28drm/nouveau/imem: cosmetic changesBen Skeggs
This is purely preparation for upcoming commits, there should be no code changes here. Signed-off-by: Ben Skeggs <bskeggs@redhat.com>
2015-08-28drm/nouveau/fb: cosmetic changesBen Skeggs
This is purely preparation for upcoming commits, there should be no code changes here. Signed-off-by: Ben Skeggs <bskeggs@redhat.com>
2015-01-22drm/nouveau/instmem: namespace + nvidia gpu names (no binary change)Ben Skeggs
The namespace of NVKM is being changed to nvkm_ instead of nouveau_, which will be used for the DRM part of the driver. This is being done in order to make it very clear as to what part of the driver a given symbol belongs to, and as a minor step towards splitting the DRM driver out to be able to stand on its own (for virt). Because there's already a large amount of churn here anyway, this is as good a time as any to also switch to NVIDIA's device and chipset naming to ease collaboration with them. A comparison of objdump disassemblies proves no code changes. Signed-off-by: Ben Skeggs <bskeggs@redhat.com>
2015-01-22drm/nouveau: remove symlinks, move core/ to nvkm/ (no code changes)Ben Skeggs
The symlinks were annoying some people, and they're not used anywhere else in the kernel tree. The include directory structure has been changed so that symlinks aren't needed anymore. NVKM has been moved from core/ to nvkm/ to make it more obvious as to what the directory is for, and as some minor prep for when NVKM gets split out into its own module (virt) at a later date. Signed-off-by: Ben Skeggs <bskeggs@redhat.com>