- 21 Dec, 2023 40 commits
-
-
Zbigniew Kempczyński authored
Using jiffies as a timeout from userspace is weird even if theoretically exists possiblity of acquiring jiffies via getconf. Unfortunately this method is unreliable and the returned value may vary from the one configured in the kernel config. Now timeout is expressed in nanoseconds and its interpretation depends on setting DRM_XE_UFENCE_WAIT_ABSTIME flag. Relative timeout (flag is not set) means fence expire at now() + timeout. Absolute timeout (flag is set) means that the fence expires at exact point of time. Passing negative timeout means we will wait "forever" by setting wait time to MAX_SCHEDULE_TIMEOUT. Cc: Andi Shyti <andi.shyti@linux.intel.com> Reviewed-by:
Andi Shyti <andi.shyti@linux.intel.com> Link: https://lore.kernel.org/r/20230628055141.398036-2-zbigniew.kempczynski@intel.comSigned-off-by:
Zbigniew Kempczyński <zbigniew.kempczynski@intel.com> Signed-off-by:
Rodrigo Vivi <rodrigo.vivi@intel.com>
-
Paulo Zanoni authored
If !no_engines, then we use copy_from_user to copy to the 'eci' array, which has XE_HW_ENGINE_MAX_INSTANCE members. The amount of members copied is given by the user in args->num_engines, so add code to check that args->num_engines does not exceed XE_HW_ENGINE_MAX_INSTANCE. It's an unsigned value so there's no need to check for negative values. Fixes error messages such as: Buffer overflow detected (54 < 18446744073709551520)! Reviewed-by:José Roberto de Souza <jose.souza@intel.com> Signed-off-by:
Paulo Zanoni <paulo.r.zanoni@intel.com> Reviewed-by:
Lucas De Marchi <lucas.demarchi@intel.com> Link: https://lore.kernel.org/r/20230626212221.136640-2-paulo.r.zanoni@intel.comSigned-off-by:
-
Paulo Zanoni authored
There's this shared machine running xe.ko and I often log in to see my tmux corrupted by messages such as: usercopy: Kernel memory overwrite attempt detected to wrapped address (offset 0, size 18446660151965198754)! I also sometimes see: kernel BUG at mm/usercopy.c:102! Someone is running a program that's definitely submitting random numbers to this ioctl. If you pass width=65535 and num_placements=32769 then you get a negative 'len', which avoids the EINVAL check, leading to the bug. Switch 'len' to u32. It is the result of the multiplication of two u16 numbers, so it won't be able to overflow back into smaller numbers as an u32. v2: Make len u32 instead of checking for <=0 (José). Signed-off-by:Matthew Brost <matthew.brost@intel.com> Reviewed-by:
-
Daniele Ceraolo Spurio authored
The SLPC code has a strict 5ms timeout from when the start command is queued to when we expect the reply to appear in memory. This works if the CT channel is empty, but if the channel is busy there might be an extra delay that causes the process to exceeded the timeout. We see this issue when a reset occurs while userspace keeps submitting, because the submission code is re-enabled first and it will start using the channel to service those submissions. To fix this, we can simply start SLPC before re-enabling submission. This has also the benefit of not allowing submissions to go through with an uninitialized SLPC. Link: https://gitlab.freedesktop.org/drm/xe/kernel/-/issues/375Signed-off-by:
Daniele Ceraolo Spurio <daniele.ceraolospurio@intel.com> Cc: Vinay Belgaumkar <vinay.belgaumkar@intel.com> Cc: Matthew Brost <matthew.brost@intel.com> Reviewed-by:
Vinay Belgaumkar <vinay.belgaumkar@intel.com> Reviewed-by:
-
Daniele Ceraolo Spurio authored
The firmware definitions must be ordered based on platform, from newer to older, which means that the DG1 FW must come before the ADL one. Link: https://gitlab.freedesktop.org/drm/intel/-/issues/8699Signed-off-by:
-
Anusha Srivatsa authored
With the fake device creation fix in the previous patch, adding Alderlake P platform in xe_wa_test. With this, driver is able to run the kunit test for ADLP properly. Cc: Lucas De Marchi <lucas.demarchi@intel.com> Signed-off-by:
Anusha Srivatsa <anusha.srivatsa@intel.com> Reviewed-by:
-
Anusha Srivatsa authored
For platform like Alderlake P there are subplatforms and just Alderlake P. Unlike DG2 in which every flavour is either a G10,G11 or G12 variant. In this case(Alderlake P/S), the Kunit test evaluates the subplatform to NONE and is unable to create a fake device. Removing the condition in xe_pci_fake_device_init() to support this corner case so driver can proceed with the unit testing. Cc: Lucas De Marchi <lucas.demarchi@intel.com> Signed-off-by:
-
Anshuman Gupta authored
Intel Discrete GFX cards gfx may have multiple PCIe endpoints, they connects to root port via pcie upstream switch port(USP) and virtual pcie switch port(VSP), sometimes VSP pcie devices doesn't bind to pcieport driver. Without pcieport driver, pcie PM comes without any warranty and with unbounded VSP gfx card won't transition to low power pcie Device and Link states therefore assert drm_warn on unbounded VSP and disable xe driver PM support. v2: - Disable Xe PCI PM support. [Rodrigo] v3: - Changed subject and Rebase. v4: - %s/xe_pci_unbounded_bridge_disable_pm/xe_assert_on_unbounded_bridge. [Rodrigo] - Use device_set_pm_not_required() instead of dev_pm_ops NULL assignment. Cc: Rodrigo Vivi <rodrigo.vivi@intel.com> Signed-off-by:
Anshuman Gupta <anshuman.gupta@intel.com> Reviewed-by:
-
Thomas Hellström authored
Fix a race in xe_vm_lookup() where the vm could disappear after the lookup mutex unlock but before the get. The xe_vm_get() call must be inside the lookup mutex. Also fix a vm close race where multiple callers could potentially succeed in calling xe_vm_close_and_put(). Reported-by:
Oded Gabbay <ogabbay@kernel.org> Link: https://lists.freedesktop.org/archives/intel-xe/2023-May/004704.htmlSigned-off-by:
Thomas Hellström <thomas.hellstrom@linux.intel.com> Reviewed-by:
-
Thomas Hellström authored
The main difference is that we don't bounce and sync on eviction, allowing for pipelined eviction. Moving forward we also need to be careful with dma mappings which can be released in SYSTEM but may remain in TT. v2: - Remove a stale comment (Matthew Brost) Signed-off-by:
-
Thomas Hellström authored
The function ttm_bo_move_accel_cleanup() attempts to help pipeline a move, and in doing so, needs memory allocations which may fail. Rather than failing in a state where the new resource may freed while accessed by the copy engine, sync uninterruptible and do a failsafe cleanup. v2: - Don't try to attach the signaled fence on ttm_bo_move_accel_cleanup() error. Signed-off-by:
Matthew Auld <matthew.auld@intel.com> Reviewed-by:
-
Thomas Hellström authored
When creating a new bo, on the first move the bo->resource is typically NULL. Our move callback rejected that instructing TTM to create a system resource. In addition a struct ttm_tt with a page-vector was created, although not populated with pages. Similarly when the clearing of VRAM was complete, the system resource was put on a ghost object and freed using the TTM delayed destroy mechanism. This is a lot of pointless work. So avoid creating the system resource and instead change the code to cope with a NULL bo->resource. v2: - Add some code comments (Matthew Brost) v3: - Fix a dereference of old_mem which might be NULL. Signed-off-by:
-
Thomas Hellström authored
When a source system resource had been swapped out, we incorrectly assumed that we were lacking source data for a move and therefore cleared the destination instead of swapping in and copying the swapped-out data. Fix this. Signed-off-by:
-
Badal Nilawar authored
Add the registers to get C6 residency of MTL SAMedia and C6 status of MTL gts v2: - move register definitions to regs header (Anshuman) - correct reg definition for mtl rc status - make idle_status function common (Badal) v3: - remove extra line in commit message - use only media type check in initialization - use graphics ver check (Anshuman) v4: - remove extra lines (Anshuman) Bspec: 66300 Signed-off-by:
Badal Nilawar <badal.nilawar@intel.com> Signed-off-by:
Riana Tauro <riana.tauro@intel.com> Reviewed-by:
-
Riana Tauro authored
1) Add a new sysfs directory under devices/gt#/ called gtidle to contain idle properties of GT such as name, idle_status, idle_residency_ms 2) Remove forcewake calls for residency counter v2: - abstract using function pointers (Anshuman) - remove forcewake calls for residency counter - use device_attr (Badal) - move rc functions to guc_pc - change name to gt_idle (Rodrigo) v3: - return error for drmm_add_action_or_reset - replace file and functions with gt_idle prefix to gt_idle_sysfs (Himal) - use enum for gt idle state - move multiplier to gt idle and initialize (Anshuman) - correct doc annotation (Rodrigo) - remove return variable - use kobj_gt instead of new gtidle kobj - move residency_ms to gtidle file - retain xe_guc_pc prefix for functions in guc_rc file (Michal) v4: - fix doc errors in xe_guc_pc file - change u64 to u32 for reading residency counter - keep gtidle states generic GT_IDLE_C[0/6] (Anshuman) v5: - update commit message to include removal of forcewake calls (Anshuman) - return void from sysfs initialization function and add warnings (Andi) v6: - remove extra lines (Anshuman) Signed-off-by: -
Matthew Auld authored
For VRAM allocations the bo->flags can control some characteristics of the underlying memory, like whether it needs to be contiguous, and in the future whether it needs to be in the CPU visible portion. Rather use add_vram() in xe_bo_migrate() which should take care of such things for us. Signed-off-by:
-
Matthew Auld authored
Make sure the uapi gets picked up by the normal docs build. Signed-off-by:
Francois Dugast <francois.dugast@intel.com> Signed-off-by:
-
Matthew Auld authored
./include/uapi/drm/xe_drm.h:263: warning: Function parameter or member 'gts' not described in 'drm_xe_query_gts' ./include/uapi/drm/xe_drm.h:854: WARNING: Inline emphasis start-string without end-string. With the idea to also include the uapi file in the pre-merge CI hooks when building the kernel-doc, so first make sure it's clean: https://gitlab.freedesktop.org/drm/xe/ci/-/merge_requests/16 v2: (Francois) - It makes more sense to just fix the kernel-doc for 'gts' Signed-off-by:
-
Matthew Auld authored
Since we need to extend this, we should also take the time to add some basic kernel-doc here for the existing bits. Note that this is all still subject to change when upstreaming. Also convert XE_MEM_REGION_CLASS_* into an enum, so we can more easily create links to it from other parts of the uapi. Suggested-by:
Gwan-gyeong Mun <gwan-gyeong.mun@intel.com> Signed-off-by:
-
Matthew Auld authored
Since this is considered an info leak (system wide accounting), rather hide behind perfmon_capable(). v2: - Without perfmon_capable() it likely makes more sense to report as zero, instead of reporting as used == total size. This should give similar behaviour as i915 which rather tracks free instead of used. Signed-off-by: -
Francois Dugast authored
Provide information on the types of topology masks that can be queried and add some examples. Signed-off-by:
-
Francois Dugast authored
Align on same rule in the whole file: defines then doc then relevant field, with an empty line to separate fields. v2: - Rebase on drm-xe-next - Fix ordering of defines and fields in uAPI (Lucas De Marchi) v3: Remove useless empty lines (Lucas De Marchi) v4: Move changelog to commit v5: Rebase Reported-by:
-
Francois Dugast authored
This adds documentation to the various structures used to query memory, GTs, topology, engines, and so on. It includes a functional code snippet to query engines. v2: - Rebase on drm-xe-next - Also document structures related to drm_xe_device_query, changed pseudo code to snippet (Lucas De Marchi) v3: - Move changelog to commit - Fix warnings showed only using dim checkpath Reported-by: -
Mika Kuoppala authored
The engine xarray holds a ref to engine, guarded by the lock. While we do lookup for engine, we need to take the ref inside the lock to prevent unreffed pointer escaping and causing potential use-after-free after. v2: remove branch prediction hint (Thomas) Cc: Thomas Hellström <thomas.hellstrom@linux.intel.com> Signed-off-by:
Mika Kuoppala <mika.kuoppala@linux.intel.com> Reviewed-by:
-
Lucas De Marchi authored
Like commit 69a3738b ("drm/i915: Skip applying copy engine fuses"), do not apply copy engine fuses for platforms where MEML3_EN is not relevant for determining the presence of the copy engines. Acked-by:
Gustavo Sousa <gustavo.sousa@intel.com> Reviewed-by:
Matt Roper <matthew.d.roper@intel.com> Link: https://lore.kernel.org/r/20230613180356.2906441-1-lucas.demarchi@intel.comSigned-off-by:
-
Matthew Auld authored
When moving between PL_VRAM <-> PL_SYSTEM we have to have use PL_TT in the middle as a temporary resource for the actual copy. In some GL workloads it can be seen that once the resource has been moved to the PL_TT we might have to bail out of the ttm_bo_validate(), before finishing the final hop. If this happens the resource is left as TTM_PL_FLAG_TEMPORARY, and when the ttm_bo_validate() is restarted the current placement is always seen as incompatible, requiring us to complete the move. However if the BO allows PL_TT as a possible placement we can end up attempting a PL_TT -> PL_TT move (like when running out of VRAM) which leads to explosions in xe_bo_move(), like triggering the XE_BUG_ON(!tile). Going from TTM_PL_FLAG_TEMPORARY with PL_TT -> PL_VRAM should already work as-is, so it looks like we only need to worry about PL_TT -> PL_TT and it looks like we can just treat it as a dummy move, since no real move is needed. Reported-by:
-
Matthew Brost authored
Use the TTM LRU bulk move for BOs tied to a VM. Update the bulk moves LRU position on every exec. v2: Bulk move for compute VMs, use WARN rather than BUG Reviewed-by:
-
Matthew Brost authored
We only need to try to lock a BO if it's external as non-external BOs share the dma-resv with the already locked VM. Trying to lock non-external BOs caused an issue (list corruption) in an uncoming patch which adds bulk LRU move. Since this code isn't needed, remove it. v2: New commit message, s/mattthew/matthew/ Reviewed-by:
-
Matthew Brost authored
With our ref counting scheme long running (LR) engines only close properly if not persistent, ensure that LR engines are non-persistent. v2: spell out LR Signed-off-by:
-
Matthew Brost authored
For long running (LR) jobs with the DRM scheduler we must return NULL in run_job which results in signaling the job's finished fence immediately. This prevents LR jobs from creating infinite dma-fences. Signaling job's finished fence immediately breaks flow controlling ring with the DRM scheduler. To work around this, the ring is flow controlled and written in the exec IOCTL. Signaling job's finished fence immediately also breaks the TDR which is used in reset / cleanup entity paths so write a new path for LR entities. v2: Better commit, white space, remove rmb(), better comment next to emit_job() v3 (Thomas): Change LR reference counting, fix working in commit Reviewed-by:
-
Matthew Brost authored
Add uAPI and implementation for NULL bindings. A NULL binding is defined as writes dropped and read zero. A single bit in the uAPI has been added which results in a single bit in the PTEs being set. NULL bindings are intendedd to be used to implement VK sparse bindings, in particular residencyNonResidentStrict property. v2: Fix BUG_ON shown in VK testing, fix check patch warning, fix xe_pt_scan_64K, update __gen8_pte_encode to understand NULL bindings, remove else if vma_addr Reviewed-by:
-
Janga Rahul Kumar authored
ENOTSUPP is not a standard Unix error should use EOPNOTSUPP instead. v2: Update commit description (Aravind) Reviewed-by:
Aravind Iddamsetty <aravind.iddamsetty@intel.com> Signed-off-by:
Janga Rahul Kumar <janga.rahul.kumar@intel.com> Signed-off-by:
-
Daniele Ceraolo Spurio authored
The GuC can't access addresses above GUC_GGTT_TOP, so any GuC-accessible objects can't be mapped above that offset. Instead of checking each object to see if GuC may access it or not before mapping it, we just limit the GGTT size to GUC_GGTT_TOP. This wastes a bit of address space (about ~18 MBs, which is in addition to what already removed at the bottom of the GGTT), but it is a good tradeoff to keep the code simple. The in-code comment has also been updated to explain the limitation. Signed-off-by:
-
Matt Roper authored
This adds a handful of workarounds that apply to production steppings of MTL: - Wa_14018575942 - Wa_22016670082 - Wa_14017856879 - Wa_18019271663 Wa_22016670082 is currently only applied to the primary GT at the moment, but may need to be extended to the media GT in the future if a pending update to the workaround database gets finalized. OOB workarounds will need to be implemented separately in future patches for Wa_14016712196, Wa_16018063123, and Wa_18013179988. Reviewed-by:
Radhakrishna Sripada <radhakrishna.sripada@intel.com> Link: https://lore.kernel.org/r/20230608181217.2385932-1-matthew.d.roper@intel.comSigned-off-by:
-
Michał Winiarski authored
It's not possible for the condition checking if we're running on platform without geometry pipeline to ever be true, since gt->fuse_topo.g_dss_mask is an array. It also breaks the build: ../drivers/gpu/drm/xe/xe_rtp.c:183:50: error: address of array 'gt->fuse_topo.g_dss_mask' will always evaluate to 'true' [-Werror,-Wpointer-bool-conversion] Signed-off-by:
Michał Winiarski <michal.winiarski@intel.com> Reviewed-by:
-
Michał Winiarski authored
Using uninitialized variables leads to undefined behavior. Moreover, it causes the compiler to complain with: ../drivers/gpu/drm/xe/xe_vm.c:3265:40: error: variable 'vma' is uninitialized when used here [-Werror,-Wuninitialized] ../drivers/gpu/drm/xe/xe_rtp.c:118:36: error: variable 'i' is uninitialized when used here [-Werror,-Wuninitialized] ../drivers/gpu/drm/xe/xe_mocs.c:449:3: error: variable 'flags' is uninitialized when used here [-Werror,-Wuninitialized] Signed-off-by:
-
Riana Tauro authored
gt_count is only being incremented when initializing the primary GT; since the media GT sets the ID directly, gt_count is not incremented again, resulting in an incorrect count on MTL. Use autoincrement while assigning the media GTs ID to ensure gt_count is correct on MTL and other future platforms with standalone media. Signed-off-by:
-
Badal Nilawar authored
RPSTAT1 is an sgunit register and thus doesn't need forcewake. MTL_MIRROR_TARGET_WP1 is within an "always on" power domain and thus doesn't require any forcewake to ensure the register is powered up and usable. When GT is RC6 the actual frequency reported will be 0. v2: - Add bspec index (Anshuman) - %s/GEN12_RPSTAT1/GT_PERF_STATUS as per bspec v3: Update Fixes tag Bspec: 51837, 67651 Fixes: dd08ebf6 ("drm/xe: Introduce a new DRM driver for Intel GPUs") Signed-off-by:
-
Lucas De Marchi authored
One of the messages was printed without 0x prefix, so it was not clear if it was decimal or hex: make sure to add the prefix by using %#x. While at it, normalize the other messages in the same function to follow the same pattern. Reviewed-by:
-
Lucas De Marchi authored
Fix the log message when it fails to enable CT. Reviewed-by:
-
