drm/xe/pxp/uapi: Add userspace and LRC support for PXP-using queues

Userspace is required to mark a queue as using PXP to guarantee that the
PXP instructions will work. In addition to managing the P

drm/xe/pxp/uapi: Add userspace and LRC support for PXP-using queues

Userspace is required to mark a queue as using PXP to guarantee that the
PXP instructions will work. In addition to managing the PXP sessions,
when a PXP queue is created the driver will set the relevant bits in
its context control register.

On submission of a valid PXP queue, the driver will validate all
encrypted objects mapped to the VM to ensured they were encrypted with
the current key.

v2: Remove pxp_types include outside of PXP code (Jani), better comments
and code cleanup (John)

v3: split the internal PXP management to a separate patch for ease of
review. re-order ioctl checks to always return -EINVAL if parameters are
invalid, rebase on msix changes.

Signed-off-by: Daniele Ceraolo Spurio <[email protected]>
Cc: John Harrison <[email protected]>
Reviewed-by: John Harrison <[email protected]>
Link: https://patchwork.freedesktop.org/patch/msgid/[email protected]

show more ...

drm/xe/exec_queue: Prepare last fence for hw engine group resume context

Ensure we can safely take a ref of the exec queue's last fence from the
context of resuming jobs from the hw engine group. Th

drm/xe/exec_queue: Prepare last fence for hw engine group resume context

Ensure we can safely take a ref of the exec queue's last fence from the
context of resuming jobs from the hw engine group. The locking requirements
differ from the general case, hence the introduction of this new function.

v2: Add kernel doc, rework the code to prevent code duplication

v3: Fix kernel doc, remove now unnecessary lockdep variants (Matt Brost)

v4: Remove new put function (Matt Brost)

Signed-off-by: Francois Dugast <[email protected]>
Reviewed-by: Matthew Brost <[email protected]>
Signed-off-by: Matthew Brost <[email protected]>
Link: https://patchwork.freedesktop.org/patch/msgid/[email protected]

show more ...

drm/xe: Use reserved copy engine for user binds on faulting devices

User binds map to engines with can fault, faults depend on user binds
completion, thus we can deadlock. Avoid this by using reserv

drm/xe: Use reserved copy engine for user binds on faulting devices

User binds map to engines with can fault, faults depend on user binds
completion, thus we can deadlock. Avoid this by using reserved copy
engine for user binds on faulting devices.

While we are here, normalize bind queue creation with a helper.

v2:
- Pass in extensions to bind queue creation (CI)
v3:
- s/resevered/reserved (Lucas)
- Fix NULL hwe check (Jonathan)

Fixes: dd08ebf6c352 ("drm/xe: Introduce a new DRM driver for Intel GPUs")
Cc: Thomas Hellström <[email protected]>
Signed-off-by: Matthew Brost <[email protected]>
Reviewed-by: Jonathan Cavitt <[email protected]>
Link: https://patchwork.freedesktop.org/patch/msgid/[email protected]

show more ...

drm/xe: Add xe_exec_queue_last_fence_test_dep

Helpful to determine if a bind can immediately use CPU or needs to be
deferred a drm scheduler job.

v7:
- Better wording in kernel doc (Matthew Auld)

drm/xe: Add xe_exec_queue_last_fence_test_dep

Helpful to determine if a bind can immediately use CPU or needs to be
deferred a drm scheduler job.

v7:
- Better wording in kernel doc (Matthew Auld)

Signed-off-by: Matthew Brost <[email protected]>
Reviewed-by: Matthew Auld <[email protected]>
Link: https://patchwork.freedesktop.org/patch/msgid/[email protected]

show more ...

drm/xe: Use run_ticks instead of runtime for client stats

Note that runtime is also used in the pm context, so it is confusing to
use the same name to denote run time of the drm client. Use a more
a

drm/xe: Use run_ticks instead of runtime for client stats

Note that runtime is also used in the pm context, so it is confusing to
use the same name to denote run time of the drm client. Use a more
appropriate name for the client utilization.

While at it, drop the incorrect multi-lrc comment in the helper
description

v2: s/show_runtime/show_run_ticks/ (Rodrigo)

Signed-off-by: Umesh Nerlige Ramappa <[email protected]>
Reviewed-by: Rodrigo Vivi <[email protected]>
Link: https://patchwork.freedesktop.org/patch/msgid/[email protected]

show more ...

drm/xe: Add helper to accumulate exec queue runtime

Add a helper to accumulate per-client runtime of all its
exec queues. This is called every time a sched job is finished.

v2:
- Use guc_exec_que

drm/xe: Add helper to accumulate exec queue runtime

Add a helper to accumulate per-client runtime of all its
exec queues. This is called every time a sched job is finished.

v2:
- Use guc_exec_queue_free_job() and execlist_job_free() to accumulate
runtime when job is finished since xe_sched_job_completed() is not a
notification that job finished.
- Stop trying to update runtime from xe_exec_queue_fini() - that is
redundant and may happen after xef is closed, leading to a
use-after-free
- Do not special case the first timestamp read: the default LRC sets
CTX_TIMESTAMP to zero, so even the first sample should be a valid
one.
- Handle the parallel submission case by multiplying the runtime by
width.
v3: Update comments

Signed-off-by: Umesh Nerlige Ramappa <[email protected]>
Reviewed-by: Matt Roper <[email protected]>
Link: https://patchwork.freedesktop.org/patch/msgid/[email protected]
Signed-off-by: Lucas De Marchi <[email protected]>

show more ...

drm/xe: Force wedged state and block GT reset upon any GPU hang

