- 24 Mar, 2021 38 commits
-
-
Maarten Lankhorst authored
vmap is using pin_pages, but needs to use ww locking, add pin_pages_unlocked to correctly lock the mapping. Also add ww locking to begin/end cpu access. Changes since v1: - Fix i915_gem_map_dma_buf by using pin_pages_unlocked(). Signed-off-by:
Maarten Lankhorst <maarten.lankhorst@linux.intel.com> Reviewed-by:
Thomas Hellström <thomas.hellstrom@linux.intel.com> Signed-off-by:
Daniel Vetter <daniel.vetter@ffwll.ch> Link: https://patchwork.freedesktop.org/patch/msgid/20210323155059.628690-38-maarten.lankhorst@linux.intel.com
-
Maarten Lankhorst authored
In the ucode functions, the calls are done before userspace runs, when debugging using debugfs, or when creating semi-permanent mappings; we can safely use the unlocked versions that does the ww dance for us. Because there is no pin_pages_unlocked yet, add it as convenience function. This removes possible lockdep splats about missing resv lock for ucode. Signed-off-by:
-
Maarten Lankhorst authored
We need to lock a few more objects, some temporarily, add ww lock where needed. Signed-off-by:
-
Maarten Lankhorst authored
i915_gem_object_pin_map potentially needs a ww context, so ensure we have one we can revoke. Signed-off-by:
-
Maarten Lankhorst authored
By default, we assume that it's called inside igt_create_request to keep existing selftests working, but allow for manual pinning when passing a ww context. Signed-off-by:
-
Thomas Hellström authored
Stolen objects need to lock, and we may call put_pages when refcount drops to 0, ensure all calls are handled correctly. Changes since v1: - Rebase on top of upstream changes. Idea-from: Thomas Hellström <thomas.hellstrom@intel.com> Signed-off-by:
Matthew Auld <matthew.auld@intel.com> Signed-off-by:
-
Maarten Lankhorst authored
pin_map needs the ww lock, so ensure we pin both before submission. Signed-off-by:
-
Maarten Lankhorst authored
We are removing obj->mm.lock, and need to take the reservation lock before we can pin pages. Move the pinning pages into the helper, and merge gtt pwrite/pread preparation and cleanup paths. The fence lock is also removed; it will conflict with fence annotations, because of memory allocations done when pagefaulting inside copy_*_user. Signed-off-by:
-
Maarten Lankhorst authored
We need to take the obj lock to pin pages, so wait until the callers have done so, before making the object unshrinkable. Signed-off-by:
-
Maarten Lankhorst authored
We need to lock the object to move it to the correct domain, add the missing lock. Signed-off-by:
-
Maarten Lankhorst authored
Take the ww lock around engine_unpark. Because of the many many places where rpm is used, I chose the safest option and used a trylock to opportunistically take this lock for __engine_unpark. Signed-off-by:
-
Maarten Lankhorst authored
Make creation separate from pinning, in order to take the lock only once, and pin the mapping with the lock held. Changes since v1: - Rebase on top of upstream changes. Changes since v2: - Fully clear wa_ctx on error. Signed-off-by:
-
Maarten Lankhorst authored
We previously complained when ww == NULL. This function is now only used in selftests to pin an object, and ww locking is now fixed. Signed-off-by:
-
Maarten Lankhorst authored
This should be done as part of the ww loop, in order to remove a i915_vma_pin that needs ww held. Now only i915_ggtt_pin() callers remaining. Signed-off-by:
-
Maarten Lankhorst authored
Take a simple lock so we hold ww around (un)pin_pages as needed. Signed-off-by:
-
Maarten Lankhorst authored
Instead of multiple lockings, lock the object once, and perform the ww dance around attach_phys and pin_pages. Signed-off-by:
-
Maarten Lankhorst authored
Pin in the caller, not in the work itself. This should also work better for dma-fence annotations. Signed-off-by:
-
Maarten Lankhorst authored
Try to pin to ggtt first, and use a full ww loop to handle eviction correctly. Signed-off-by:
-
Maarten Lankhorst authored
We map the initial context during first pin. This allows us to remove pin_map from state allocation, which saves us a few retry loops. We won't need this until first pin anyway. intel_ring_submission_setup() is also reworked slightly to do all pinning in a single ww loop. Changes since v1: - Handle -EDEADLK backoff in intel_ring_submission_setup() better. - Handle smatch errors reported by Dan and testbot. Signed-off-by:
kernel test robot <lkp@intel.com> Reported-by:
Dan Carpenter <dan.carpenter@oracle.com> Reviewed-by:
-
Maarten Lankhorst authored
This allows us to remove pin_map from state allocation, which saves us a few retry loops. We won't need this until first pin, anyway. Signed-off-by:
-
Maarten Lankhorst authored
With userptr fixed, there is no need for all separate lockdep classes now, and we can remove all lockdep tricks used. A trylock in the shrinker is all we need now to flatten the locking hierarchy. Signed-off-by:
-
Maarten Lankhorst authored
Instead of doing what we do currently, which will never work with PROVE_LOCKING, do the same as AMD does, and something similar to relocation slowpath. When all locks are dropped, we acquire the pages for pinning. When the locks are taken, we transfer those pages in .get_pages() to the bo. As a final check before installing the fences, we ensure that the mmu notifier was not called; if it is, we return -EAGAIN to userspace to signal it has to start over. Changes since v1: - Unbinding is done in submit_init only. submit_begin() removed. - MMU_NOTFIER -> MMU_NOTIFIER Changes since v2: - Make i915->mm.notifier a spinlock. Changes since v3: - Add WARN_ON if there are any page references left, should have been 0. - Return 0 on success in submit_init(), bug from spinlock conversion. - Release pvec outside of notifier_lock (Thomas). Changes since v4: - Mention why we're clearing eb->[i + 1].vma in the code. (Thomas) - Actually check all invalidations in eb_move_to_gpu. (Thomas) - Do not wait when process is exiting to fix gem_ctx_persistence.userptr. Changes since v5: - Clarify why check on PF_EXITING is (temporarily) required. Changes since v6: - Ensure userptr validity is checked in set_domain through a special path. Signed-off-by:
Dave Airlie <airlied@redhat.com> [danvet: s/kfree/kvfree/ in i915_gem_object_userptr_drop_ref in the previous review round, but which got lost. The other open questions around page refcount are imo better discussed in a separate series, with amdgpu folks involved]. Reviewed-by:
-
Maarten Lankhorst authored
Now that unsynchronized mappings are removed, the only time userptr works is when the MMU notifier is enabled. Put all of the userptr code behind a mmu notifier ifdef. Signed-off-by:
-
Maarten Lankhorst authored
We should not allow this any more, as it will break with the new userptr implementation, it could still be made to work, but there's no point in doing so. Inspection of the beignet opencl driver shows that it's only used when normal userptr is not available, which means for new kernels you will need CONFIG_I915_USERPTR. Signed-off-by:
Jason Ekstrand <jason@jlekstrand.net> Signed-off-by:
-
Maarten Lankhorst authored
There are a couple of ioctl's related to tiling and cache placement, that make no sense for userptr, reject those: - i915_gem_set_tiling_ioctl() Tiling should always be linear for userptr. Changing placement will fail with -ENXIO. - i915_gem_set_caching_ioctl() Userptr memory should always be cached. Changing caching mode will fail with -ENXIO. - i915_gem_set_domain_ioctl() Still temporarily allowed to work as intended, it's used to check userptr validity. With the reworked userptr code, it will keep working for this usecase. This plus the previous changes have been tested against beignet by using its own unit tests, and intel-video-compute by using piglit's opencl tests. Changes since v1: - set_domain was apparently used in iris for checking userptr validity, keep it working as intended. Signed-off-by: -
Maarten Lankhorst authored
It doesn't make sense to export a memory address, we will prevent allowing access this way to different address spaces when we rework userptr handling, so best to explicitly disable it. Signed-off-by:
-
Maarten Lankhorst authored
Userptr should not need the kernel for a userspace memcpy, userspace needs to call memcpy directly. Specifically, disable i915_gem_pwrite_ioctl() and i915_gem_pread_ioctl(). Signed-off-by:
-
Maarten Lankhorst authored
As soon as we install fences, we should stop allocating memory in order to prevent any potential deadlocks. This is required later on, when we start adding support for dma-fence annotations. Signed-off-by:
-
Maarten Lankhorst authored
Simple adding of i915_gem_object_lock, we may start to pass ww to get_pages() in the future, but that won't be the case here; We override shmem's get_pages() handling by calling i915_gem_object_get_pages_phys(), no ww is needed. Changes since v1: - Call shmem put pages directly, the callback would go down the phys free path. Signed-off-by:
-
Maarten Lankhorst authored
Instead of creating a separate object type, we make changes to the shmem type, to clear struct page backing. This will allow us to ensure we never run into a race when we exchange obj->ops with other function pointers. Signed-off-by:
-
Maarten Lankhorst authored
We want to remove the changing of ops structure for attaching phys pages, so we need to kill off HAS_STRUCT_PAGE from ops->flags, and put it in the bo. This will remove a potential race of dereferencing the wrong obj->ops without ww mutex held. Signed-off-by:
-
Maarten Lankhorst authored
Doesn't need the full ww lock, only checking if pages are bound. Signed-off-by:
-
Maarten Lankhorst authored
Currently we have a lot of places where we hold the gem object lock, but haven't yet been converted to the ww dance. Complain loudly about those places. i915_vma_pin shouldn't have the obj lock held, so we can do a ww dance, while i915_vma_pin_ww should. Signed-off-by:
-
Maarten Lankhorst authored
i915_vma_pin may fail with -EDEADLK when we start locking page tables, so ensure we handle this correctly. Changes since v1: - Drop -EDEADLK todo, this commit handles it. - Change eb_pin_vma from sort-of-bool + -EDEADLK to a proper int. (Matt) Cc: Matthew Brost <matthew.brost@intel.com> Signed-off-by:
-
Maarten Lankhorst authored
We need to get rid of allocations in the cmd parser, because it needs to be called from a signaling context, first move all pinning to execbuf, where we already hold all locks. Allocate jump_whitelist in the execbuffer, and add annotations around intel_engine_cmd_parser(), to ensure we only call the command parser without allocating any memory, or taking any locks we're not supposed to. Because i915_gem_object_get_page() may also allocate memory, add a path to i915_gem_object_get_sg() that prevents memory allocations, and walk the sg list manually. It should be similarly fast. This has the added benefit of being able to catch all memory allocation errors before the point of no return, and return -ENOMEM safely to the execbuf submitter. Signed-off-by:
-
Maarten Lankhorst authored
We're starting to require the reservation lock for pinning, so wait until we have that. Update the selftests to handle this correctly, and ensure pin is called in live_hwsp_rollover_user() and mock_hwsp_freelist(). Changes since v1: - Fix NULL + XX arithmatic, use casts. (kbuild) Changes since v2: - Clear entire cacheline when pinning. Changes since v3: - CACHELINE_BYTES -> TIMELINE_SEQNO_BYTES. (jekstrand) Signed-off-by:
-
Maarten Lankhorst authored
Instead of sharing pages with breadcrumbs, give each timeline a single page. This allows unrelated timelines not to share locks any more during command submission. As an additional benefit, seqno wraparound no longer requires i915_vma_pin, which means we no longer need to worry about a potential -EDEADLK at a point where we are ready to submit. Changes since v1: - Fix erroneous i915_vma_acquire that should be a i915_vma_release (ickle). - Extra check for completion in intel_read_hwsp(). Changes since v2: - Fix inconsistent indent in hwsp_alloc() (kbuild) - memset entire cacheline to 0. Changes since v3: - Do same in intel_timeline_reset_seqno(), and clflush for good measure. Changes since v4: - Use refcounting on timeline, instead of relying on i915_active. - Fix waiting on kernel requests. Changes since v5: - Bump amount of slots to maximum (256), for best wraparounds. - Add hwsp_offset to i915_request to fix potential wraparound hang. - Ensure timeline wrap test works with the changes. - Assign hwsp in intel_timeline_read_hwsp() within the rcu lock to fix a hang. Changes since v6: - Rename i915_request_active_offset to i915_request_active_seqno(), and elaborate the function. (tvrtko) Changes since v7: - Move hunk to where it belongs. (jekstrand) - Replace CACHELINE_BYTES with TIMELINE_SEQNO_BYTES. (jekstrand) Signed-off-by:
-
Liam Howlett authored
Use i915 prefix to avoid name collision with future vma_lookup() in mm. Signed-off-by:
Liam R. Howlett <Liam.Howlett@Oracle.com> Reviewed-by:
Matthew Wilcox (Oracle) <willy@infradead.org> Signed-off-by:
-
- 18 Mar, 2021 2 commits
-
-
Ashutosh Dixit authored
The rationale for this change is roughly as follows: 1. The functionality can be done entirely in userspace with a combination of mmap + memcpy 2. The only reason anyone in userspace is still using it is because someone implemented bo_subdata that way in libdrm ages ago and they're all too lazy to write the 5 lines of code to do a map. 3. This falls cleanly into the category of things which will only get more painful with local memory support. These ioctls aren't used much anymore by "real" userspace drivers. Vulkan has never used them and neither has the iris GL driver. The old i965 GL driver does use PWRITE for glBufferSubData but it only supports up through Gen11; Gen12 was never enabled in i965. The compute driver has never used PREAD/PWRITE. The only remaining user is the media driver which uses it exactly twice and they're easily removed [1] so expecting them to drop it going forward is reasonable. IGT changes which handle this kernel change have also been submitted [2]. [1] https://github.com/intel/media-driver/pull/1160 [2] https://patchwork.freedesktop.org/series/81384/ v2 (Jason Ekstrand): - Improved commit message with the status of all usermode drivers - A more future-proof platform check v3 (Jason Ekstrand): - Drop the HAS_LMEM checks as they're already covered by the version checks Signed-off-by:Ashutosh Dixit <ashutosh.dixit@intel.com> Signed-off-by:
-
Jason Ekstrand authored
The Vulkan driver in Mesa for Intel hardware never uses relocations if it's running on a version of i915 that supports at least softpin which all versions of i915 supporting Gen12 do. On the OpenGL side, Gen12+ is only supported by iris which never uses relocations. The older i965 driver in Mesa does use relocations but it only supports Intel hardware through Gen11 and has been deprecated for all hardware Gen9+. The compute driver also never uses relocations. This only leaves the media driver which is supposed to be switching to softpin going forward. Making softpin a requirement for all future hardware seems reasonable. There is one piece of hardware enabled by default in i915: RKL which was enabled by e22fa6f0 which has not yet landed in drm-next so this almost but not really a userspace API change for RKL. If it becomes a problem, we can always add !IS_ROCKETLAKE(eb->i915) to the condition. Rejecting relocations starting with newer Gen12 platforms has the benefit that we don't have to bother supporting it on platforms with local memory. Given how much CPU touching of memory is required for relocations, not having to do so on platforms where not all memory is directly CPU-accessible carries significant advantages. v2 (Jason Ekstrand): - Allow TGL-LP platforms as they've already shipped v3 (Jason Ekstrand): - WARN_ON platforms with LMEM support in case the check is wrong v4 (Jason Ekstrand): - Call out Rocket Lake in the commit message v5 (Jason Ekstrand): - Drop the HAS_LMEM check as it's already covered by the version check v6 (Jason Ekstrand): - Move the check to eb_validate_vma() with all the other exec_object validation checks. Signed-off-by:
Zbigniew Kempczyński <zbigniew.kempczynski@intel.com> Reviewed-by:
-
