The PAT index determines how PTEs are encoded and can be modified by
madvise. Therefore, it is now part of the vma attributes.
Reviewed-by: Matthew Brost <matthew.brost@intel.com>
Link: https://lore.kernel.org/r/20250821173104.3030148-4-himal.prasad.ghimiray@intel.com
Signed-off-by: Himal Prasad Ghimiray <himal.prasad.ghimiray@intel.com>
The attribute of xe_vma will determine the migration policy and the
encoding of the page table entries (PTEs) for that vma.
This attribute helps manage how memory pages are moved and how their
addresses are translated. It will be used by madvise to set the
behavior of the vma.
v2 (Matthew Brost)
- Add docs
v3 (Matthew Brost)
- Add uapi references
- 80 characters line wrap
Cc: Matthew Brost <matthew.brost@intel.com>
Reviewed-by: Matthew Brost <matthew.brost@intel.com>
Reviewed-by: Thomas Hellström <thomas.hellstrom@linux.intel.com>
Link: https://lore.kernel.org/r/20250821173104.3030148-3-himal.prasad.ghimiray@intel.com
Signed-off-by: Himal Prasad Ghimiray <himal.prasad.ghimiray@intel.com>
This commit introduces a new madvise interface to support
driver-specific ioctl operations. The madvise interface allows for more
efficient memory management by providing hints to the driver about the
expected memory usage and pte update policy for gpuvma.
v2 (Matthew/Thomas)
- Drop num_ops support
- Drop purgeable support
- Add kernel-docs
- IOWR/IOW
v3 (Matthew/Thomas)
- Reorder attributes
- use __u16 for migration_policy
- use __u64 for reserved in unions
- Avoid usage of vma
Cc: Matthew Brost <matthew.brost@intel.com>
Reviewed-by: Matthew Brost <matthew.brost@intel.com>
Link: https://lore.kernel.org/r/20250821173104.3030148-2-himal.prasad.ghimiray@intel.com
Signed-off-by: Himal Prasad Ghimiray <himal.prasad.ghimiray@intel.com>
Sync with drm-misc-next which is necessary for changes in gpuvm
and gpusvm that will be used in xe.
Signed-off-by: Lucas De Marchi <lucas.demarchi@intel.com>
Commit b0a2ee5567 ("drm/xe: prepare xe_gen_wa_oob to be multi-use")
introduced a call to basename(). The GNU version of this function is not
portable and fails to build with alternative libc implementations like
musl or bionic. This causes the following build error:
drivers/gpu/drm/xe/xe_gen_wa_oob.c:130:12: error: assignment to ‘const char *’ from ‘int’ makes pointer from integer without a cast [-Wint-conversion]
130 | fn = basename(fn);
| ^
While a POSIX version of basename() could be used, it would require a
separate header plus the behavior differs from GNU version in that it
might modify its argument. Not great.
Instead, implement a local xbasename() helper based on strrchr() that
provides the same functionality and avoids portability issues.
Fixes: b0a2ee5567 ("drm/xe: prepare xe_gen_wa_oob to be multi-use")
Suggested-by: Lucas De Marchi <lucas.demarchi@intel.com>
Reviewed-by: Tiffany Yang <ynaffit@google.com>
Signed-off-by: Carlos Llamas <cmllamas@google.com>
Reviewed-by: Lucas De Marchi <lucas.demarchi@intel.com>
Link: https://lore.kernel.org/r/20250825155743.1132433-1-cmllamas@google.com
Signed-off-by: Lucas De Marchi <lucas.demarchi@intel.com>
On the first validate of an imported dma-buf (initial bind), the device
has no GPU mappings, so a rebind is unnecessary. Rebinding here is
harmful in multi-GPU setups and for VMs using preempt-fence mode, as it
would evict in-flight GPU work.
v2:
- Drop dma_buf_validated, check for XE_PL_SYSTEM (Thomas)
Fixes: dd08ebf6c3 ("drm/xe: Introduce a new DRM driver for Intel GPUs")
Signed-off-by: Matthew Brost <matthew.brost@intel.com>
Reviewed-by: Thomas Hellström <thomas.hellstrom@linux.intel.com>
Link: https://lore.kernel.org/r/20250825152841.3837378-1-matthew.brost@intel.com
Avoid triggering a dereference of an error pointer on cleanup in
xe_vm_free_scratch() by clearing any scratch_pt error pointer.
Signed-off-by: Thomas Hellström <thomas.hellstrom@linux.intel.com>
Fixes: 06951c2ee7 ("drm/xe: Use NULL PTEs as scratch PTEs")
Cc: Brian Welty <brian.welty@intel.com>
Cc: Rodrigo Vivi <rodrigo.vivi@intel.com>
Cc: Lucas De Marchi <lucas.demarchi@intel.com>
Cc: <stable@vger.kernel.org> # v6.8+
Reviewed-by: Matthew Brost <matthew.brost@intel.com>
Link: https://lore.kernel.org/r/20250821143045.106005-4-thomas.hellstrom@linux.intel.com
This member is set when exporting using prime. However
the xe_gem_prime_export() alone doesn't set it, since it's done
later in the prime export flow.
For the test, set it manually and remove the hack that set it
temporarily when it was really needed.
Signed-off-by: Thomas Hellström <thomas.hellstrom@linux.intel.com>
Reviewed-by: Matthew Brost <matthew.brost@intel.com>
Link: https://lore.kernel.org/r/20250821143045.106005-3-thomas.hellstrom@linux.intel.com
The pinning has the odd side-effect that unlocking *any* resv
during validation triggers an "unlocking pinned lock" warning.
Cc: Matthew Brost <matthew.brost@intel.com>
Fixes: 9d5558649f ("drm/xe: Rework eviction rejection of bound external bos")
Signed-off-by: Thomas Hellström <thomas.hellstrom@linux.intel.com>
Reviewed-by: Matthew Brost <matthew.brost@intel.com>
Link: https://lore.kernel.org/r/20250821143045.106005-2-thomas.hellstrom@linux.intel.com
Marking ufence as signalled after copy_to_user() is too late.
Worker thread which signals ufence by memory write might be raced
with another userspace vm-bind call. In map/unmap scenario unmap
may still see ufence is not signalled causing -EBUSY. Change the
order of marking / write to user-fence fixes this issue.
Fixes: 977e5b82e0 ("drm/xe: Expose user fence from xe_sync_entry")
Link: https://gitlab.freedesktop.org/drm/xe/kernel/-/issues/5536
Signed-off-by: Zbigniew Kempczyński <zbigniew.kempczynski@intel.com>
Cc: Matthew Brost <matthew.brost@intel.com>
Cc: Matthew Auld <matthew.auld@intel.com>
Reviewed-by: Matthew Brost <matthew.brost@intel.com>
Signed-off-by: Matthew Brost <matthew.brost@intel.com>
Link: https://lore.kernel.org/r/20250820083903.2109891-2-zbigniew.kempczynski@intel.com
Device configuration using configfs could be prepared long time prior
the driver load. Currently all the xe configfs entries are for things
that are important to have in the log if a non-default value is being
used. Add a info-level message about that with the individual entries
that are different than the default.
Based on previous patch by Michal Wajdeczko.
Cc: Michal Wajdeczko <michal.wajdeczko@intel.com>
Cc: John Harrison <John.C.Harrison@Intel.com>
Reviewed-by: Vinay Belgaumkar <vinay.belgaumkar@intel.com>
Link: https://lore.kernel.org/r/20250821-psmi-v5-12-34ab7550d3d8@intel.com
Signed-off-by: Lucas De Marchi <lucas.demarchi@intel.com>
Add a few missing punctuation and line breaks and make the syntax for
code snippets common to all of them.
Reviewed-by: Dnyaneshwar Bhadane <dnyaneshwar.bhadane@intel.com>
Link: https://lore.kernel.org/r/20250821-psmi-v5-11-34ab7550d3d8@intel.com
Signed-off-by: Lucas De Marchi <lucas.demarchi@intel.com>
The steps are roughly:
1. Load the module without binding to the device
2. Configure the desired device
3. Bind the device
Move the binding part to the "Create devices" since it's not exclusive
to the survivability_mode attribute and better document the steps.
Reviewed-by: Riana Tauro <riana.tauro@intel.com>
Link: https://lore.kernel.org/r/20250821-psmi-v5-10-34ab7550d3d8@intel.com
Signed-off-by: Lucas De Marchi <lucas.demarchi@intel.com>
When documenting the directories, use an output similar to the `tree`
command and add VFs and missing attributes.
Reviewed-by: Dnyaneshwar Bhadane <dnyaneshwar.bhadane@intel.com>
Link: https://lore.kernel.org/r/20250821-psmi-v5-9-34ab7550d3d8@intel.com
Signed-off-by: Lucas De Marchi <lucas.demarchi@intel.com>
Instead of the manual lock()/unlock() pattern, use guard() which will
make things easier for handling errors or early returns.
Reviewed-by: Dnyaneshwar Bhadane <dnyaneshwar.bhadane@intel.com>
Link: https://lore.kernel.org/r/20250821-psmi-v5-8-34ab7550d3d8@intel.com
Signed-off-by: Lucas De Marchi <lucas.demarchi@intel.com>
Now that additional WAs are in place and it's possible to allocate
buffers through debugfs, add the configfs attribute to turn PSMI on.
Cc: Matt Roper <matthew.d.roper@intel.com>
Cc: Daniele Ceraolo Spurio <daniele.ceraolospurio@intel.com>
Cc: John Harrison <John.C.Harrison@Intel.com>
Reviewed-by: Riana Tauro <riana.tauro@intel.com>
Link: https://lore.kernel.org/r/20250821-psmi-v5-7-34ab7550d3d8@intel.com
Signed-off-by: Lucas De Marchi <lucas.demarchi@intel.com>
From the caller perspective reading the documentation, there's no need
to be so specific about everything the function is doing/checking. Just
document the functionality a caller cares about.
Reviewed-by: Riana Tauro <riana.tauro@intel.com>
Link: https://lore.kernel.org/r/20250821-psmi-v5-6-34ab7550d3d8@intel.com
Signed-off-by: Lucas De Marchi <lucas.demarchi@intel.com>
This WA ensures GuC will restore the media MCFG registers at C6
exit.
Signed-off-by: Vinay Belgaumkar <vinay.belgaumkar@intel.com>
Reviewed-by: Matt Atwood <matthew.s.atwood@intel.com>
Link: https://lore.kernel.org/r/20250821-psmi-v5-5-34ab7550d3d8@intel.com
Signed-off-by: Lucas De Marchi <lucas.demarchi@intel.com>
Enable Wa 14020001231 to block psmi interrupts during C6 entry exit
flow. It's only enabled if PSMI is enabled in runtime.
Signed-off-by: Badal Nilawar <badal.nilawar@intel.com>
Reviewed-by: Matt Atwood <matthew.s.atwood@intel.com>
Link: https://lore.kernel.org/r/20250821-psmi-v5-4-34ab7550d3d8@intel.com
Signed-off-by: Lucas De Marchi <lucas.demarchi@intel.com>
Add match to be used on WAs for only enabling workarounds if psmi is
intended to be used.
Reviewed-by: Vinay Belgaumkar <vinay.belgaumkar@intel.com>
Link: https://lore.kernel.org/r/20250821-psmi-v5-3-34ab7550d3d8@intel.com
Signed-off-by: Lucas De Marchi <lucas.demarchi@intel.com>
Requirement for PSMI capture is to have a physically contiguous buffer.
All the needed configuration is done by the userspace tool directly to
the GPU via mmio access.
This interface only support allocating from VRAM regions. For integrated
devices, the PSMI buffer is in SYSTEM memory and should be allocated by
userspace using hugetlbfs.
Here we add the ability to allocate a region of physically contiguous
memory by writing to debugfs file (listed below). For multi-tile devices,
the capture tool requires ability to allocate a capture buffer per tile
(VRAM region) and so user can specify a region_mask. The tool then
can mmap the buffers via direct mmap of the PCIBAR via sysfs.
To support the capture tool, 3 new debugfs entries are added:
psmi_capture_addr - physical address per VRAM region's capture buffer
psmi_capture_region_mask - select which region(s) to allocate a buffer
psmi_capture_size - size of current capture buffer
Writing psmi_capture_size will allocate new buffer of requested size per
region after freeing any current buffers.
Cc: Matt Roper <matthew.d.roper@intel.com>
Cc: Vinay Belgaumkar <vinay.belgaumkar@intel.com>
Original-author: Brian Welty <brian.welty@intel.com>
Reviewed-by: Vinay Belgaumkar <vinay.belgaumkar@intel.com> # v2
Link: https://lore.kernel.org/r/20250821-psmi-v5-2-34ab7550d3d8@intel.com
Signed-off-by: Lucas De Marchi <lucas.demarchi@intel.com>
PSMI allows to capture data from the GPU useful for early
validation. From the kernel side there isn't much to be done, just a few
things:
1) Toggle the feature support in GuC
2) Enable some additional WAs
3) Allocate buffers
Here is the first step, with the next ones to follow. For now everything
is disabled through a check in configfs that is currently hardcoded to
disabled.
Cc: Matt Roper <matthew.d.roper@intel.com>
Cc: Daniele Ceraolo Spurio <daniele.ceraolospurio@intel.com>
Cc: John Harrison <John.C.Harrison@Intel.com>
Reviewed-by: Vinay Belgaumkar <vinay.belgaumkar@intel.com>
Link: https://lore.kernel.org/r/20250821-psmi-v5-1-34ab7550d3d8@intel.com
Signed-off-by: Lucas De Marchi <lucas.demarchi@intel.com>
There are two registers filled in when reading data from
pcode besides the mailbox itself. Currently, we allow a NULL
value for the second of these two (data1) and assume the first
is defined. However, many of the routines that are calling
this function assume that pcode will ignore the value being
passed in and so leave that first value (data0) defined but
uninitialized. To be safe, make sure this value is always
initialized to something (0 generally) in the event pcode
behavior changes and starts using this value.
v2: Fix sob/author
Signed-off-by: Stuart Summers <stuart.summers@intel.com>
Reviewed-by: Jonathan Cavitt <jonathan.cavitt@intel.com>
Link: https://lore.kernel.org/r/20250819201054.393220-1-stuart.summers@intel.com
Signed-off-by: Rodrigo Vivi <rodrigo.vivi@intel.com>
Our list of typical platforms used to generate test device objects
does not contain any PANTHERLAKE. Add one.
Signed-off-by: Michal Wajdeczko <michal.wajdeczko@intel.com>
Cc: Lucas De Marchi <lucas.demarchi@intel.com>
Reviewed-by: Lucas De Marchi <lucas.demarchi@intel.com>
Link: https://lore.kernel.org/r/20250818192032.633-1-michal.wajdeczko@intel.com
We are currently bumping gt_count as we define GTs for each tile. While
that works with our current code, there are reasons to improve that:
* That section of the code is dedicated to define each tile's set of GTs
and their respective info. The gt_count can be seen as a device level
property. While it is fair to bump it as we define each GT, we can
also focus on the GT themselves and count after we are done with the
definitions.
* More *importantly*, gt_count should reflect the number of GTs that we
would get when looping over them with for_each_gt(). Bumping gt_count
the way we are currently doing makes that value not really connected
to for_each_gt(). This could bite us in the future if in the loop gets
extra checks that are not accounted for in each existing "gt_count++".
As such, let's use for_each_gt() and extract the calculation of gt_count
into a separate block, just after we define the set of GTs for each
tile.
Reviewed-by: Jonathan Cavitt <jonathan.cavitt@intel.com>
Reviewed-by: Rodrigo Vivi <rodrigo.vivi@intel.com>
Link: https://lore.kernel.org/r/20250818-gt_count-improvements-v4-2-ee12870c6f57@intel.com
Signed-off-by: Gustavo Sousa <gustavo.sousa@intel.com>
The function mmio_multi_tile_setup() does not look like the proper
location for probing for the number of existing tiles in the hardware.
It should not be that function's responsibility and such information
should instead be already available when it gets called.
The fact that we need to adjust gt_count is a symptom of that.
Move probing of available tile count to a dedicated function named
xe_info_probe_tile_count() and call it from xe_info_init(), which seems
like a more appropriate place for that.
With that move, we no longer need to (and shouldn't) adjust gt_count as
a part of xe_info_probe_tile_count(), as that field will be initialized
later in xe_info_init().
v4:
- Only probe for tile count if the default tile_count != 1 (just like
was done in mmio_multi_tile_setup()). (CI)
v3:
- Unchanged.
v2:
- Use KUnit static stub so that we do not try to query hardware when
running KUnit tests. (CI)
- Tweak last paragraph of commit message to make it clearer.
(Jonathan)
Reviewed-by: Jonathan Cavitt <jonathan.cavitt@intel.com>
Reviewed-by: Rodrigo Vivi <rodrigo.vivi@intel.com>
Link: https://lore.kernel.org/r/20250818-gt_count-improvements-v4-1-ee12870c6f57@intel.com
Signed-off-by: Gustavo Sousa <gustavo.sousa@intel.com>
Extend the "Disable NULL query for Anyhit Shader" tuning to Xe2
(graphics version 2000+) platforms, in addition to Xe3.
This sets the DIS_NULL_QUERY bit in RT_CTRL to disable null query
for Anyhit shaders on both Xe2 and Xe3.
This is a change in behavior that can regress a userspace not
prepared for it. However it's not feasible to change dynamically
the option per client or per exec queue via an opt-in flag. Mesa
is already prepared for that and it got propagated to their
stable versions. Even if it was possible, at this point adding a
flag would mean mesa would also need to propagate such a flag to
their stable versions, otherwise the previous fix would not be
used.
Signed-off-by: Nitin Gote <nitin.r.gote@intel.com>
Acked-by: Tapani Pälli <tapani.palli@intel.com>
Link: https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/35044
Reviewed-by: Lucas De Marchi <lucas.demarchi@intel.com>
Link: https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/35044
Link: https://lore.kernel.org/r/20250819061151.1272622-1-nitin.r.gote@intel.com
Signed-off-by: Lucas De Marchi <lucas.demarchi@intel.com>
Set the `support_hdcp` bit to enable the connector to register content
protection during initialization.
Signed-off-by: Hsin-Yi Wang <hsinyi@chromium.org>
Reviewed-by: Sean Paul <seanpaul@chromium.org>
Signed-off-by: Fei Shao <fshao@chromium.org>
Signed-off-by: Douglas Anderson <dianders@chromium.org>
Link: https://lore.kernel.org/r/20250812082135.3351172-3-fshao@chromium.org
Some bridges can update HDCP status based on userspace requests if they
support HDCP.
The HDCP property is created after connector initialization and before
registration, just like other connector properties.
Add the content protection property to the connector if a bridge
supports HDCP.
Signed-off-by: Hsin-Yi Wang <hsinyi@chromium.org>
Reviewed-by: Sean Paul <seanpaul@chromium.org>
Signed-off-by: Fei Shao <fshao@chromium.org>
Signed-off-by: Douglas Anderson <dianders@chromium.org>
Link: https://lore.kernel.org/r/20250812082135.3351172-2-fshao@chromium.org
Include <linux/property.h> to declare device_property_read_bool() and
<linux/mod_devicetable.h> to declare struct of_device_id. Avoids the
dependency on the backlight header to include both.
Signed-off-by: Thomas Zimmermann <tzimmermann@suse.de>
Reviewed-by: Neil Armstrong <neil.armstrong@linaro.org>
Link: https://lore.kernel.org/r/20250812082509.227879-1-tzimmermann@suse.de
The drm_gpusvm_for_each_notifier, drm_gpusvm_for_each_notifier_safe and
drm_gpusvm_for_each_range_safe macros are useful for locating notifiers
and ranges within a user-specified range. By making these macros public,
we enable broader access and utility for developers who need to leverage
them in their implementations.
v2 (Matthew Brost)
- drop inline __drm_gpusvm_range_find
- /s/notifier_iter_first/drm_gpusvm_notifier_find
Signed-off-by: Himal Prasad Ghimiray <himal.prasad.ghimiray@intel.com>
Reviewed-by: Matthew Brost <matthew.brost@intel.com>
Signed-off-by: Matthew Brost <matthew.brost@intel.com>
Link: https://lore.kernel.org/r/20250819162058.2777306-5-himal.prasad.ghimiray@intel.com
This ops is used to iterate over GPUVA's in the user-provided range
and split the existing sparse VMA's if the start or end of the input
range lies within it. The operations can create up to 2 REMAPS and 2 MAPs.
The primary use case is for drivers to assign attributes to GPU VAs in
the specified range without performing unmaps or merging mappings,
supporting fine-grained control over sparse va's.
Cc: Danilo Krummrich <dakr@kernel.org>
Cc: Matthew Brost <matthew.brost@intel.com>
Cc: Boris Brezillon <bbrezillon@kernel.org>
Cc: <dri-devel@lists.freedesktop.org>
Signed-off-by: Himal Prasad Ghimiray<himal.prasad.ghimiray@intel.com>
Reviewed-by: Matthew Brost <matthew.brost@intel.com>
Acked-by: Danilo Krummrich <dakr@kernel.org>
Signed-off-by: Matthew Brost <matthew.brost@intel.com>
Link: https://lore.kernel.org/r/20250819162058.2777306-4-himal.prasad.ghimiray@intel.com
drm_gpuva_init() only has one internal user, and given we are about to
add new optional fields, it only add maintenance burden for no real
benefit, so let's kill the thing now.
Cc: Danilo Krummrich <dakr@kernel.org>
Cc: Rob Clark <robin.clark@oss.qualcomm.com>
Signed-off-by: Boris Brezillon <boris.brezillon@collabora.com>
Acked-by: Danilo Krummrich <dakr@kernel.org>
Reviewed-by: Matthew Brost <matthew.brost@intel.com>
Signed-off-by: Himal Prasad Ghimiray <himal.prasad.ghimiray@intel.com>
Reviewed-by: Rob Clark <robin.clark@oss.qualcomm.com>
Signed-off-by: Matthew Brost <matthew.brost@intel.com>
Link: https://lore.kernel.org/r/20250819162058.2777306-3-himal.prasad.ghimiray@intel.com
We are about to pass more arguments to drm_gpuvm_sm_map[_ops_create](),
so, before we do that, let's pass arguments through a struct instead
of changing each call site every time a new optional argument is added.
Cc: Danilo Krummrich <dakr@kernel.org>
Cc: Brendan King <Brendan.King@imgtec.com>
Cc: Matt Coster <matt.coster@imgtec.com>
Cc: Boris Brezillon <bbrezillon@kernel.org>
Cc: Caterina Shablia <caterina.shablia@collabora.com>
Cc: Rob Clark <robin.clark@oss.qualcomm.com>
Cc: Matthew Brost <matthew.brost@intel.com>
Cc: <dri-devel@lists.freedesktop.org>
Co-developed-by: Himal Prasad Ghimiray <himal.prasad.ghimiray@intel.com>
Signed-off-by: Himal Prasad Ghimiray <himal.prasad.ghimiray@intel.com>
Signed-off-by: Boris Brezillon <boris.brezillon@collabora.com>
Acked-by: Danilo Krummrich <dakr@kernel.org>
Reviewed-by: Matthew Brost <matthew.brost@intel.com>
Reviewed-by: Rob Clark <robin.clark@oss.qualcomm.com>
Reviewed-by: Matt Coster <matt.coster@imgtec.com> # imagination/pvr_vm.c
Acked-by: Matt Coster <matt.coster@imgtec.com>
Signed-off-by: Matthew Brost <matthew.brost@intel.com>
Link: https://lore.kernel.org/r/20250819162058.2777306-2-himal.prasad.ghimiray@intel.com
Update call sites in drm to import `ARef` and
`AlwaysRefCounted` from `sync::aref` instead of `types`.
This aligns with the ongoing effort to move `ARef` and
`AlwaysRefCounted` to sync.
Suggested-by: Benno Lossin <lossin@kernel.org>
Link: https://github.com/Rust-for-Linux/linux/issues/1173
Signed-off-by: Shankari Anand <shankari.ak0208@gmail.com>
Reviewed-by: Benno Lossin <lossin@kernel.org>
Reviewed-by: Elle Rhumsaa <elle@weathered-steel.dev>
Link: https://lore.kernel.org/r/20250815161706.1324860-1-shankari.ak0208@gmail.com
Signed-off-by: Danilo Krummrich <dakr@kernel.org>
If PAGE_SIZE != XE_PAGE_SIZE (which is currently locked behind
CONFIG_BROKEN), this would generate the wrong number of PDEs.
Since these PDEs are consumed by the GPU, the GPU page size needs to be
used.
Signed-off-by: Simon Richter <Simon.Richter@hogyros.de>
Reviewed-by: Matthew Brost <matthew.brost@intel.com>
Signed-off-by: Matthew Brost <matthew.brost@intel.com>
Link: https://lore.kernel.org/r/20250818064806.2835-1-Simon.Richter@hogyros.de
Change the resource cleanup order to align with reverse allocation order.
Cc: Matthew Brost <matthew.brost@intel.com>
Signed-off-by: Christoph Manszewski <christoph.manszewski@intel.com>
Reviewed-by: Matthew Brost <matthew.brost@intel.com>
Signed-off-by: Matthew Brost <matthew.brost@intel.com>
Link: https://lore.kernel.org/r/20250813101231.196632-3-christoph.manszewski@intel.com
Walking hardware contexts created by a process is duplicated in multiple
spots. Add a function, amdxdna_hwctx_walk(), and replace all spots.
hwctx_srcu and dev_lock are good enough to protect hardware context list.
Remove hwctx_lock.
Reviewed-by: Mario Limonciello <mario.limonciello@amd.com>
Signed-off-by: Lizhi Hou <lizhi.hou@amd.com>
Link: https://lore.kernel.org/r/20250815171634.3417487-1-lizhi.hou@amd.com
VFs without native PCIe Power Management (PM) capabilities inherit their
PF's power state as per PCIe specifications(§5.10.1 PCIe Base Spec 7.0).
Enabling Runtime Power Management (RPM) for these VFs trigger unnecessary
driver suspend/resume operations that ultimately perform no PCI-level power
transition.
Since VFs without PM capabilities cannot independently enter low-power
states, the existing RPM workflow becomes redundant:
1. Driver executes full suspend/resume sequence
2. PCI PM transition step becomes no-op
3. VF power state remains tied to PF's status
Disabling RPM for VFs eliminates this redundant processing while
maintaining proper power management through PF dependency. This
optimization ensures VFs follow their PF's power state without superfluous
runtime handling.
Signed-off-by: Satyanarayana K V P <satyanarayana.k.v.p@intel.com>
Cc: Michal Wajdeczko <michal.wajdeczko@intel.com>
Cc: Matthew Brost <matthew.brost@intel.com>
Cc: Michał Winiarski <michal.winiarski@intel.com>
Cc: Anshuman Gupta <anshuman.gupta@intel.com>
Cc: Rodrigo Vivi <rodrigo.vivi@intel.com>
Cc: Maarten Lankhorst <dev@lankhorst.se>
Reviewed-by: Rodrigo Vivi <rodrigo.vivi@intel.com>
Link: https://lore.kernel.org/r/20250812163613.9954-1-satyanarayana.k.v.p@intel.com
Signed-off-by: Rodrigo Vivi <rodrigo.vivi@intel.com>
a fallback during cpuid helpers reorg
- Initialize reserved fields in the SVSM page validation calls structure
to zero in order to allow for future structure extensions
- Have the sev-guest driver's buffers used in encryption operations be
in linear mapping space as the encryption operation can be offloaded
to an accelerator
- Have a read-only MSR write when in an AMD SNP guest trap to the
hypervisor as it is usually done. This makes the guest user experience
better by simply raising a #GP instead of terminating said guest
- Do not output AVX512 elapsed time for kernel threads because the data
is wrong and fix a NULL pointer dereferencing in the process
- Adjust the SRSO mitigation selection to the new attack vectors
-----BEGIN PGP SIGNATURE-----
iQIzBAABCgAdFiEEzv7L6UO9uDPlPSfHEsHwGGHeVUoFAmihmPcACgkQEsHwGGHe
VUr6Iw/+KKuQdicPRvdQ8Kv+710oHFHka1CY/LdHuADuuzWWE+Zj6RzwraM0aqIr
1E4resu05MPVJj3KAzt0rBS4Ch5bbNU0QHQqhuuxe+EZpbY8XNxx53f43E4wHTS8
bPaZI1GdLZSTh5BUGRj9N0udK5gnd6kbku80PAbP2fqi+aSOZSA8JCqmiUicSi0/
EbYye7n38q8u1Dh2y9t9CBuxAOZEyzCM6LXRELmK5lya1LGJkKOTGllyb8irzsiv
HlLW1sN+weeVlvdUd1LvaYgTAetNhSVtiuh71cGMENnpoAyO6HAea+7X8Tg7UHHp
zsYRVXKg2CENQpo4OsQ3q/O7fnPTets7NFm8DNwSKO0qoCqn3Yf4AD4IeCIqZdM3
B2an4b1SWN2xtW38YEEGFVKIBIZVLQFzjmwR3yu8wqjhycIW3rNRCiQuI4EvW+ej
kx5ZXHXHKvThoLuxio/ILce1oWa4O9K+GzV9vEDHtYK283sCUU2XyUOVq3Ntpmoc
/mzOaBWAjN9nMWJ01DoPRh0bs5nkbN/NQxIOHUiOtLmMkwJX9ls/ed2VagL/iMq1
Sj1RZqkLEUYSHgE+HOToK8LXhbuDp6QEv1FUL/29pu1fzXRn5cn0PJx56+EKjJWO
f7b3NWMNGbbD/sIcYAtU73GVNnAOGzUkNA7AjDfmq+YoiC5G+LA=
=zsPJ
-----END PGP SIGNATURE-----
Merge tag 'x86_urgent_for_v6.17_rc2' of git://git.kernel.org/pub/scm/linux/kernel/git/tip/tip
Pull x86 fixes from Borislav Petkov:
- Remove a transitional asm/cpuid.h header which was added only as a
fallback during cpuid helpers reorg
- Initialize reserved fields in the SVSM page validation calls
structure to zero in order to allow for future structure extensions
- Have the sev-guest driver's buffers used in encryption operations be
in linear mapping space as the encryption operation can be offloaded
to an accelerator
- Have a read-only MSR write when in an AMD SNP guest trap to the
hypervisor as it is usually done. This makes the guest user
experience better by simply raising a #GP instead of terminating said
guest
- Do not output AVX512 elapsed time for kernel threads because the data
is wrong and fix a NULL pointer dereferencing in the process
- Adjust the SRSO mitigation selection to the new attack vectors
* tag 'x86_urgent_for_v6.17_rc2' of git://git.kernel.org/pub/scm/linux/kernel/git/tip/tip:
x86/cpuid: Remove transitional <asm/cpuid.h> header
x86/sev: Ensure SVSM reserved fields in a page validation entry are initialized to zero
virt: sev-guest: Satisfy linear mapping requirement in get_derived_key()
x86/sev: Improve handling of writes to intercepted TSC MSRs
x86/fpu: Fix NULL dereference in avx512_status()
x86/bugs: Select best SRSO mitigation
type of task so that they don't trigger falsely
- Use the write unsafe user access pairs when writing a futex value to prevent
an error on PowerPC which does user read and write accesses differently
-----BEGIN PGP SIGNATURE-----
iQIzBAABCgAdFiEEzv7L6UO9uDPlPSfHEsHwGGHeVUoFAmihlaAACgkQEsHwGGHe
VUrV7g/+Kx4n1TQuGnk4kd5h5q0uls8mgeFddYjv6BgVxcaWq7Tzv7XMJ5hvWEqp
P/+Zt43Sv9sd7i+PhoFD2Lr+EDYx8c0Lp08/LH0zsgKIA2Ai8ntJHJcb3se3Kxr5
yV23d0tkrCijcB58OL1xncm96Lp3XoXyTz8b0ahKDNG9mS8F/9XK9GgmG9OqKXDg
7T8Vx5NKt0YrvAWwvsQQlTUTcQ4a4O/UMwJmgEbvqHn0WwQISRxx/TE6wYuIwWAj
pbrN5kzDsZ6tA07h48NWnkFOEeqsQgbbKDkWvYYRYBrVzEATQBpBWfSQ0HsaqPmc
1Mk5Zs+J5UFhHx7Yw348JVqw5Fl4VDT4Oi4AoIzjBym3c73nrNfZzESRsf4dES5Q
DBsgTb0tjEZcR7MrWWErYu1LXw1qP5Ib39qLDVIvQQ4HomctSUuXVTIRL9qJvaCK
aCPt2Ivkhj3wItZSeTfzLTXbWE9lP4AhuBpJ4ALHRbOaCRLNfK9ZzLfOUyKePUvx
s3j7iPubfS5/lw192z5weLzEE4e8E7wIxSkIQNKLQFI/kr5YwKfwEO5Zm+UMfH5j
m+Hl7YKS0nT2IlFbRel2cSkw4MDaEJjgahMzbp+D0p+xV2H4KjY4nLoarwsuoP8D
GxLAOmRW1nzqj3QHIWsBF9iBxkO89lshWOgGxhUbhtywNqxSV6M=
=q1tX
-----END PGP SIGNATURE-----
Merge tag 'locking_urgent_for_v6.17_rc2' of git://git.kernel.org/pub/scm/linux/kernel/git/tip/tip
Pull locking fixes from Borislav Petkov:
- Make sure sanity checks down in the mutex lock path happen on the
correct type of task so that they don't trigger falsely
- Use the write unsafe user access pairs when writing a futex value to
prevent an error on PowerPC which does user read and write accesses
differently
* tag 'locking_urgent_for_v6.17_rc2' of git://git.kernel.org/pub/scm/linux/kernel/git/tip/tip:
locking: Fix __clear_task_blocked_on() warning from __ww_mutex_wound() path
futex: Use user_write_access_begin/_end() in futex_put_value()
Toolchain and infrastructure:
- Workaround 'rustdoc' target modifiers bug in Rust >= 1.88.0. It will
be fixed in Rust 1.90.0 (expected 2025-09-18).
- Clean 'rustdoc' output before running it to avoid confusing the tool
when files from previous versions remain.
-----BEGIN PGP SIGNATURE-----
iQIzBAABCgAdFiEEPjU5OPd5QIZ9jqqOGXyLc2htIW0FAmig+UEACgkQGXyLc2ht
IW1s4RAAzT1MCd+CMXfPFyVQnsyXblCa5I3UWhE0+T2nPlicdQqD8NmmkvsxyGLB
SpoZnYk1yDl9L0wxx7Bw/elGeaoIf/EDqsF2Jl7jg9czhWuQhUTsnHemhw93gaOW
uCpCUduiTRlZH3Zp2jCQ7rglXdbAzWTPhyCOTJ5oxn3XTj9GL5iFE8iCea2/vjgV
sYf9GMkwy6I1+HmLsf7rhKVtrt+vozI8PVTXiPX1OlYpRBH0VjmRwjHIDJiGL1qU
FO0AZzNJqZ8yctheCvTJLxezf2SWXxgMaRuEPY7dEXNvyf7LcmXcxvnAnuQbbh0v
7wWTRd427bcKLG4NQ6Mqs1bB53YrgC/qfnSgczAtmULXTYoKHq26Ei6bUG2RnBr6
Br534xF1o1k71Fi5vebtbaGRoLAQFVSB1eTU+iaSZy01YZAevqP4+Ot2Y4NntJtP
CYnU9cUMZiWIOa42RnBI0YHOtdW7QeNSKKIAH2eT1GTB2bbqUtWuioN67jbHG3uq
kt3q7Mu8BwLoH6x6/vkPVW9KKahK5LMlB/uOspZhoaEHeGLO7JluoRwc0+EWV8Zm
QOaCB+lQC1gsEJTmNt0SaexYc7T2ml7zh8uXf+7jXOPzJ1UGUtCXq74un5kkYSOG
CKMmDKAhZa76BwSiFhlrYKlKBxhnYatyzQKXxe6u7caKoJAixfc=
=uT2O
-----END PGP SIGNATURE-----
Merge tag 'rust-fixes-6.17' of git://git.kernel.org/pub/scm/linux/kernel/git/ojeda/linux
Pull rust fixes from Miguel Ojeda:
- Workaround 'rustdoc' target modifiers bug in Rust >= 1.88.0. It will
be fixed in Rust 1.90.0 (expected 2025-09-18).
- Clean 'rustdoc' output before running it to avoid confusing the tool
when files from previous versions remain.
* tag 'rust-fixes-6.17' of git://git.kernel.org/pub/scm/linux/kernel/git/ojeda/linux:
rust: kbuild: clean output before running `rustdoc`
rust: workaround `rustdoc` target modifiers bug
- Fix a regression affecting old IDE/PATA device scan and introduced by
the recent link power management cleanups & fixes. The regression
prevented devices from being properly detected (me).
- Fix command duration limits (CDL) feature control: attempting to
enable the feature while NCQ commands are being executed resulted in
a silent failure to enable CDL when needed (Igor).
-----BEGIN PGP SIGNATURE-----
iHUEABYKAB0WIQSRPv8tYSvhwAzJdzjdoc3SxdoYdgUCaKB5NgAKCRDdoc3SxdoY
dmb0AQDGsKNEgAB4tY6e0dkqmp6j0TbcfqT38sizQrOHQKXbQwD8Cq/SdMxsWvjq
4gWan4AiQmCBR5plwuFmeZ5XXuLSdgU=
=2Hgt
-----END PGP SIGNATURE-----
Merge tag 'ata-ata-6.17-rc2' of git://git.kernel.org/pub/scm/linux/kernel/git/libata/linux
Pull ata fixes from Damien Le Moal:
- Fix a regression affecting old IDE/PATA device scan and introduced by
the recent link power management cleanups & fixes. The regression
prevented devices from being properly detected (me)
- Fix command duration limits (CDL) feature control: attempting to
enable the feature while NCQ commands are being executed resulted in
a silent failure to enable CDL when needed (Igor)
* tag 'ata-ata-6.17-rc2' of git://git.kernel.org/pub/scm/linux/kernel/git/libata/linux:
ata: libata-scsi: Fix CDL control
ata: libata-eh: Fix link state check for IDE/PATA ports
