2017-02-13 17:15:19 +00:00
|
|
|
/*
|
2019-05-28 10:29:49 +01:00
|
|
|
* SPDX-License-Identifier: MIT
|
2017-02-13 17:15:19 +00:00
|
|
|
*
|
2019-05-28 10:29:49 +01:00
|
|
|
* Copyright © 2016 Intel Corporation
|
2017-02-13 17:15:19 +00:00
|
|
|
*/
|
|
|
|
|
2022-02-10 17:45:47 +02:00
|
|
|
#include "i915_file_private.h"
|
2017-02-13 17:15:19 +00:00
|
|
|
#include "mock_context.h"
|
2019-11-07 21:39:29 +00:00
|
|
|
#include "selftests/mock_drm.h"
|
2019-05-28 10:29:49 +01:00
|
|
|
#include "selftests/mock_gtt.h"
|
2017-02-13 17:15:19 +00:00
|
|
|
|
|
|
|
struct i915_gem_context *
|
|
|
|
mock_context(struct drm_i915_private *i915,
|
|
|
|
const char *name)
|
|
|
|
{
|
|
|
|
struct i915_gem_context *ctx;
|
2019-04-26 17:33:34 +01:00
|
|
|
struct i915_gem_engines *e;
|
2021-07-08 10:48:23 -05:00
|
|
|
struct intel_sseu null_sseu = {};
|
2017-02-13 17:15:19 +00:00
|
|
|
|
|
|
|
ctx = kzalloc(sizeof(*ctx), GFP_KERNEL);
|
|
|
|
if (!ctx)
|
|
|
|
return NULL;
|
|
|
|
|
|
|
|
kref_init(&ctx->ref);
|
|
|
|
INIT_LIST_HEAD(&ctx->link);
|
|
|
|
ctx->i915 = i915;
|
2021-09-02 16:20:47 +02:00
|
|
|
INIT_WORK(&ctx->release_work, i915_gem_context_release_work);
|
2017-02-13 17:15:19 +00:00
|
|
|
|
2020-07-03 01:43:06 +01:00
|
|
|
mutex_init(&ctx->mutex);
|
|
|
|
|
2020-03-03 08:05:44 +00:00
|
|
|
spin_lock_init(&ctx->stale.lock);
|
|
|
|
INIT_LIST_HEAD(&ctx->stale.engines);
|
|
|
|
|
drm/i915/gem: Make context persistence optional
Our existing behaviour is to allow contexts and their GPU requests to
persist past the point of closure until the requests are complete. This
allows clients to operate in a 'fire-and-forget' manner where they can
setup a rendering pipeline and hand it over to the display server and
immediately exit. As the rendering pipeline is kept alive until
completion, the display server (or other consumer) can use the results
in the future and present them to the user.
The compute model is a little different. They have little to no buffer
sharing between processes as their kernels tend to operate on a
continuous stream, feeding the results back to the client application.
These kernels operate for an indeterminate length of time, with many
clients wishing that the kernel was always running for as long as they
keep feeding in the data, i.e. acting like a DSP.
Not all clients want this persistent "desktop" behaviour and would prefer
that the contexts are cleaned up immediately upon closure. This ensures
that when clients are run without hangchecking (e.g. for compute kernels
of indeterminate runtime), any GPU hang or other unexpected workloads
are terminated with the process and does not continue to hog resources.
The default behaviour for new contexts is the legacy persistence mode,
as some desktop applications are dependent upon the existing behaviour.
New clients will have to opt in to immediate cleanup on context
closure. If the hangchecking modparam is disabled, so is persistent
context support -- all contexts will be terminated on closure.
We expect this behaviour change to be welcomed by compute users, who
have often been caught between a rock and a hard place. They disable
hangchecking to avoid their kernels being "unfairly" declared hung, but
have also experienced true hangs that the system was then unable to
clean up. Naturally, this leads to bug reports.
Testcase: igt/gem_ctx_persistence
Link: https://github.com/intel/compute-runtime/pull/228
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Cc: Joonas Lahtinen <joonas.lahtinen@linux.intel.com>
Cc: Michał Winiarski <michal.winiarski@intel.com>
Cc: Jon Bloomfield <jon.bloomfield@intel.com>
Reviewed-by: Jon Bloomfield <jon.bloomfield@intel.com>
Reviewed-by: Tvrtko Ursulin <tvrtko.ursulin@intel.com>
Reviewed-by: Joonas Lahtinen <joonas.lahtinen@linux.intel.com>
Acked-by: Jason Ekstrand <jason@jlekstrand.net>
Link: https://patchwork.freedesktop.org/patch/msgid/20191029202338.8841-1-chris@chris-wilson.co.uk
2019-10-29 20:23:38 +00:00
|
|
|
i915_gem_context_set_persistence(ctx);
|
|
|
|
|
2017-02-13 17:15:19 +00:00
|
|
|
if (name) {
|
2019-06-11 10:12:38 +01:00
|
|
|
struct i915_ppgtt *ppgtt;
|
2019-03-22 09:23:23 +00:00
|
|
|
|
2023-09-19 04:45:31 +00:00
|
|
|
strscpy(ctx->name, name, sizeof(ctx->name));
|
2017-02-13 17:15:19 +00:00
|
|
|
|
2019-03-22 09:23:23 +00:00
|
|
|
ppgtt = mock_ppgtt(i915, name);
|
|
|
|
if (!ppgtt)
|
2021-07-08 10:48:34 -05:00
|
|
|
goto err_free;
|
2019-10-04 14:40:09 +01:00
|
|
|
|
2022-03-04 09:26:39 +01:00
|
|
|
ctx->vm = &ppgtt->vm;
|
2017-02-13 17:15:19 +00:00
|
|
|
}
|
|
|
|
|
2021-07-08 10:48:34 -05:00
|
|
|
mutex_init(&ctx->engines_mutex);
|
|
|
|
e = default_engines(ctx, null_sseu);
|
|
|
|
if (IS_ERR(e))
|
|
|
|
goto err_vm;
|
|
|
|
RCU_INIT_POINTER(ctx->engines, e);
|
|
|
|
|
|
|
|
INIT_RADIX_TREE(&ctx->handles_vma, GFP_KERNEL);
|
|
|
|
mutex_init(&ctx->lut_mutex);
|
|
|
|
|
2017-02-13 17:15:19 +00:00
|
|
|
return ctx;
|
|
|
|
|
2021-07-08 10:48:34 -05:00
|
|
|
err_vm:
|
|
|
|
if (ctx->vm)
|
2022-03-04 09:26:39 +01:00
|
|
|
i915_vm_put(ctx->vm);
|
2019-04-26 17:33:34 +01:00
|
|
|
err_free:
|
2017-02-13 17:15:19 +00:00
|
|
|
kfree(ctx);
|
|
|
|
return NULL;
|
|
|
|
}
|
|
|
|
|
|
|
|
void mock_context_close(struct i915_gem_context *ctx)
|
|
|
|
{
|
2017-10-12 13:57:26 +01:00
|
|
|
context_close(ctx);
|
2017-02-13 17:15:19 +00:00
|
|
|
}
|
2017-06-20 12:05:46 +01:00
|
|
|
|
|
|
|
void mock_init_contexts(struct drm_i915_private *i915)
|
|
|
|
{
|
2019-10-04 14:40:09 +01:00
|
|
|
init_contexts(&i915->gem.contexts);
|
2017-06-20 12:05:46 +01:00
|
|
|
}
|
2017-07-21 13:32:34 +01:00
|
|
|
|
|
|
|
struct i915_gem_context *
|
2019-11-07 21:39:29 +00:00
|
|
|
live_context(struct drm_i915_private *i915, struct file *file)
|
2017-07-21 13:32:34 +01:00
|
|
|
{
|
drm/i915/gem: Delay context creation (v3)
The current context uAPI allows for two methods of setting context
parameters: SET_CONTEXT_PARAM and CONTEXT_CREATE_EXT_SETPARAM. The
former is allowed to be called at any time while the later happens as
part of GEM_CONTEXT_CREATE. Currently, everything settable via one is
settable via the other. While some params are fairly simple and setting
them on a live context is harmless such as the context priority, others
are far trickier such as the VM or the set of engines. In order to swap
out the VM, for instance, we have to delay until all current in-flight
work is complete, swap in the new VM, and then continue. This leads to
a plethora of potential race conditions we'd really rather avoid.
In previous patches, we added a i915_gem_proto_context struct which is
capable of storing and tracking all such create parameters. This commit
delays the creation of the actual context until after the client is done
configuring it with SET_CONTEXT_PARAM. From the perspective of the
client, it has the same u32 context ID the whole time. From the
perspective of i915, however, it's an i915_gem_proto_context right up
until the point where we attempt to do something which the proto-context
can't handle. Then the real context gets created.
This is accomplished via a little xarray dance. When GEM_CONTEXT_CREATE
is called, we create a proto-context, reserve a slot in context_xa but
leave it NULL, the proto-context in the corresponding slot in
proto_context_xa. Then, whenever we go to look up a context, we first
check context_xa. If it's there, we return the i915_gem_context and
we're done. If it's not, we look in proto_context_xa and, if we find it
there, we create the actual context and kill the proto-context.
In order for this dance to work properly, everything which ever touches
a proto-context is guarded by drm_i915_file_private::proto_context_lock,
including context creation. Yes, this means context creation now takes
a giant global lock but it can't really be helped and that should never
be on any driver's fast-path anyway.
v2 (Daniel Vetter):
- Commit message grammatical fixes.
- Use WARN_ON instead of GEM_BUG_ON
- Rename lazy_create_context_locked to finalize_create_context_locked
- Rework the control-flow logic in the setparam ioctl
- Better documentation all around
v3 (kernel test robot):
- Make finalize_create_context_locked static
Signed-off-by: Jason Ekstrand <jason@jlekstrand.net>
Reviewed-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Link: https://patchwork.freedesktop.org/patch/msgid/20210708154835.528166-25-jason@jlekstrand.net
2021-07-08 10:48:29 -05:00
|
|
|
struct drm_i915_file_private *fpriv = to_drm_file(file)->driver_priv;
|
2021-07-08 10:48:21 -05:00
|
|
|
struct i915_gem_proto_context *pc;
|
2019-03-21 14:07:08 +00:00
|
|
|
struct i915_gem_context *ctx;
|
|
|
|
int err;
|
2019-12-24 09:59:20 +00:00
|
|
|
u32 id;
|
2019-03-21 14:07:08 +00:00
|
|
|
|
2023-11-07 10:18:02 +00:00
|
|
|
pc = proto_context_create(fpriv, i915, 0);
|
2021-07-08 10:48:21 -05:00
|
|
|
if (IS_ERR(pc))
|
|
|
|
return ERR_CAST(pc);
|
|
|
|
|
|
|
|
ctx = i915_gem_create_context(i915, pc);
|
2021-09-24 12:14:45 -07:00
|
|
|
proto_context_close(i915, pc);
|
2019-03-21 14:07:08 +00:00
|
|
|
if (IS_ERR(ctx))
|
|
|
|
return ctx;
|
|
|
|
|
2020-01-28 11:34:26 +00:00
|
|
|
i915_gem_context_set_no_error_capture(ctx);
|
|
|
|
|
drm/i915/gem: Delay context creation (v3)
The current context uAPI allows for two methods of setting context
parameters: SET_CONTEXT_PARAM and CONTEXT_CREATE_EXT_SETPARAM. The
former is allowed to be called at any time while the later happens as
part of GEM_CONTEXT_CREATE. Currently, everything settable via one is
settable via the other. While some params are fairly simple and setting
them on a live context is harmless such as the context priority, others
are far trickier such as the VM or the set of engines. In order to swap
out the VM, for instance, we have to delay until all current in-flight
work is complete, swap in the new VM, and then continue. This leads to
a plethora of potential race conditions we'd really rather avoid.
In previous patches, we added a i915_gem_proto_context struct which is
capable of storing and tracking all such create parameters. This commit
delays the creation of the actual context until after the client is done
configuring it with SET_CONTEXT_PARAM. From the perspective of the
client, it has the same u32 context ID the whole time. From the
perspective of i915, however, it's an i915_gem_proto_context right up
until the point where we attempt to do something which the proto-context
can't handle. Then the real context gets created.
This is accomplished via a little xarray dance. When GEM_CONTEXT_CREATE
is called, we create a proto-context, reserve a slot in context_xa but
leave it NULL, the proto-context in the corresponding slot in
proto_context_xa. Then, whenever we go to look up a context, we first
check context_xa. If it's there, we return the i915_gem_context and
we're done. If it's not, we look in proto_context_xa and, if we find it
there, we create the actual context and kill the proto-context.
In order for this dance to work properly, everything which ever touches
a proto-context is guarded by drm_i915_file_private::proto_context_lock,
including context creation. Yes, this means context creation now takes
a giant global lock but it can't really be helped and that should never
be on any driver's fast-path anyway.
v2 (Daniel Vetter):
- Commit message grammatical fixes.
- Use WARN_ON instead of GEM_BUG_ON
- Rename lazy_create_context_locked to finalize_create_context_locked
- Rework the control-flow logic in the setparam ioctl
- Better documentation all around
v3 (kernel test robot):
- Make finalize_create_context_locked static
Signed-off-by: Jason Ekstrand <jason@jlekstrand.net>
Reviewed-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Link: https://patchwork.freedesktop.org/patch/msgid/20210708154835.528166-25-jason@jlekstrand.net
2021-07-08 10:48:29 -05:00
|
|
|
err = xa_alloc(&fpriv->context_xa, &id, NULL, xa_limit_32b, GFP_KERNEL);
|
2019-03-21 14:07:10 +00:00
|
|
|
if (err < 0)
|
2019-03-21 14:07:08 +00:00
|
|
|
goto err_ctx;
|
|
|
|
|
drm/i915/gem: Delay context creation (v3)
The current context uAPI allows for two methods of setting context
parameters: SET_CONTEXT_PARAM and CONTEXT_CREATE_EXT_SETPARAM. The
former is allowed to be called at any time while the later happens as
part of GEM_CONTEXT_CREATE. Currently, everything settable via one is
settable via the other. While some params are fairly simple and setting
them on a live context is harmless such as the context priority, others
are far trickier such as the VM or the set of engines. In order to swap
out the VM, for instance, we have to delay until all current in-flight
work is complete, swap in the new VM, and then continue. This leads to
a plethora of potential race conditions we'd really rather avoid.
In previous patches, we added a i915_gem_proto_context struct which is
capable of storing and tracking all such create parameters. This commit
delays the creation of the actual context until after the client is done
configuring it with SET_CONTEXT_PARAM. From the perspective of the
client, it has the same u32 context ID the whole time. From the
perspective of i915, however, it's an i915_gem_proto_context right up
until the point where we attempt to do something which the proto-context
can't handle. Then the real context gets created.
This is accomplished via a little xarray dance. When GEM_CONTEXT_CREATE
is called, we create a proto-context, reserve a slot in context_xa but
leave it NULL, the proto-context in the corresponding slot in
proto_context_xa. Then, whenever we go to look up a context, we first
check context_xa. If it's there, we return the i915_gem_context and
we're done. If it's not, we look in proto_context_xa and, if we find it
there, we create the actual context and kill the proto-context.
In order for this dance to work properly, everything which ever touches
a proto-context is guarded by drm_i915_file_private::proto_context_lock,
including context creation. Yes, this means context creation now takes
a giant global lock but it can't really be helped and that should never
be on any driver's fast-path anyway.
v2 (Daniel Vetter):
- Commit message grammatical fixes.
- Use WARN_ON instead of GEM_BUG_ON
- Rename lazy_create_context_locked to finalize_create_context_locked
- Rework the control-flow logic in the setparam ioctl
- Better documentation all around
v3 (kernel test robot):
- Make finalize_create_context_locked static
Signed-off-by: Jason Ekstrand <jason@jlekstrand.net>
Reviewed-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Link: https://patchwork.freedesktop.org/patch/msgid/20210708154835.528166-25-jason@jlekstrand.net
2021-07-08 10:48:29 -05:00
|
|
|
gem_context_register(ctx, fpriv, id);
|
|
|
|
|
2019-03-21 14:07:08 +00:00
|
|
|
return ctx;
|
|
|
|
|
|
|
|
err_ctx:
|
|
|
|
context_close(ctx);
|
|
|
|
return ERR_PTR(err);
|
2017-07-21 13:32:34 +01:00
|
|
|
}
|
2018-02-05 15:24:29 +00:00
|
|
|
|
|
|
|
struct i915_gem_context *
|
2021-07-08 10:48:32 -05:00
|
|
|
kernel_context(struct drm_i915_private *i915,
|
|
|
|
struct i915_address_space *vm)
|
2018-02-05 15:24:29 +00:00
|
|
|
{
|
2019-12-21 16:03:24 +00:00
|
|
|
struct i915_gem_context *ctx;
|
2021-07-08 10:48:21 -05:00
|
|
|
struct i915_gem_proto_context *pc;
|
|
|
|
|
2023-11-07 10:18:02 +00:00
|
|
|
pc = proto_context_create(NULL, i915, 0);
|
2021-07-08 10:48:21 -05:00
|
|
|
if (IS_ERR(pc))
|
|
|
|
return ERR_CAST(pc);
|
2019-12-21 16:03:24 +00:00
|
|
|
|
2021-07-08 10:48:32 -05:00
|
|
|
if (vm) {
|
|
|
|
if (pc->vm)
|
|
|
|
i915_vm_put(pc->vm);
|
|
|
|
pc->vm = i915_vm_get(vm);
|
|
|
|
}
|
|
|
|
|
2021-07-08 10:48:21 -05:00
|
|
|
ctx = i915_gem_create_context(i915, pc);
|
2021-09-24 12:14:45 -07:00
|
|
|
proto_context_close(i915, pc);
|
2019-12-21 16:03:24 +00:00
|
|
|
if (IS_ERR(ctx))
|
|
|
|
return ctx;
|
|
|
|
|
|
|
|
i915_gem_context_clear_bannable(ctx);
|
|
|
|
i915_gem_context_set_persistence(ctx);
|
2020-02-09 23:08:35 +00:00
|
|
|
i915_gem_context_set_no_error_capture(ctx);
|
2019-12-21 16:03:24 +00:00
|
|
|
|
|
|
|
return ctx;
|
2018-02-05 15:24:29 +00:00
|
|
|
}
|
|
|
|
|
|
|
|
void kernel_context_close(struct i915_gem_context *ctx)
|
|
|
|
{
|
|
|
|
context_close(ctx);
|
|
|
|
}
|