- 19 Apr, 2024 1 commit
-
-
Ashutosh Dixit authored
When both hwmon and hwmon drvdata (on which hwmon depends) are device managed resources, the expectation, on device unbind, is that hwmon will be released before drvdata. However, in i915 there are two separate code paths, which both release either drvdata or hwmon and either can be released before the other. These code paths (for device unbind) are as follows (see also the bug referenced below): Call Trace: release_nodes+0x11/0x70 devres_release_group+0xb2/0x110 component_unbind_all+0x8d/0xa0 component_del+0xa5/0x140 intel_pxp_tee_component_fini+0x29/0x40 [i915] intel_pxp_fini+0x33/0x80 [i915] i915_driver_remove+0x4c/0x120 [i915] i915_pci_remove+0x19/0x30 [i915] pci_device_remove+0x32/0xa0 device_release_driver_internal+0x19c/0x200 unbind_store+0x9c/0xb0 and Call Trace: release_nodes+0x11/0x70 devres_release_all+0x8a/0xc0 device_unbind_cleanup+0x9/0x70 device_release_driver_internal+0x1c1/0x200 unbind_store+0x9c/0xb0 This means that in i915, if use devm, we cannot gurantee that hwmon will always be released before drvdata. Which means that we have a uaf if hwmon sysfs is accessed when drvdata has been released but hwmon hasn't. The only way out of this seems to be do get rid of devm_ and release/free everything explicitly during device unbind. v2: Change commit message and other minor code changes v3: Cleanup from i915_hwmon_register on error (Armin Wolf) v4: Eliminate potential static analyzer warning (Rodrigo) Eliminate fetch_and_zero (Jani) v5: Restore previous logic for ddat_gt->hwmon_dev error return (Andi) Closes: https://gitlab.freedesktop.org/drm/intel/-/issues/10366Reviewed-by:Rodrigo Vivi <rodrigo.vivi@intel.com> Signed-off-by:
Ashutosh Dixit <ashutosh.dixit@intel.com> Reviewed-by:
Andi Shyti <andi.shyti@linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20240417145646.793223-1-ashutosh.dixit@intel.com
-
- 18 Apr, 2024 18 commits
-
-
Himal Prasad Ghimiray authored
xe_pm_init may encounter failures for various reasons, such as a failure in initializing drmm_mutex, or when dealing with a d3cold-capable device for vram_threshold sysfs creation and setting default threshold. Presently, all these potential failures are disregarded. Move d3cold.lock initialization to xe_pm_init_early and cause driver abort if mutex initialization has failed. For xe_pm_init failures cleanup the driver and return error code -v2 Make mutex init cleaner (Lucas) Cc: Lucas De Marchi <lucas.demarchi@intel.com> Cc: Rodrigo Vivi <rodrigo.vivi@intel.com> Signed-off-by:
Himal Prasad Ghimiray <himal.prasad.ghimiray@intel.com> Reviewed-by:
Lucas De Marchi <lucas.demarchi@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20240412181211.1155732-8-himal.prasad.ghimiray@intel.comSigned-off-by:
-
Himal Prasad Ghimiray authored
Ensure that the status of all tile associated sysfs entries creation is relayed to xe_tile_init_noalloc, leading to a driver load abort if any sysfs creation failures occur. -v2 Avoid unnecessary warn/error messages. (Lucas) Cc: Rodrigo Vivi <rodrigo.vivi@intel.com> Cc: Lucas De Marchi <lucas.demarchi@intel.com> Signed-off-by:
-
Himal Prasad Ghimiray authored
Instead of allowing the driver to load with incomplete sysfs entries in case of sysfs creation failure, we should terminate the driver loading. This change ensures that the status of all gt associated sysfs entries creation is relayed to xe_gt_init, leading to a driver load abort if any sysfs creation failures occur. -v2 use err_force_wake label instead of new. (Lucas) Avoid unnecessary warn/error messages. (Lucas) Cc: Rodrigo Vivi <rodrigo.vivi@intel.com> Cc: Lucas De Marchi <lucas.demarchi@intel.com> Signed-off-by:
-
Himal Prasad Ghimiray authored
In case of drmm_add_action_or_reset failure return NULL and no need to print warning messages as they will be printed implictly. Cc: Tejas Upadhyay <tejas.upadhyay@intel.com> Cc: Rodrigo Vivi <rodrigo.vivi@intel.com> Reviewed-by:
-
Himal Prasad Ghimiray authored
The drmm_add_action_or_reset function automatically invokes the action (free_gsc_pkt) in the event of a failure; therefore, there's no necessity to call it within the return check. -v2 Fix commit message. (Lucas) Fixes: d8b15713 ("drm/xe/huc: HuC authentication via GSC") Cc: Rodrigo Vivi <rodrigo.vivi@intel.com> Cc: Daniele Ceraolo Spurio <daniele.ceraolospurio@intel.com> Reviewed-by:
Daniele Ceraolo Spurio <daniele.ceraolospurio@intel.com> Signed-off-by:
-
Himal Prasad Ghimiray authored
The drmm_add_action_or_reset function automatically invokes the action (sysfs removal) in the event of a failure; therefore, there's no necessity to call it within the return check. Modify the return type of xe_gt_ccs_mode_sysfs_init to int, allowing the caller to pass errors up the call chain. Should sysfs creation or drmm_add_action_or_reset fail, error propagation will prompt a driver load abort. -v2 Edit commit message (Nikula/Lucas) use err_force_wake label instead of new. (Lucas) Avoid unnecessary warn/error messages. (Lucas) Fixes: f3bc5bb4 ("drm/xe: Allow userspace to configure CCS mode") Cc: Lucas De Marchi <lucas.demarchi@intel.com> Cc: Jani Nikula <jani.nikula@intel.com> Cc: Rodrigo Vivi <rodrigo.vivi@intel.com> Cc: Niranjana Vishwanathapura <niranjana.vishwanathapura@intel.com> Reviewed-by:
-
Himal Prasad Ghimiray authored
Instead of assigning the value of drmm_add_action_or_reset() to err and returning err in case of failure and 0 in case of success, simply return the result of drmm_add_action_or_reset(). -v2: cleanup in xe_display too. Cc: Rodrigo Vivi <rodrigo.vivi@intel.com> Cc: Lucas De Marchi <lucas.demarchi@intel.com> Reviewed-by:
-
Gustavo Sousa authored
Wa_14020338487 also applies to Xe2_LPG. Replicate the existing entry to one specific for Xe2_LPG. Signed-off-by:
Gustavo Sousa <gustavo.sousa@intel.com> Reviewed-by:
Matt Roper <matthew.d.roper@intel.com> Signed-off-by:
-
Rodrigo Vivi authored
Any kunit doing any memory access should get their own runtime_pm outer references since they don't use the standard driver API entries. In special this dma_buf from the same driver. Found by pre-merge CI on adding WARN calls for unprotected inner callers: <6> [318.639739] # xe_dma_buf_kunit: running xe_test_dmabuf_import_same_driver <4> [318.639957] ------------[ cut here ]------------ <4> [318.639967] xe 0000:4d:00.0: Missing outer runtime PM protection <4> [318.640049] WARNING: CPU: 117 PID: 3832 at drivers/gpu/drm/xe/xe_pm.c:533 xe_pm_runtime_get_noresume+0x48/0x60 [xe] Cc: Matthew Auld <matthew.auld@intel.com> Cc: Francois Dugast <francois.dugast@intel.com> Reviewed-by:
Matthew Brost <matthew.brost@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20240417203952.25503-10-rodrigo.vivi@intel.comSigned-off-by:
-
Rodrigo Vivi authored
At this point mem_access references should be only used as inner points of the execution and a get with synchronous resume previously called at an outer point. So, before killing mem_acces in favor of direct accsess, let's ensure that we first convert them towards the new _noresume variant that will WARN us if no inner caller happened. Reviewed-by:
Matthew Auld <matthew.auld@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20240417203952.25503-9-rodrigo.vivi@intel.comSigned-off-by:
-
Rodrigo Vivi authored
Now that assert_mem_access is relying directly on the pm_runtime state instead of the counters, there's no reason why we cannot use the pm_runtime functions directly. Reviewed-by:
-
Rodrigo Vivi authored
This is not needed any longer, now that we have all the protection in place with the runtime pm itself. Reviewed-by:
-
Rodrigo Vivi authored
The gem page fault is one of the outer bound protections where we want to ensure that the hardware is in D0 before proceeding with memory access. Let's convert it towards the xe_pm_runtime functions directly so we can then convert the mem_access to be inner protection only and then Kill it for good. Reviewed-by:
-
Rodrigo Vivi authored
xe_pm_init is the very last thing during the xe_pci_probe(), hence these protections are useless from the point of view of ensuring that the device is awake. Let's remove it so we continue towards the goal of killing xe_device_mem_access. v2: Adding more cases v3: Provide a separate fix for xe_tile_init_noalloc return (Matt) Adding a new case where display HDCP init calls which are also called at display probe time. Cc: Matthew Auld <matthew.auld@intel.com> Reviewed-by: -
Rodrigo Vivi authored
The mem_access itself is not holding any lock, but attempting to train lockdep with possible scarring locks happening during runtime pm. We are going soon to kill the mem_access get and put helpers in favor of direct xe_pm_runtime calls, so let's just move this lock around to where it now belongs. v2: s/lockdep_training/lockdep_prime (Matt Auld) Reviewed-by:
-
Rodrigo Vivi authored
This patch brings no functional change. Since at this point of the code we are already asserting a wakeref was held, it means that we are with runtime_pm 'in_use' and in practical terms we are only bumping the pm_runtime usage counter and moving on. However, xe driver has a lockdep annotation that warned us that if a sync resume was actually called at this point, we could have a deadlock because we are inside the power_domains->lock locked area and the resume would call the irq_reset, which would also try to get the power_domains->lock. For this reason, let's convert this call to a safer option and calm lockdep on. v2: use _noresume variant instead of get_in_use (Ville, Imre) Cc: Ville Syrjälä <ville.syrjala@linux.intel.com> Acked-by:
Imre Deak <imre.deak@intel.com> Cc: Matthew Auld <matthew.auld@intel.com> Reviewed-by:
Francois Dugast <francois.dugast@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20240417203952.25503-3-rodrigo.vivi@intel.comSigned-off-by:
-
Rodrigo Vivi authored
The i915-display will start using the intel_runtime_pm_noresume. So we need to add the compat header before it. Reviewed-by:
-
Rodrigo Vivi authored
Let's ensure that we have an option for inner callers that will raise WARN if device is not active and not protected by outer callers. Make this also a void function forcing every caller to unconditionally put the reference back afterwards. This will be very important for cases where we want to hold the reference before scheduling a work in a queue. Then the work job will be responsible for putting it back. While at this, already convert a case from mem_access_get_ongoing where it is not checking for the reference and put it back, what would cause the underflow. v2: Fix identation. v3: Convert equivalent missing put from mem_access towards pm_runtime. Reviewed-by:
-
- 17 Apr, 2024 6 commits
-
-
Vinay Belgaumkar authored
Enable WA for a bug that could cause the C6 state machine to hang during RC6 exit. v2: Add comment clarifying the WA (John H) v3: Add more details to the comment (John H) Signed-off-by:
Vinay Belgaumkar <vinay.belgaumkar@intel.com> Reviewed-by:
John Harrison <John.C.Harrison@Intel.com> Signed-off-by:
-
Matthew Auld authored
clangd complains here, since nothing in xe_gt.h seems to be needed. Signed-off-by:
-
Matthew Auld authored
Now that we no longer grab the usm.lock mutex (which might sleep) it looks like it should be safe to directly perform xe_vm_free when vm refcount reaches zero, instead of punting that off to some worker. Signed-off-by:
-
Matthew Auld authored
The asid is only erased from the xarray when the vm refcount reaches zero, however this leads to potential UAF since the xe_vm_get() only works on a vm with refcount != 0. Since the asid is allocated in the vm create ioctl, rather erase it when closing the vm, prior to dropping the potential last ref. This should also work when user closes driver fd without explicit vm destroy. Fixes: dd08ebf6 ("drm/xe: Introduce a new DRM driver for Intel GPUs") Closes: https://gitlab.freedesktop.org/drm/xe/kernel/-/issues/1594Signed-off-by:
-
Matthew Auld authored
We have observed underruns on some platforms if the CFB offset is within the first page of stolen. Just like i915 skip the first page. v2 (Maarten) - Also align the start. BSpec: 50214 Reported-by:
Maarten Lankhorst <maarten.lankhorst@linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20240412150301.273344-4-matthew.auld@intel.com
-
Matthew Auld authored
No need to be so aggressive here. The upper layers will already apply the needed alignment, plus some allocations might wish to skip it. Main issue is that we might want to have start/end bias range which doesn't match the default alignment which is rejected by the allocator. Signed-off-by:
-
- 16 Apr, 2024 9 commits
-
-
Lu Yao authored
ACPI_WMI is a subitem of X86_PLATFORM_DEVICES. And X86_PLATFORM_DEVICES is not selected in the current Kconfig, and may cause Kconfig warnings: WARNING: unmet direct dependencies detected for ACPI_WMI Depends on [n]: X86_PLATFORM_DEVICES [=n] && ACPI [=y] Selected by [m]: - DRM_XE [=m] && HAS_IOMEM [=y] && DRM [=m] && PCI [=y] && MMU [=y] && (m && MODULES [=y] || y && KUNIT [=y]=y) && X86 [=y] && ACPI [=y] Signed-off-by:Lu Yao <yaolu@kylinos.cn> Reviewed-by:
-
John Harrison authored
Enable a couple of existing workarounds for a new platform. Signed-off-by:
-
John Harrison authored
There are a couple of new workarounds for LNL that are implemented in the GuC firmware. The KMD needs to enable them explicitly. Signed-off-by:
-
Michal Wajdeczko authored
To run correctly, each Virtual Function must be provisioned with some chunk of shared hardware or firmware resources (like GGTT, device memory, GuC doorbell IDs, GuC context IDs) and scheduling parameters (execution quantum or preemption timeout). All resources assigned to VFs must be excluded from the PF driver use and may require some additional preparation steps (like setup of the LMTT or update of the GGTT PTE). Those provisioning details must be then sent to the GuC firmware as most of those details will be shared later with the VF drivers during their boot. Add basic functions to provision VFs with all hardware resources or scheduling parameters. We will use them shortly in upcoming patches either in manual provisioning over debugfs, exposed to the advanced users, or automatic provisioning done by PF driver during VFs enabling. Reviewed-by:
Piotr Piórkowski <piotr.piorkowski@intel.com> Signed-off-by:
Michal Wajdeczko <michal.wajdeczko@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20240415173937.1287-7-michal.wajdeczko@intel.com
-
Michal Wajdeczko authored
The PF driver must maintain additional GT level data per each VF. This additional per-VF data will be added in upcoming patches and will include: provisioning configuration (like GGTT space or LMEM allocation sizes or scheduling parameters), monitoring thresholds and counters, and more. As number of supported VFs varies across platforms use flexible array where first entry will contain metadata for the PF itself (if such configuration parameter is applicable for the PF) and all remaining entries will contain data for potential VFs. Reviewed-by:
-
Michal Wajdeczko authored
In upcoming patches the PF driver will add support to change VFs configuration and will need to use PF2GUC_UPDATE_VF_CFG messages. Add necessary definitions to our GuC firmware ABI header. Definitions of the GuC VF Configuration KLVs used by this action are already present in abi/guc_klvs_abi.h Reviewed-by:
-
Michal Wajdeczko authored
The PF driver will need to know size of the remaining available VRAM to estimate fair VRAM allocations that could be used across all VFs in automatic VFs provisioning mode. Add helper function for that. We will use it in upcoming patch. Reviewed-by:
-
Michal Wajdeczko authored
VF's drivers can't modify GGTT PTEs except the range explicitly assigned by the PF driver. To allow hardware enforcement of this requirement, each GGTT PTE has a field with the VF number that identifies which VF can modify that particular GGTT PTE entry. Only PF driver can modify this field and PF driver shall do that before VF drivers will be loaded. Add function to prepare PTEs. Since it will be used only by the PF driver, make it available only for CONFIG_PCI_IOV=y. Bspec: 45015, 52395 Reviewed-by:
-
Michal Wajdeczko authored
While the GuC firmware and the Xe driver are using VF identifier VFID(0) to represent the Physical Function, we should avoid using "VF0" name and use proper "PF" name in all user facing messages related to the Physical Function and use "VFn" name only when referrinf to the true Virtual Function. Add simple helper to get properly formatted function name based on the function number. Reviewed-by:
-
- 15 Apr, 2024 1 commit
-
-
Francois Dugast authored
Generate the mask of enabled L3 banks for the GT. It is stored with the rest of the GT topology in a consistent representation across platforms. For now the L3 bank mask is just printed in the log for developers to easily figure out the fusing characteristics of machines that they are trying to debug issues on. Later it can be used to replace existing code in the driver that requires the L3 bank count (not mask). Also the mask can easily be exposed to user space in a new query if needed. v2: Better naming of variable and function (Matt Roper) Bspec: 52545, 52546, 62482 Cc: Matt Roper <matthew.d.roper@intel.com> Signed-off-by:
-
- 12 Apr, 2024 5 commits
-
-
Michal Wajdeczko authored
There are few knobs inside GuC firmware to control VFs scheduling. Add basic functions to support their reconfigurations. We will start using them shortly once we prepare debugfs. Signed-off-by:
-
Michal Wajdeczko authored
Many of the GuC actions use KLVs to pass additional parameters or configuration data. Add few helper functions for better reporting any information related to KLVs. Cc: Himal Prasad Ghimiray <himal.prasad.ghimiray@intel.com> Reviewed-by:
-
Michal Wajdeczko authored
In upcoming patches the PF driver will add support to change GuC policies and will need to use PF2GUC_UPDATE_VGT_POLICY messages. Add necessary definitions to our GuC firmware ABI header. Reviewed-by:
-
Michal Wajdeczko authored
PF driver will maintain VF's configuration data mostly on the GT level, but some internal data is located at the device level. To allow easy access to that data from the GT level functions, and to minimize code duplications, introduce set of helper functions and macros for explicit use by the PF driver. We will use these helpers in upcoming patches. Reviewed-by:
-
Michal Wajdeczko authored
PF driver will maintain configurations and resources for every VF and this data could span multiple tiles and/or GTs. Prepare mutex to protect data that we will add in upcoming patches. Reviewed-by:
-