In many validation situations when debugging GPU Hangs,
it is useful to preserve the GT situation from the moment
that the timeout occ

drm/xe: Force wedged state and block GT reset upon any GPU hang

In many validation situations when debugging GPU Hangs,
it is useful to preserve the GT situation from the moment
that the timeout occurred.

This patch introduces a module parameter that could be used
on situations like this.

If xe.wedged module parameter is set to 2, Xe will be declared
wedged on every single execution timeout (a.k.a. GPU hang) right
after devcoredump snapshot capture and without attempting any
kind of GT reset and blocking entirely any kind of execution.

v2: Really block gt_reset from guc side. (Lucas)
s/wedged/busted (Lucas)

v3: - s/busted/wedged
- Really use global_flags (Dafna)
- More robust timeout handling when wedging it.

v4: A really robust clean exit done by Matt Brost.
No more kernel warns on unbind.

v5: Simplify error message (Lucas)

Cc: Matthew Brost <[email protected]>
Cc: Dafna Hirschfeld <[email protected]>
Cc: Lucas De Marchi <[email protected]>
Cc: Alan Previn <[email protected]>
Cc: Himanshu Somaiya <[email protected]>
Reviewed-by: Lucas De Marchi <[email protected]>
Link: https://patchwork.freedesktop.org/patch/msgid/[email protected]
Signed-off-by: Rodrigo Vivi <[email protected]>

show more ...

drm/xe: Finish refactoring of exec_queue_create

Setting of exec_queue user extensions is moved from the end of the ioctl
function earlier, into __xe_exec_queue_alloc().
This fixes bug in that the US

drm/xe: Finish refactoring of exec_queue_create

Setting of exec_queue user extensions is moved from the end of the ioctl
function earlier, into __xe_exec_queue_alloc().
This fixes bug in that the USM attributes for access counters were being
applied too late, and effectively were ignored.

However, in order to apply user extensions this early, we can no longer
call q->ops functions. Instead, make it more efficient. The user extension
functions can simply update the q->sched_props values and they will be
applied by the backend during q->ops->init().

v2: minor changes for readability (Matt)

Signed-off-by: Brian Welty <[email protected]>
Signed-off-by: Matthew Brost <[email protected]>
Reviewed-by: Matthew Brost <[email protected]>

show more ...

drm/xe/uapi: Kill exec_queue_set_property

All the properties should be immutable and set upon exec_queue creation
using the existent extension. So, let's kill this useless and dangerous
uapi.

Cc: F

drm/xe/uapi: Kill exec_queue_set_property

All the properties should be immutable and set upon exec_queue creation
using the existent extension. So, let's kill this useless and dangerous
uapi.

Cc: Francois Dugast <[email protected]>
Cc: José Roberto de Souza <[email protected]>
Cc: Matthew Brost <[email protected]>
Signed-off-by: Rodrigo Vivi <[email protected]>
Reviewed-by: José Roberto de Souza <[email protected]>
Signed-off-by: Francois Dugast <[email protected]>

show more ...

drm/xe: Fix VM bind out-sync signaling ordering

A case existed where an out-sync of a later VM bind operation could
signal before a previous one if the later operation results in a NOP
(e.g. a unbin

drm/xe: Fix VM bind out-sync signaling ordering

A case existed where an out-sync of a later VM bind operation could
signal before a previous one if the later operation results in a NOP
(e.g. a unbind or prefetch to a VA range without any mappings). This
breaks the ordering rules, fix this. This patch also lays the groundwork
for users to pass in num_binds == 0 and out-syncs.

Signed-off-by: Matthew Brost <[email protected]>
Reviewed-by: Thomas Hellström <[email protected]>
Signed-off-by: Rodrigo Vivi <[email protected]>

show more ...

drm/xe: common function to assign queue name

The queue name assignment is identical in both GuC and execlists
backends, so we can move it to a common function. This will make adding
a new entry in t

drm/xe: common function to assign queue name

The queue name assignment is identical in both GuC and execlists
backends, so we can move it to a common function. This will make adding
a new entry in the next patch slightly cleaner.

Signed-off-by: Daniele Ceraolo Spurio <[email protected]>
Reviewed-by: Matt Roper <[email protected]>
Link: https://lore.kernel.org/r/[email protected]
Signed-off-by: Rodrigo Vivi <[email protected]>

show more ...

drm/xe: Rename engine to exec_queue

Engine was inappropriately used to refer to execution queues and it
also created some confusion with hardware engines. Where it applies
the exec_queue variable na

drm/xe: Rename engine to exec_queue

Engine was inappropriately used to refer to execution queues and it
also created some confusion with hardware engines. Where it applies
the exec_queue variable name is changed to q and comments are also
updated.

Link: https://gitlab.freedesktop.org/drm/xe/kernel/-/issues/162
Signed-off-by: Francois Dugast <[email protected]>
Reviewed-by: Rodrigo Vivi <[email protected]>
Signed-off-by: Rodrigo Vivi <[email protected]>

show more ...

drm/xe: Rename xe_engine.[ch] to xe_exec_queue.[ch]

This is a preparation commit for a larger renaming of engine to exec queue.

Signed-off-by: Francois Dugast <[email protected]>
Reviewed-b

drm/xe: Rename xe_engine.[ch] to xe_exec_queue.[ch]

This is a preparation commit for a larger renaming of engine to exec queue.

Signed-off-by: Francois Dugast <[email protected]>
Reviewed-by: Rodrigo Vivi <[email protected]>
Signed-off-by: Rodrigo Vivi <[email protected]>

show more ...