- 28 Feb, 2024 2 commits
-
-
Mika Kuoppala authored
If user fence was provided for MAP in vm_bind_ioctl and it has still not been signalled, deny UNMAP of said vma with EBUSY as long as unsignalled fence exists. This guarantees that MAP vs UNMAP sequences won't escape under the radar if we ever want to track the client's state wrt to completed and accessible MAPs. By means of intercepting the ufence release signalling. v2: find ufence with num_fences > 1 (Matt) v3: careful on clearing vma ufence (Matt) Link: https://gitlab.freedesktop.org/drm/xe/kernel/-/issues/1159 Cc: Thomas Hellström <thomas.hellstrom@linux.intel.com> Cc: Matthew Brost <matthew.brost@intel.com> Cc: Joonas Lahtinen <joonas.lahtinen@linux.intel.com> Signed-off-by:
Mika Kuoppala <mika.kuoppala@linux.intel.com> Reviewed-by:
Matthew Brost <matthew.brost@intel.com> Signed-off-by:
Thomas Hellström <thomas.hellstrom@linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20240215181152.450082-3-mika.kuoppala@linux.intel.com
-
Mika Kuoppala authored
By allowing getting reference to user fence, we can control the lifetime outside of sync entries. This is needed to allow vma to track the associated user fence that was provided with bind ioctl. v2: xe_user_fence can be kept opaque (Jani, Matt) v3: indent fix (Matt) Cc: Thomas Hellström <thomas.hellstrom@linux.intel.com> Cc: Matthew Brost <matthew.brost@intel.com> Cc: Jani Nikula <jani.nikula@linux.intel.com> Signed-off-by:
-
- 26 Feb, 2024 18 commits
-
-
Matthew Brost authored
Timing out of signaled jobs can happen during regular operations (e.g. an exec queue closed immediately after last fence signaled). The TDR can pass the worker which free jobs. Rather than running through the TDR if signaled job is found, simply free it without any debug messages. Cc: Thomas Hellström <thomas.hellstrom@linux.intel.com> Reported-by:
José Roberto de Souza <jose.souza@intel.com> Closes: https://gitlab.freedesktop.org/drm/xe/kernel/-/issues/1271Signed-off-by:
-
Paulo Zanoni authored
Mesa has been issuing a single bind operation per ioctl since xe.ko changed to GPUVA due xe.ko bug #746. If I change Mesa to try again to issue every single bind operation it can in the same ioctl, it hits the MAX_BINDS assertion when running Vulkan conformance tests. Test dEQP-VK.sparse_resources.transfer_queue.3d.rgba32i.1024_128_8 issues 960 bind operations in a single ioctl, it's the most I could find in the conformance suite. I don't see a reason to keep the MAX_BINDS restriction: it doesn't seem to be preventing any specific issue. If the number is too big for the memory allocations, then those will fail. Nothing related to num_binds seems to be using the stack. Let's just get rid of it. Fixes: dd08ebf6 ("drm/xe: Introduce a new DRM driver for Intel GPUs") Testcase: dEQP-VK.sparse_resources.transfer_queue.3d.rgba32i.1024_128_8 References: https://gitlab.freedesktop.org/drm/xe/kernel/-/issues/746 Cc: Matthew Brost <matthew.brost@intel.com> Signed-off-by:
Paulo Zanoni <paulo.r.zanoni@intel.com> Reviewed-by:
-
Matthew Brost authored
Use vmalloc in effort to allow a user pass in a large number of binds in an IOCTL (mesa use case). Also use array allocations rather open coding the size calculation. v2: Use __GFP_ACCOUNT for allocations (Thomas) Fixes: dd08ebf6 ("drm/xe: Introduce a new DRM driver for Intel GPUs") Signed-off-by:
-
Francois Dugast authored
The infrastructure to query GuC firmware version is already in place. It is extended with a new micro-controller type to query the HuC firmware version. It can be used from user space to know if HuC is running. Cc: John Harrison <John.C.Harrison@Intel.com> Cc: Francois Dugast <francois.dugast@intel.com> Cc: Lucas De Marchi <lucas.demarchi@intel.com> Signed-off-by:
Francois Dugast <francois.dugast@intel.com> Signed-off-by:
Rodrigo Vivi <rodrigo.vivi@intel.com> Reviewed-by:
John Harrison <John.C.Harrison@Intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20240208183539.185095-2-jose.souza@intel.com
-
Rodrigo Vivi authored
PAT dumps are already protected by the xe_pm_runtime_{get,put} around the debugfs call. So, these can be removed. Reviewed-by:Matthew Auld <matthew.auld@intel.com> Signed-off-by:
-
Rodrigo Vivi authored
We need to ensure that device is in D0 on any kind of GT reset. We are likely already protected by outer bounds like exec, but if exec/sched ref gets dropped on a hang, we might transition to D3 before we are able to perform the gt_reset and recover. Suggested-by:
-
Rodrigo Vivi authored
At these points, we are sure that device is awake in D0. Likely in the middle of the transition, but awake. So, these extra protections are useless. Let's remove it and continue with the killing of xe_device_mem_access. Reviewed-by:
-
Rodrigo Vivi authored
Let's directly use xe_pm_runtime_{get,put} instead of the mem_access helpers that are going away soon. Reviewed-by: -
Rodrigo Vivi authored
Every IOCTL is already protected on its outer bounds by xe_pm_runtime_{get,put} calls, so we can now remove these. Reviewed-by: -
Rodrigo Vivi authored
Continue the work to kill the mem_access in favor of a pure runtime pm. Reviewed-by:
-
Rodrigo Vivi authored
Continue on the path to entirely remove mem_access helpers in favour of the direct xe_pm_runtime calls. This item is one of the direct outer bounds of the protection. Reviewed-by:
-
Rodrigo Vivi authored
Let's ensure our PCI device is awaken on every debugfs call. Let's increase the runtime_pm protection and start moving that to the outer bounds. Also let's remove the mem_access_{get,put} from where they are not needed anymore. Reviewed-by: -
Rodrigo Vivi authored
We are now protected by init, sysfs, or removal and don't need these mem_access protections around GuC_PC anymore. Reviewed-by:
-
Rodrigo Vivi authored
Let's ensure our PCI device is awaken on every sysfs call. Let's increase the runtime_pm protection and start moving that to the outer bounds. For now, for the files with small number of attr functions, let's only call the runtime pm functions directly. For the hw_engines entries with many files, let's add the sysfs_ops wrapper. Reviewed-by:
-
Rodrigo Vivi authored
Let's convert the kunit tests that are currently relying on xe_device_mem_access_{get,put} towards the direct xe_pm_runtime_{get,put}. While doing this we need to move the get/put calls towards the outer bounds of the tests to ensure consistency with the other usages of pm_runtime on the regular paths. v2: include xe_pm.h in tests/xe_mocs.c and sort the include block while at it. Reviewed-by: -
Rodrigo Vivi authored
Let's ensure our PCI device is awaken on every IOCTL entry. Let's increase the runtime_pm protection and start moving that to the outer bounds. v2: minor typo fix and renaming function to make it clear that is intended to be used by ioctl only. (Matt) v3: Make it NULL if CONFIG_COMPAT is not selected. Cc: Matthew Auld <matthew.auld@intel.com> Reviewed-by: -
Rodrigo Vivi authored
The mem_access helpers are going away and getting replaced by direct calls of the xe_pm_runtime_{get,put} functions. However, an assertion with a warning splat is desired when we hit the worst case of a memory access with the device really in the 'suspended' state. Also, this needs to be the first step. Otherwise, the upcoming conversion would be really noise with warn splats of missing mem_access gets. v2: Minor doc changes as suggested by Matt Reviewed-by: -
Rodrigo Vivi authored
Replace outdated information with a proper PM documentation. Already establish the rules for the runtime PM get and put that Xe needs to follow. Also add missing function documentation to all the "exported" functions. v2: updated after Francois' feedback. s/grater/greater (Matt) v3: detach D3 from runtime_pm remove opportunistic S0iX (Anshuman) Cc: Matthew Auld <matthew.auld@intel.com> Cc: Anshuman Gupta <anshuman.gupta@intel.com> Acked-by:Anshuman Gupta <anshuman.gupta@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20240222163937.138342-1-rodrigo.vivi@intel.com
-
- 23 Feb, 2024 5 commits
-
-
Matthew Brost authored
The xe_gt_tlb_invalidation layer implements TLB invalidations for a GuC backend. Simply return if in execlists mode. A follow up may properly implement the xe_gt_tlb_invalidation layer for both GuC and execlists. Fixes: a9351846 ("drm/xe: Break of TLB invalidation into its own file") Cc: Rodrigo Vivi <rodrigo.vivi@intel.com> Signed-off-by:
-
Matthew Brost authored
xe_ggtt.c touched GuC layers which is incorrect. Call into xe_gt_tlb_invalidation layer instead. Cc: Rodrigo Vivi <rodrigo.vivi@intel.com> Signed-off-by:
-
Matthew Brost authored
Although execlist submission is not supported it should be kept in a basic working state as it can be used for very early hardware bring up. Fix the below splat. WARNING: CPU: 3 PID: 11 at drivers/gpu/drm/xe/xe_execlist.c:217 execlist_run_job+0x1c2/0x220 [xe] Modules linked in: xe drm_kunit_helpers drm_gpuvm drm_ttm_helper ttm drm_exec drm_suballoc_helper drm_buddy gpu_sched mei_pxp mei_hdcp wmi_bmof x86_pkg_temp_thermal coretemp crct10dif_pclmul crc32_pclmul snd_hda_intel ghash_clmulni_intel snd_intel_dspcfg snd_hda_codec snd_hwdep snd_hda_core video snd_pcm mei_me mei wmi fuse e1000e i2c_i801 ptp i2c_smbus pps_core intel_lpss_pci CPU: 3 PID: 11 Comm: kworker/u16:0 Tainted: G U 6.8.0-rc3-guc+ #1046 Hardware name: Intel Corporation Tiger Lake Client Platform/TigerLake U DDR4 SODIMM RVP, BIOS TGLSFWI1.R00.3243.A01.2006102133 06/10/2020 Workqueue: rcs0 drm_sched_run_job_work [gpu_sched] RIP: 0010:execlist_run_job+0x1c2/0x220 [xe] Code: 8b f8 03 00 00 4c 89 39 e9 e2 fe ff ff 49 8d 7d 20 be ff ff ff ff e8 ed fd a6 e1 85 c0 0f 85 e1 fe ff ff 0f 0b e9 da fe ff ff <0f> 0b 0f 0b 41 83 fc 03 0f 86 8a fe ff ff 0f 0b e9 83 fe ff ff be RSP: 0018:ffffc9000013bdb8 EFLAGS: 00010246 RAX: ffff888105021a00 RBX: ffff888105078400 RCX: 0000000000000000 RDX: 0000000000000001 RSI: ffffc9000013bd14 RDI: ffffc90001609090 RBP: ffff88811e3f0040 R08: 0000000000000088 R09: 00000000ffffff81 R10: 0000000000000001 R11: ffff88810c10c000 R12: 00000000fffffffe R13: ffff888109b72c28 R14: ffff8881050784a0 R15: ffff888105078408 FS: 0000000000000000(0000) GS:ffff88849f980000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 0000563459d130f8 CR3: 000000000563a001 CR4: 0000000000f70ef0 DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000 DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400 PKRU: 55555554 Call Trace: <TASK> ? __warn+0x7f/0x170 ? execlist_run_job+0x1c2/0x220 [xe] ? report_bug+0x1c7/0x1d0 ? handle_bug+0x3c/0x70 ? exc_invalid_op+0x18/0x70 ? asm_exc_invalid_op+0x1a/0x20 ? execlist_run_job+0x1c2/0x220 [xe] ? execlist_run_job+0x2c/0x220 [xe] drm_sched_run_job_work+0x246/0x3f0 [gpu_sched] ? process_one_work+0x18d/0x4e0 process_one_work+0x1f7/0x4e0 worker_thread+0x1da/0x3e0 ? __pfx_worker_thread+0x10/0x10 kthread+0xfe/0x130 ? __pfx_kthread+0x10/0x10 ret_from_fork+0x2c/0x50 ? __pfx_kthread+0x10/0x10 ret_from_fork_asm+0x1b/0x30 </TASK> Fixes: 9b9529ce ("drm/xe: Rename engine to exec_queue") Signed-off-by:
-
Francois Dugast authored
Those cases missed in previous uAPI cleanups were mostly accidentally brought in from i915 or created to exercise the possibilities of gpuvm but they are not used by userspace yet, so let's remove them. They can still be brought back later if needed. v2: - Fix XE_VM_FLAG_FAULT_MODE support in xe_lrc.c (Brian Welty) - Leave DRM_XE_VM_BIND_OP_UNMAP_ALL (José Roberto de Souza) - Ensure invalid flag values are rejected (Rodrigo Vivi) v3: Rebase after removal of persistent exec_queues (Francois Dugast) v4: Rodrigo: Rebase after the new dumpable flag. Fixes: dd08ebf6 ("drm/xe: Introduce a new DRM driver for Intel GPUs") Cc: Thomas Hellström <thomas.hellstrom@linux.intel.com> Cc: Rodrigo Vivi <rodrigo.vivi@intel.com> Signed-off-by:
-
Erick Archer authored
This is an effort to get rid of all multiplications from allocation functions in order to prevent integer overflows [1]. As the "q" variable is a pointer to "struct xe_exec_queue" and this structure ends in a flexible array: struct xe_exec_queue { [...] struct xe_lrc lrc[]; }; the preferred way in the kernel is to use the struct_size() helper to do the arithmetic instead of the argument "size + size * count" in the kzalloc() function. This way, the code is more readable and more safer. Link: https://www.kernel.org/doc/html/latest/process/deprecated.html#open-coded-arithmetic-in-allocator-arguments [1] Link: https://github.com/KSPP/linux/issues/160 [2] Signed-off-by:Erick Archer <erick.archer@gmx.com> Signed-off-by:
Lucas De Marchi <lucas.demarchi@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20240210141913.6611-1-erick.archer@gmx.com
-
- 22 Feb, 2024 3 commits
-
-
Lucas De Marchi authored
Commit a0df2cc8 ("drm/xe/xe_bo_move: Enhance xe_bo_move trace") inadvertently reverted commit 8d038f49 ("drm/xe: Fix cast on trace variable"), breaking the build on 32bits. As noted by Ville, there's no point in converting the pointers to u64 and add casts everywhere. In fact, it's better to just use %p and let the address be hashed. Convert all the cases in xe_trace.h to use pointers. Cc: Ville Syrjälä <ville.syrjala@linux.intel.com> Cc: Matt Roper <matthew.d.roper@intel.com> Cc: Priyanka Dandamudi <priyanka.dandamudi@intel.com> Cc: Oak Zeng <oak.zeng@intel.com> Cc: Thomas Hellström <thomas.hellstrom@linux.intel.com> Signed-off-by:
-
Dafna Hirschfeld authored
The generated file 'generated/xe_wa_oob.h' is included using: "generated/xe_wa_oob.h" which first look inside the source code. But the file resides in the build directory and should therefore be included using: <generated/xe_wa_oob.h> Signed-off-by:
Dafna Hirschfeld <dhirschfeld@habana.ai> Reviewed-by:
-
Matthew Brost authored
Will help debug issues with VM binds. Signed-off-by:
-
- 21 Feb, 2024 6 commits
-
-
Maarten Lankhorst authored
Since we cannot immediately capture the BO's and userptr, perform it in 2 stages. The immediate stage takes a reference to each BO and userptr, while a delayed worker captures the contents and then frees the reference. This is required because in signaling context, no locks can be taken, no memory can be allocated, and no waits on userspace can be performed. With the delayed worker, all of this can be performed very easily, without having to resort to hacks. Changes since v1: - Fix crash on NULL captured vm. - Use ascii85_encode to capture BO contents and save some space. - Add length to coredump output for each captured area. Changes since v2: - Dump each mapping on their own line, to simplify tooling. - Fix null pointer deref in xe_vm_snapshot_free. Changes since v3: - Don't add uninitialized value to snap->ofs. (Souza) - Use kernel types for u32 and u64. - Move snap_mutex destruction to final vm destruction. (Souza) Changes since v4: - Remove extra memset. (Souza) Signed-off-by:
Maarten Lankhorst <maarten.lankhorst@linux.intel.com> Reviewed-by:
-
Maarten Lankhorst authored
The devcoredump is done in fence signaling context. Because of this, we cannot take any of the normal mutexes or we would invert. Normal: Take vm->lock, dma_fence_wait() Devcoredump: from dma_fence_wait() context, take vm->lock. This doesn't work, and we only care about integrity, so take the locks around additions and removals of vma's. Signed-off-by:
-
Maarten Lankhorst authored
In preparation for snapshot dumping, mark each dumpable VMA as such, so we can walk over the VM later and dump it. Signed-off-by:
-
Maarten Lankhorst authored
Add the flag XE_VM_BIND_FLAG_DUMPABLE to notify devcoredump that this mapping should be dumped. This is not hooked up, but the uapi should be ready before merging. It's likely easier to dump the contents of the bo's at devcoredump readout time, so it's better if the bos will stay unmodified after a hang. The NEEDS_CPU_MAPPING flag is removed as requirement. Signed-off-by:
-
Maarten Lankhorst authored
It's not strictly needed to clear right now, but this prevents bugs from dangling pointers. Signed-off-by:
-
Maarten Lankhorst authored
The kernel will complain loudly if allocation fails, no need to do it ourselves. Signed-off-by:
-
- 20 Feb, 2024 6 commits
-
-
Ashutosh Dixit authored
$ make W=1 -j100 M=drivers/gpu/drm/xe MODPOST drivers/gpu/drm/xe/Module.symvers WARNING: modpost: missing MODULE_DESCRIPTION() in drivers/gpu/drm/xe/tests/xe_mocs_test.o Fix is identical to '1d425066 ("drm/xe: Fix modpost warning on kunit modules")'. Fixes: a6a4ea6d ("drm/xe: Add mocs kunit") Signed-off-by:
Ashutosh Dixit <ashutosh.dixit@intel.com> Reviewed-by:
-
Ashutosh Dixit authored
Newline in name is redunant and produces an unnecessary empty line during 'cat name'. Newline is added during sysfs_emit. See '27a1a1e2 ("drm/xe: stringify the argument to avoid potential vulnerability")'. v2: Add Fixes tag (Riana) Fixes: 7b076d14 ("drm/xe/mtl: Add support to get C6 residency/status of MTL") Reviewed-by:
Riana Tauro <riana.tauro@intel.com> Signed-off-by:
-
Christophe JAILLET authored
ida_alloc() and ida_free() should be preferred to the deprecated ida_simple_get() and ida_simple_remove(). Note that the upper limit of ida_simple_get() is exclusive, but the one of ida_alloc_max() is inclusive. So a -1 has been added when needed. Signed-off-by:
Christophe JAILLET <christophe.jaillet@wanadoo.fr> Reviewed-by:
-
Michał Winiarski authored
SR-IOV VF has limited access to MMIO registers. Fortunately, it is able to access a curated subset that is needed to initialize the driver by communicating with SR-IOV PF using GuC CT. Initialize GuC earlier in order to keep the unified probe ordering between VF and PF modes. Signed-off-by:
Michał Winiarski <michal.winiarski@intel.com> Reviewed-by:
-
Michał Winiarski authored
SLPC is not used at "hwconfig" stage. Move the initialization of data structures used for SLPC to a later point in probe. Also - move the xe_guc_pc_init_early to happen just prior to initial "hwconfig" load. Signed-off-by:
-
Michał Winiarski authored
Similar to GuC, we're using system memory for the initial stage, and move the image to vram when it's available for subsequent loads (e.g. after reset). Signed-off-by:
-
