#
17008293 |
|
19-Sep-2023 |
Ben Skeggs <bskeggs@redhat.com> |
drm/nouveau/mmu/gp100-: always invalidate TLBs at CACHE_LEVEL_ALL Fixes some issues when running on top of RM. Signed-off-by: Ben Skeggs <bskeggs@redhat.com> Reviewed-by: Lyude Paul <lyude@redhat.com> Acked-by: Danilo Krummrich <me@dakr.org> Signed-off-by: Lyude Paul <lyude@redhat.com> Link: https://patchwork.freedesktop.org/patch/msgid/20230919220442.202488-5-lyude@redhat.com
|
#
6b252cf4 |
|
04-Aug-2023 |
Danilo Krummrich <dakr@redhat.com> |
drm/nouveau: nvkm/vmm: implement raw ops to manage uvmm The new VM_BIND UAPI uses the DRM GPU VA manager to manage the VA space. Hence, we a need a way to manipulate the MMUs page tables without going through the internal range allocator implemented by nvkm/vmm. This patch adds a raw interface for nvkm/vmm to pass the resposibility for managing the address space and the corresponding map/unmap/sparse operations to the upper layers. Reviewed-by: Dave Airlie <airlied@redhat.com> Signed-off-by: Danilo Krummrich <dakr@redhat.com> Link: https://patchwork.freedesktop.org/patch/msgid/20230804182406.5222-11-dakr@redhat.com
|
#
381ba6a6 |
|
12-Oct-2021 |
Karol Herbst <kherbst@redhat.com> |
drm/nouveau/mmu/gp100: remove unused variable Fixes a compilation issue introduced because I forgot to test with WERROR enabled. Cc: Stephen Rothwell <sfr@canb.auug.org.au> Cc: DRI <dri-devel@lists.freedesktop.org> Cc: nouveau@lists.freedesktop.org Fixes: 404046cf4805 ("drm/nouveau/mmu/gp100-: drop unneeded assignment in the if condition.") Acked-by: Adam Jackson <ajax@redhat.com> Reviewed-by: Lyude Paul <lyude@redhat.com> Signed-off-by: Karol Herbst <kherbst@redhat.com> Link: https://patchwork.freedesktop.org/patch/msgid/20211012133334.1737918-1-kherbst@redhat.com
|
#
404046cf |
|
20-Aug-2021 |
Luo penghao <luo.penghao@zte.com.cn> |
drm/nouveau/mmu/gp100-: drop unneeded assignment in the if condition. In order to keep the code style consistency of the whole file, the 'inst' assignments should be deleted. The clang_analyzer complains as follows: drivers/gpu/drm/nouveau/nvkm/subdev/mmu/vmmgp100.c:499:8: warning: Although the value storedto 'inst' is used in the enclosing expression, the value is never actually read from 'inst'. Karol: Removed unneeded brackets. Reported-by: Zeal Robot <zealci@zte.com.cn> Signed-off-by: Luo penghao <luo.penghao@zte.com.cn> Reviewed-by: Karol Herbst <kherbst@redhat.com> Signed-off-by: Karol Herbst <kherbst@redhat.com> Link: https://patchwork.freedesktop.org/patch/msgid/20210821021447.27097-1-luo.penghao@zte.com.cn
|
#
59f216cf |
|
04-Mar-2021 |
Ben Skeggs <bskeggs@redhat.com> |
drm/nouveau: rip out nvkm_client.super No longer required now that userspace can't touch anything that might need it, and should fix DRM MM operations racing with each other, and the random hangs/crashes that come with that. Signed-off-by: Ben Skeggs <bskeggs@redhat.com> Reviewed-by: Lyude Paul <lyude@redhat.com>
|
#
8f187163 |
|
30-Jun-2021 |
Alistair Popple <apopple@nvidia.com> |
nouveau/svm: implement atomic SVM access Some NVIDIA GPUs do not support direct atomic access to system memory via PCIe. Instead this must be emulated by granting the GPU exclusive access to the memory. This is achieved by replacing CPU page table entries with special swap entries that fault on userspace access. The driver then grants the GPU permission to update the page undergoing atomic access via the GPU page tables. When CPU access to the page is required a CPU fault is raised which calls into the device driver via MMU notifiers to revoke the atomic access. The original page table entries are then restored allowing CPU access to proceed. Link: https://lkml.kernel.org/r/20210616105937.23201-11-apopple@nvidia.com Signed-off-by: Alistair Popple <apopple@nvidia.com> Reviewed-by: Ben Skeggs <bskeggs@redhat.com> Cc: Christoph Hellwig <hch@lst.de> Cc: Hugh Dickins <hughd@google.com> Cc: Jason Gunthorpe <jgg@nvidia.com> Cc: John Hubbard <jhubbard@nvidia.com> Cc: "Matthew Wilcox (Oracle)" <willy@infradead.org> Cc: Peter Xu <peterx@redhat.com> Cc: Ralph Campbell <rcampbell@nvidia.com> Cc: Shakeel Butt <shakeelb@google.com> Signed-off-by: Andrew Morton <akpm@linux-foundation.org> Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
|
#
1a77decd |
|
23-Jul-2020 |
Ralph Campbell <rcampbell@nvidia.com> |
nouveau: fix storing invalid ptes When migrating a range of system memory to device private memory, some of the pages in the address range may not be migrating. In this case, the non migrating pages won't have a new GPU MMU entry to store but the nvif_object_ioctl() NVIF_VMM_V0_PFNMAP method doesn't check the input and stores a bad valid GPU page table entry. Fix this by skipping the invalid input PTEs when updating the GPU page tables. Link: https://lore.kernel.org/r/20200723223004.9586-2-rcampbell@nvidia.com Signed-off-by: Ralph Campbell <rcampbell@nvidia.com> Signed-off-by: Jason Gunthorpe <jgg@nvidia.com>
|
#
7763d24f |
|
30-Jun-2020 |
Ralph Campbell <rcampbell@nvidia.com> |
drm/nouveau/vmm/gp100-: fix mapping 2MB sysmem pages The nvif_object_ioctl() method NVIF_VMM_V0_PFNMAP wasn't correctly setting the hardware specific GPU page table entries for 2MB sized pages. Fix this by adding functions to set and clear PD0 GPU page table entries. Signed-off-by: Ralph Campbell <rcampbell@nvidia.com> Signed-off-by: Ben Skeggs <bskeggs@redhat.com>
|
#
b9f327f1 |
|
09-Jun-2020 |
Ben Skeggs <bskeggs@redhat.com> |
drm/nouveau/mmu/gp100-: enable mmu invalidate depth optimisation This causes us to invalidate MMU only at the level we made modifications - ie: if we've only modified PTEs, there's no need to have MMU dump the PDs it's fetched into L2. Signed-off-by: Ben Skeggs <bskeggs@redhat.com>
|
#
4725c6b8 |
|
01-Jul-2020 |
Ralph Campbell <rcampbell@nvidia.com> |
nouveau: fix mapping 2MB sysmem pages The nvif_object_ioctl() method NVIF_VMM_V0_PFNMAP wasn't correctly setting the hardware specific GPU page table entries for 2MB sized pages. Fix this by adding functions to set and clear PD0 GPU page table entries. Link: https://lore.kernel.org/r/20200701225352.9649-4-rcampbell@nvidia.com Signed-off-by: Ralph Campbell <rcampbell@nvidia.com> Signed-off-by: Jason Gunthorpe <jgg@nvidia.com>
|
#
176ada03 |
|
16-Dec-2019 |
James Jones <jajones@nvidia.com> |
drm/nouveau/mmu: Add correct turing page kinds Turing introduced a new simplified page kind scheme, reducing the number of possible page kinds from 256 to 16. It also is the first NVIDIA GPU in which the highest possible page kind value is not reserved as an "invalid" page kind. To address this, the invalid page kind is made an explicit property of the MMU HAL, and a new table of page kinds is added to the tu102 MMU HAL. One hardware change not addressed here is that 0x00 is technically no longer a supported page kind, and pitch surfaces are instead intended to share the block-linear generic page kind 0x06. However, because that will be a rather invasive change to nouveau and 0x00 still works fine in practice on Turing hardware, addressing this new behavior is deferred. Signed-off-by: James Jones <jajones@nvidia.com> Signed-off-by: Ben Skeggs <bskeggs@redhat.com>
|
#
ab2ee9ff |
|
08-May-2018 |
Ben Skeggs <bskeggs@redhat.com> |
drm/nouveau/mmu/gp100-: support vmms with gcc/tex replayable faults enabled Some GPU units are capable of supporting "replayable" page faults, where the execution unit will wait for SW to fixup GPU page tables rather than triggering a channel-fatal fault. This feature isn't useful (it's harmful, even) unless something like HMM is being used to manage events appearing in the replayable fault buffer, so, it's disabled by default. This commit allows a client to request it be enabled. Signed-off-by: Ben Skeggs <bskeggs@redhat.com>
|
#
71871aa6 |
|
09-Jul-2018 |
Ben Skeggs <bskeggs@redhat.com> |
drm/nouveau/mmu/gp100-: add privileged methods for fault replay/cancel Host methods exist to do at least some of what we need, but we are not currently pushing replay/cancels through a channel like UVM does as it's not clear whether it's necessary in our case (UVM also updates PTEs with the GPU). UVM also pushes a software method for fault cancels on Pascal, seemingly because the host methods don't appear to be sufficient. If/when we want to push the replay/cancel on the GPU, we can re-purpose the cancellation code here to implement that swmthd. Keep it simple for now, until we figure out exactly what we need here. Signed-off-by: Ben Skeggs <bskeggs@redhat.com>
|
#
a5ff307f |
|
06-Jul-2018 |
Ben Skeggs <bskeggs@redhat.com> |
drm/nouveau/mmu: add a privileged method to directly manage PTEs This provides a somewhat more direct method of manipulating the GPU page tables, which will be required to support SVM. Signed-off-by: Ben Skeggs <bskeggs@redhat.com>
|
#
2606f291 |
|
13-Jun-2018 |
Ben Skeggs <bskeggs@redhat.com> |
drm/nouveau/mmu: support initialisation of client-managed address-spaces NVKM is currently responsible for managing the allocation of a client's GPU address-space, but there's various use-cases (ie. HMM address-space mirroring) where giving a client more direct control is desirable. This commit allows for a VMM to be created where the area allocated for NVKM is limited to a client-specified window, the remainder of address- space is controlled directly by the client. Leaving a window is necessary to support various internal requirements, but also to support existing allocation interfaces as not all of the HW is capable of working with a HMM allocation. Signed-off-by: Ben Skeggs <bskeggs@redhat.com>
|
#
d389fd4f |
|
12-Feb-2019 |
Ben Skeggs <bskeggs@redhat.com> |
drm/nouveau/mmu/gf100-: virtualise setting pdb base address for invalidation It appears that Pascal and newer need something different. Signed-off-by: Ben Skeggs <bskeggs@redhat.com>
|
#
874c1b56 |
|
12-Feb-2019 |
Ben Skeggs <bskeggs@redhat.com> |
drm/nouveau/mmu/gf100-: make mmu invalidate function more general Will want to reuse this for fault replay/cancellation swmthds. Signed-off-by: Ben Skeggs <bskeggs@redhat.com>
|
#
f9400afb |
|
31-Oct-2017 |
Ben Skeggs <bskeggs@redhat.com> |
drm/nouveau/mmu/gp100,gp10b: implement new vmm backend Adds support for: - 64KiB/2MiB big page sizes (128KiB not supported by HW with new PT layout). - System-memory PTs. - LPTE "invalid" state. - (Tegra) Use of video memory aperture. - Sparse PDEs/PTEs. - Additional blocklinear kinds. - 49-bit address-space. GP100 supports an entirely new 5-level page table layout that provides an expanded 49-bit address-space. It also supports the layout present on previous generations, which we've been making do with until now. This commit implements support for the new layout, and enables it by default. Signed-off-by: Ben Skeggs <bskeggs@redhat.com>
|
#
8e39abff |
|
31-Oct-2017 |
Ben Skeggs <bskeggs@redhat.com> |
drm/nouveau/mmu/gp100,gp10b: implement vmm on top of new base Adds support for: - Selection of old/new-style page table layout (GP100MmuLayout=0/1). - System-memory PDs. New layout disabled by default for the moment, as we don't have a backend that can handle it yet. Signed-off-by: Ben Skeggs <bskeggs@redhat.com>
|