2019-08-02 17:00:15 +07:00
|
|
|
/*
|
|
|
|
* SPDX-License-Identifier: GPL-2.0
|
|
|
|
*
|
|
|
|
* Copyright © 2019 Intel Corporation
|
|
|
|
*/
|
|
|
|
|
|
|
|
#include "i915_selftest.h"
|
2019-11-15 22:08:40 +07:00
|
|
|
#include "intel_engine_heartbeat.h"
|
2019-08-17 14:37:11 +07:00
|
|
|
#include "intel_engine_pm.h"
|
2019-08-02 17:00:15 +07:00
|
|
|
#include "intel_gt.h"
|
|
|
|
|
|
|
|
#include "gem/selftests/mock_context.h"
|
|
|
|
#include "selftests/igt_flush_test.h"
|
|
|
|
#include "selftests/mock_drm.h"
|
|
|
|
|
|
|
|
static int request_sync(struct i915_request *rq)
|
|
|
|
{
|
drm/i915: Mark i915_request.timeline as a volatile, rcu pointer
The request->timeline is only valid until the request is retired (i.e.
before it is completed). Upon retiring the request, the context may be
unpinned and freed, and along with it the timeline may be freed. We
therefore need to be very careful when chasing rq->timeline that the
pointer does not disappear beneath us. The vast majority of users are in
a protected context, either during request construction or retirement,
where the timeline->mutex is held and the timeline cannot disappear. It
is those few off the beaten path (where we access a second timeline) that
need extra scrutiny -- to be added in the next patch after first adding
the warnings about dangerous access.
One complication, where we cannot use the timeline->mutex itself, is
during request submission onto hardware (under spinlocks). Here, we want
to check on the timeline to finalize the breadcrumb, and so we need to
impose a second rule to ensure that the request->timeline is indeed
valid. As we are submitting the request, it's context and timeline must
be pinned, as it will be used by the hardware. Since it is pinned, we
know the request->timeline must still be valid, and we cannot submit the
idle barrier until after we release the engine->active.lock, ergo while
submitting and holding that spinlock, a second thread cannot release the
timeline.
v2: Don't be lazy inside selftests; hold the timeline->mutex for as long
as we need it, and tidy up acquiring the timeline with a bit of
refactoring (i915_active_add_request)
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Cc: Tvrtko Ursulin <tvrtko.ursulin@intel.com>
Reviewed-by: Tvrtko Ursulin <tvrtko.ursulin@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20190919111912.21631-1-chris@chris-wilson.co.uk
2019-09-19 18:19:10 +07:00
|
|
|
struct intel_timeline *tl = i915_request_timeline(rq);
|
2019-08-02 17:00:15 +07:00
|
|
|
long timeout;
|
|
|
|
int err = 0;
|
|
|
|
|
drm/i915: Mark i915_request.timeline as a volatile, rcu pointer
The request->timeline is only valid until the request is retired (i.e.
before it is completed). Upon retiring the request, the context may be
unpinned and freed, and along with it the timeline may be freed. We
therefore need to be very careful when chasing rq->timeline that the
pointer does not disappear beneath us. The vast majority of users are in
a protected context, either during request construction or retirement,
where the timeline->mutex is held and the timeline cannot disappear. It
is those few off the beaten path (where we access a second timeline) that
need extra scrutiny -- to be added in the next patch after first adding
the warnings about dangerous access.
One complication, where we cannot use the timeline->mutex itself, is
during request submission onto hardware (under spinlocks). Here, we want
to check on the timeline to finalize the breadcrumb, and so we need to
impose a second rule to ensure that the request->timeline is indeed
valid. As we are submitting the request, it's context and timeline must
be pinned, as it will be used by the hardware. Since it is pinned, we
know the request->timeline must still be valid, and we cannot submit the
idle barrier until after we release the engine->active.lock, ergo while
submitting and holding that spinlock, a second thread cannot release the
timeline.
v2: Don't be lazy inside selftests; hold the timeline->mutex for as long
as we need it, and tidy up acquiring the timeline with a bit of
refactoring (i915_active_add_request)
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Cc: Tvrtko Ursulin <tvrtko.ursulin@intel.com>
Reviewed-by: Tvrtko Ursulin <tvrtko.ursulin@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20190919111912.21631-1-chris@chris-wilson.co.uk
2019-09-19 18:19:10 +07:00
|
|
|
intel_timeline_get(tl);
|
2019-08-02 17:00:15 +07:00
|
|
|
i915_request_get(rq);
|
|
|
|
|
drm/i915: Mark i915_request.timeline as a volatile, rcu pointer
The request->timeline is only valid until the request is retired (i.e.
before it is completed). Upon retiring the request, the context may be
unpinned and freed, and along with it the timeline may be freed. We
therefore need to be very careful when chasing rq->timeline that the
pointer does not disappear beneath us. The vast majority of users are in
a protected context, either during request construction or retirement,
where the timeline->mutex is held and the timeline cannot disappear. It
is those few off the beaten path (where we access a second timeline) that
need extra scrutiny -- to be added in the next patch after first adding
the warnings about dangerous access.
One complication, where we cannot use the timeline->mutex itself, is
during request submission onto hardware (under spinlocks). Here, we want
to check on the timeline to finalize the breadcrumb, and so we need to
impose a second rule to ensure that the request->timeline is indeed
valid. As we are submitting the request, it's context and timeline must
be pinned, as it will be used by the hardware. Since it is pinned, we
know the request->timeline must still be valid, and we cannot submit the
idle barrier until after we release the engine->active.lock, ergo while
submitting and holding that spinlock, a second thread cannot release the
timeline.
v2: Don't be lazy inside selftests; hold the timeline->mutex for as long
as we need it, and tidy up acquiring the timeline with a bit of
refactoring (i915_active_add_request)
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Cc: Tvrtko Ursulin <tvrtko.ursulin@intel.com>
Reviewed-by: Tvrtko Ursulin <tvrtko.ursulin@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20190919111912.21631-1-chris@chris-wilson.co.uk
2019-09-19 18:19:10 +07:00
|
|
|
/* Opencode i915_request_add() so we can keep the timeline locked. */
|
|
|
|
__i915_request_commit(rq);
|
|
|
|
__i915_request_queue(rq, NULL);
|
|
|
|
|
2019-08-02 17:00:15 +07:00
|
|
|
timeout = i915_request_wait(rq, 0, HZ / 10);
|
drm/i915: Mark i915_request.timeline as a volatile, rcu pointer
The request->timeline is only valid until the request is retired (i.e.
before it is completed). Upon retiring the request, the context may be
unpinned and freed, and along with it the timeline may be freed. We
therefore need to be very careful when chasing rq->timeline that the
pointer does not disappear beneath us. The vast majority of users are in
a protected context, either during request construction or retirement,
where the timeline->mutex is held and the timeline cannot disappear. It
is those few off the beaten path (where we access a second timeline) that
need extra scrutiny -- to be added in the next patch after first adding
the warnings about dangerous access.
One complication, where we cannot use the timeline->mutex itself, is
during request submission onto hardware (under spinlocks). Here, we want
to check on the timeline to finalize the breadcrumb, and so we need to
impose a second rule to ensure that the request->timeline is indeed
valid. As we are submitting the request, it's context and timeline must
be pinned, as it will be used by the hardware. Since it is pinned, we
know the request->timeline must still be valid, and we cannot submit the
idle barrier until after we release the engine->active.lock, ergo while
submitting and holding that spinlock, a second thread cannot release the
timeline.
v2: Don't be lazy inside selftests; hold the timeline->mutex for as long
as we need it, and tidy up acquiring the timeline with a bit of
refactoring (i915_active_add_request)
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Cc: Tvrtko Ursulin <tvrtko.ursulin@intel.com>
Reviewed-by: Tvrtko Ursulin <tvrtko.ursulin@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20190919111912.21631-1-chris@chris-wilson.co.uk
2019-09-19 18:19:10 +07:00
|
|
|
if (timeout < 0)
|
2019-08-02 17:00:15 +07:00
|
|
|
err = timeout;
|
drm/i915: Mark i915_request.timeline as a volatile, rcu pointer
The request->timeline is only valid until the request is retired (i.e.
before it is completed). Upon retiring the request, the context may be
unpinned and freed, and along with it the timeline may be freed. We
therefore need to be very careful when chasing rq->timeline that the
pointer does not disappear beneath us. The vast majority of users are in
a protected context, either during request construction or retirement,
where the timeline->mutex is held and the timeline cannot disappear. It
is those few off the beaten path (where we access a second timeline) that
need extra scrutiny -- to be added in the next patch after first adding
the warnings about dangerous access.
One complication, where we cannot use the timeline->mutex itself, is
during request submission onto hardware (under spinlocks). Here, we want
to check on the timeline to finalize the breadcrumb, and so we need to
impose a second rule to ensure that the request->timeline is indeed
valid. As we are submitting the request, it's context and timeline must
be pinned, as it will be used by the hardware. Since it is pinned, we
know the request->timeline must still be valid, and we cannot submit the
idle barrier until after we release the engine->active.lock, ergo while
submitting and holding that spinlock, a second thread cannot release the
timeline.
v2: Don't be lazy inside selftests; hold the timeline->mutex for as long
as we need it, and tidy up acquiring the timeline with a bit of
refactoring (i915_active_add_request)
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Cc: Tvrtko Ursulin <tvrtko.ursulin@intel.com>
Reviewed-by: Tvrtko Ursulin <tvrtko.ursulin@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20190919111912.21631-1-chris@chris-wilson.co.uk
2019-09-19 18:19:10 +07:00
|
|
|
else
|
2019-08-02 17:00:15 +07:00
|
|
|
i915_request_retire_upto(rq);
|
drm/i915: Mark i915_request.timeline as a volatile, rcu pointer
The request->timeline is only valid until the request is retired (i.e.
before it is completed). Upon retiring the request, the context may be
unpinned and freed, and along with it the timeline may be freed. We
therefore need to be very careful when chasing rq->timeline that the
pointer does not disappear beneath us. The vast majority of users are in
a protected context, either during request construction or retirement,
where the timeline->mutex is held and the timeline cannot disappear. It
is those few off the beaten path (where we access a second timeline) that
need extra scrutiny -- to be added in the next patch after first adding
the warnings about dangerous access.
One complication, where we cannot use the timeline->mutex itself, is
during request submission onto hardware (under spinlocks). Here, we want
to check on the timeline to finalize the breadcrumb, and so we need to
impose a second rule to ensure that the request->timeline is indeed
valid. As we are submitting the request, it's context and timeline must
be pinned, as it will be used by the hardware. Since it is pinned, we
know the request->timeline must still be valid, and we cannot submit the
idle barrier until after we release the engine->active.lock, ergo while
submitting and holding that spinlock, a second thread cannot release the
timeline.
v2: Don't be lazy inside selftests; hold the timeline->mutex for as long
as we need it, and tidy up acquiring the timeline with a bit of
refactoring (i915_active_add_request)
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Cc: Tvrtko Ursulin <tvrtko.ursulin@intel.com>
Reviewed-by: Tvrtko Ursulin <tvrtko.ursulin@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20190919111912.21631-1-chris@chris-wilson.co.uk
2019-09-19 18:19:10 +07:00
|
|
|
|
|
|
|
lockdep_unpin_lock(&tl->mutex, rq->cookie);
|
|
|
|
mutex_unlock(&tl->mutex);
|
2019-08-02 17:00:15 +07:00
|
|
|
|
|
|
|
i915_request_put(rq);
|
drm/i915: Mark i915_request.timeline as a volatile, rcu pointer
The request->timeline is only valid until the request is retired (i.e.
before it is completed). Upon retiring the request, the context may be
unpinned and freed, and along with it the timeline may be freed. We
therefore need to be very careful when chasing rq->timeline that the
pointer does not disappear beneath us. The vast majority of users are in
a protected context, either during request construction or retirement,
where the timeline->mutex is held and the timeline cannot disappear. It
is those few off the beaten path (where we access a second timeline) that
need extra scrutiny -- to be added in the next patch after first adding
the warnings about dangerous access.
One complication, where we cannot use the timeline->mutex itself, is
during request submission onto hardware (under spinlocks). Here, we want
to check on the timeline to finalize the breadcrumb, and so we need to
impose a second rule to ensure that the request->timeline is indeed
valid. As we are submitting the request, it's context and timeline must
be pinned, as it will be used by the hardware. Since it is pinned, we
know the request->timeline must still be valid, and we cannot submit the
idle barrier until after we release the engine->active.lock, ergo while
submitting and holding that spinlock, a second thread cannot release the
timeline.
v2: Don't be lazy inside selftests; hold the timeline->mutex for as long
as we need it, and tidy up acquiring the timeline with a bit of
refactoring (i915_active_add_request)
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Cc: Tvrtko Ursulin <tvrtko.ursulin@intel.com>
Reviewed-by: Tvrtko Ursulin <tvrtko.ursulin@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20190919111912.21631-1-chris@chris-wilson.co.uk
2019-09-19 18:19:10 +07:00
|
|
|
intel_timeline_put(tl);
|
2019-08-02 17:00:15 +07:00
|
|
|
|
|
|
|
return err;
|
|
|
|
}
|
|
|
|
|
|
|
|
static int context_sync(struct intel_context *ce)
|
|
|
|
{
|
2019-08-10 01:25:18 +07:00
|
|
|
struct intel_timeline *tl = ce->timeline;
|
2019-08-02 17:00:15 +07:00
|
|
|
int err = 0;
|
|
|
|
|
2019-08-16 03:57:09 +07:00
|
|
|
mutex_lock(&tl->mutex);
|
2019-08-02 17:00:15 +07:00
|
|
|
do {
|
2019-11-22 20:24:04 +07:00
|
|
|
struct i915_request *rq;
|
2019-08-02 17:00:15 +07:00
|
|
|
long timeout;
|
|
|
|
|
2019-11-22 20:24:04 +07:00
|
|
|
if (list_empty(&tl->requests))
|
2019-08-02 17:00:15 +07:00
|
|
|
break;
|
|
|
|
|
2019-11-22 20:24:04 +07:00
|
|
|
rq = list_last_entry(&tl->requests, typeof(*rq), link);
|
|
|
|
i915_request_get(rq);
|
|
|
|
|
|
|
|
timeout = i915_request_wait(rq, 0, HZ / 10);
|
2019-08-02 17:00:15 +07:00
|
|
|
if (timeout < 0)
|
|
|
|
err = timeout;
|
|
|
|
else
|
2019-11-22 20:24:04 +07:00
|
|
|
i915_request_retire_upto(rq);
|
2019-08-02 17:00:15 +07:00
|
|
|
|
2019-11-22 20:24:04 +07:00
|
|
|
i915_request_put(rq);
|
2019-08-02 17:00:15 +07:00
|
|
|
} while (!err);
|
2019-08-16 03:57:09 +07:00
|
|
|
mutex_unlock(&tl->mutex);
|
2019-08-02 17:00:15 +07:00
|
|
|
|
|
|
|
return err;
|
|
|
|
}
|
|
|
|
|
2019-12-21 23:03:24 +07:00
|
|
|
static int __live_context_size(struct intel_engine_cs *engine)
|
2019-08-17 14:37:11 +07:00
|
|
|
{
|
|
|
|
struct intel_context *ce;
|
|
|
|
struct i915_request *rq;
|
|
|
|
void *vaddr;
|
|
|
|
int err;
|
|
|
|
|
2019-12-21 23:03:24 +07:00
|
|
|
ce = intel_context_create(engine);
|
2019-08-17 14:37:11 +07:00
|
|
|
if (IS_ERR(ce))
|
|
|
|
return PTR_ERR(ce);
|
|
|
|
|
|
|
|
err = intel_context_pin(ce);
|
|
|
|
if (err)
|
|
|
|
goto err;
|
|
|
|
|
|
|
|
vaddr = i915_gem_object_pin_map(ce->state->obj,
|
|
|
|
i915_coherent_map_type(engine->i915));
|
|
|
|
if (IS_ERR(vaddr)) {
|
|
|
|
err = PTR_ERR(vaddr);
|
|
|
|
intel_context_unpin(ce);
|
|
|
|
goto err;
|
|
|
|
}
|
|
|
|
|
|
|
|
/*
|
|
|
|
* Note that execlists also applies a redzone which it checks on
|
|
|
|
* context unpin when debugging. We are using the same location
|
|
|
|
* and same poison value so that our checks overlap. Despite the
|
|
|
|
* redundancy, we want to keep this little selftest so that we
|
|
|
|
* get coverage of any and all submission backends, and we can
|
|
|
|
* always extend this test to ensure we trick the HW into a
|
|
|
|
* compromising position wrt to the various sections that need
|
|
|
|
* to be written into the context state.
|
|
|
|
*
|
|
|
|
* TLDR; this overlaps with the execlists redzone.
|
|
|
|
*/
|
|
|
|
vaddr += engine->context_size - I915_GTT_PAGE_SIZE;
|
|
|
|
memset(vaddr, POISON_INUSE, I915_GTT_PAGE_SIZE);
|
|
|
|
|
|
|
|
rq = intel_context_create_request(ce);
|
|
|
|
intel_context_unpin(ce);
|
|
|
|
if (IS_ERR(rq)) {
|
|
|
|
err = PTR_ERR(rq);
|
|
|
|
goto err_unpin;
|
|
|
|
}
|
|
|
|
|
|
|
|
err = request_sync(rq);
|
|
|
|
if (err)
|
|
|
|
goto err_unpin;
|
|
|
|
|
|
|
|
/* Force the context switch */
|
2019-11-25 17:58:56 +07:00
|
|
|
rq = intel_engine_create_kernel_request(engine);
|
2019-08-17 14:37:11 +07:00
|
|
|
if (IS_ERR(rq)) {
|
|
|
|
err = PTR_ERR(rq);
|
|
|
|
goto err_unpin;
|
|
|
|
}
|
|
|
|
err = request_sync(rq);
|
|
|
|
if (err)
|
|
|
|
goto err_unpin;
|
|
|
|
|
|
|
|
if (memchr_inv(vaddr, POISON_INUSE, I915_GTT_PAGE_SIZE)) {
|
|
|
|
pr_err("%s context overwrote trailing red-zone!", engine->name);
|
|
|
|
err = -EINVAL;
|
|
|
|
}
|
|
|
|
|
|
|
|
err_unpin:
|
|
|
|
i915_gem_object_unpin_map(ce->state->obj);
|
|
|
|
err:
|
|
|
|
intel_context_put(ce);
|
|
|
|
return err;
|
|
|
|
}
|
|
|
|
|
|
|
|
static int live_context_size(void *arg)
|
|
|
|
{
|
|
|
|
struct intel_gt *gt = arg;
|
|
|
|
struct intel_engine_cs *engine;
|
|
|
|
enum intel_engine_id id;
|
|
|
|
int err = 0;
|
|
|
|
|
|
|
|
/*
|
|
|
|
* Check that our context sizes are correct by seeing if the
|
|
|
|
* HW tries to write past the end of one.
|
|
|
|
*/
|
|
|
|
|
2019-10-17 16:45:00 +07:00
|
|
|
for_each_engine(engine, gt, id) {
|
2019-08-17 14:37:11 +07:00
|
|
|
struct {
|
drm/i915/gt: Keep a no-frills swappable copy of the default context state
We need to keep the default context state around to instantiate new
contexts (aka golden rendercontext), and we also keep it pinned while
the engine is active so that we can quickly reset a hanging context.
However, the default contexts are large enough to merit keeping in
swappable memory as opposed to kernel memory, so we store them inside
shmemfs. Currently, we use the normal GEM objects to create the default
context image, but we can throw away all but the shmemfs file.
This greatly simplifies the tricky power management code which wants to
run underneath the normal GT locking, and we definitely do not want to
use any high level objects that may appear to recurse back into the GT.
Though perhaps the primary advantage of the complex GEM object is that
we aggressively cache the mapping, but here we are recreating the
vm_area everytime time we unpark. At the worst, we add a lightweight
cache, but first find a microbenchmark that is impacted.
Having started to create some utility functions to make working with
shmemfs objects easier, we can start putting them to wider use, where
GEM objects are overkill, such as storing persistent error state.
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Cc: Matthew Auld <matthew.auld@intel.com>
Cc: Ramalingam C <ramalingam.c@intel.com>
Cc: Tvrtko Ursulin <tvrtko.ursulin@intel.com>
Reviewed-by: Matthew Auld <matthew.auld@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20200429172429.6054-1-chris@chris-wilson.co.uk
2020-04-30 00:24:29 +07:00
|
|
|
struct file *state;
|
2019-08-17 14:37:11 +07:00
|
|
|
void *pinned;
|
|
|
|
} saved;
|
|
|
|
|
|
|
|
if (!engine->context_size)
|
|
|
|
continue;
|
|
|
|
|
|
|
|
intel_engine_pm_get(engine);
|
|
|
|
|
|
|
|
/*
|
|
|
|
* Hide the old default state -- we lie about the context size
|
|
|
|
* and get confused when the default state is smaller than
|
|
|
|
* expected. For our do nothing request, inheriting the
|
|
|
|
* active state is sufficient, we are only checking that we
|
|
|
|
* don't use more than we planned.
|
|
|
|
*/
|
|
|
|
saved.state = fetch_and_zero(&engine->default_state);
|
|
|
|
saved.pinned = fetch_and_zero(&engine->pinned_default_state);
|
|
|
|
|
|
|
|
/* Overlaps with the execlists redzone */
|
|
|
|
engine->context_size += I915_GTT_PAGE_SIZE;
|
|
|
|
|
2019-12-21 23:03:24 +07:00
|
|
|
err = __live_context_size(engine);
|
2019-08-17 14:37:11 +07:00
|
|
|
|
|
|
|
engine->context_size -= I915_GTT_PAGE_SIZE;
|
|
|
|
|
|
|
|
engine->pinned_default_state = saved.pinned;
|
|
|
|
engine->default_state = saved.state;
|
|
|
|
|
|
|
|
intel_engine_pm_put(engine);
|
|
|
|
|
|
|
|
if (err)
|
|
|
|
break;
|
|
|
|
}
|
|
|
|
|
|
|
|
return err;
|
|
|
|
}
|
|
|
|
|
2019-12-21 23:03:24 +07:00
|
|
|
static int __live_active_context(struct intel_engine_cs *engine)
|
2019-08-02 17:00:15 +07:00
|
|
|
{
|
2019-11-15 22:08:40 +07:00
|
|
|
unsigned long saved_heartbeat;
|
2019-08-02 17:00:15 +07:00
|
|
|
struct intel_context *ce;
|
|
|
|
int pass;
|
|
|
|
int err;
|
|
|
|
|
|
|
|
/*
|
|
|
|
* We keep active contexts alive until after a subsequent context
|
|
|
|
* switch as the final write from the context-save will be after
|
|
|
|
* we retire the final request. We track when we unpin the context,
|
|
|
|
* under the presumption that the final pin is from the last request,
|
|
|
|
* and instead of immediately unpinning the context, we add a task
|
|
|
|
* to unpin the context from the next idle-barrier.
|
|
|
|
*
|
|
|
|
* This test makes sure that the context is kept alive until a
|
|
|
|
* subsequent idle-barrier (emitted when the engine wakeref hits 0
|
|
|
|
* with no more outstanding requests).
|
|
|
|
*/
|
|
|
|
|
|
|
|
if (intel_engine_pm_is_awake(engine)) {
|
|
|
|
pr_err("%s is awake before starting %s!\n",
|
|
|
|
engine->name, __func__);
|
|
|
|
return -EINVAL;
|
|
|
|
}
|
|
|
|
|
2019-12-21 23:03:24 +07:00
|
|
|
ce = intel_context_create(engine);
|
2019-08-07 19:28:32 +07:00
|
|
|
if (IS_ERR(ce))
|
|
|
|
return PTR_ERR(ce);
|
2019-08-02 17:00:15 +07:00
|
|
|
|
2019-11-15 22:08:40 +07:00
|
|
|
saved_heartbeat = engine->props.heartbeat_interval_ms;
|
|
|
|
engine->props.heartbeat_interval_ms = 0;
|
|
|
|
|
2019-08-02 17:00:15 +07:00
|
|
|
for (pass = 0; pass <= 2; pass++) {
|
|
|
|
struct i915_request *rq;
|
|
|
|
|
2019-11-15 22:08:40 +07:00
|
|
|
intel_engine_pm_get(engine);
|
|
|
|
|
2019-08-02 17:00:15 +07:00
|
|
|
rq = intel_context_create_request(ce);
|
|
|
|
if (IS_ERR(rq)) {
|
|
|
|
err = PTR_ERR(rq);
|
2019-11-15 22:08:40 +07:00
|
|
|
goto out_engine;
|
2019-08-02 17:00:15 +07:00
|
|
|
}
|
|
|
|
|
|
|
|
err = request_sync(rq);
|
|
|
|
if (err)
|
2019-11-15 22:08:40 +07:00
|
|
|
goto out_engine;
|
2019-08-02 17:00:15 +07:00
|
|
|
|
|
|
|
/* Context will be kept active until after an idle-barrier. */
|
|
|
|
if (i915_active_is_idle(&ce->active)) {
|
|
|
|
pr_err("context is not active; expected idle-barrier (%s pass %d)\n",
|
|
|
|
engine->name, pass);
|
|
|
|
err = -EINVAL;
|
2019-11-15 22:08:40 +07:00
|
|
|
goto out_engine;
|
2019-08-02 17:00:15 +07:00
|
|
|
}
|
|
|
|
|
|
|
|
if (!intel_engine_pm_is_awake(engine)) {
|
|
|
|
pr_err("%s is asleep before idle-barrier\n",
|
|
|
|
engine->name);
|
|
|
|
err = -EINVAL;
|
2019-11-15 22:08:40 +07:00
|
|
|
goto out_engine;
|
2019-08-02 17:00:15 +07:00
|
|
|
}
|
2019-11-15 22:08:40 +07:00
|
|
|
|
|
|
|
out_engine:
|
|
|
|
intel_engine_pm_put(engine);
|
|
|
|
if (err)
|
|
|
|
goto err;
|
2019-08-02 17:00:15 +07:00
|
|
|
}
|
|
|
|
|
|
|
|
/* Now make sure our idle-barriers are flushed */
|
2019-11-15 22:08:40 +07:00
|
|
|
err = intel_engine_flush_barriers(engine);
|
|
|
|
if (err)
|
|
|
|
goto err;
|
|
|
|
|
2019-11-22 20:24:04 +07:00
|
|
|
/* Wait for the barrier and in the process wait for engine to park */
|
2019-08-02 17:00:15 +07:00
|
|
|
err = context_sync(engine->kernel_context);
|
|
|
|
if (err)
|
|
|
|
goto err;
|
|
|
|
|
|
|
|
if (!i915_active_is_idle(&ce->active)) {
|
|
|
|
pr_err("context is still active!");
|
|
|
|
err = -EINVAL;
|
|
|
|
}
|
|
|
|
|
2019-11-22 20:24:04 +07:00
|
|
|
intel_engine_pm_flush(engine);
|
|
|
|
|
2019-08-02 17:00:15 +07:00
|
|
|
if (intel_engine_pm_is_awake(engine)) {
|
|
|
|
struct drm_printer p = drm_debug_printer(__func__);
|
|
|
|
|
|
|
|
intel_engine_dump(engine, &p,
|
2019-11-15 22:08:40 +07:00
|
|
|
"%s is still awake:%d after idle-barriers\n",
|
|
|
|
engine->name,
|
|
|
|
atomic_read(&engine->wakeref.count));
|
2019-08-02 17:00:15 +07:00
|
|
|
GEM_TRACE_DUMP();
|
|
|
|
|
|
|
|
err = -EINVAL;
|
|
|
|
goto err;
|
|
|
|
}
|
|
|
|
|
|
|
|
err:
|
2019-11-15 22:08:40 +07:00
|
|
|
engine->props.heartbeat_interval_ms = saved_heartbeat;
|
2019-08-02 17:00:15 +07:00
|
|
|
intel_context_put(ce);
|
|
|
|
return err;
|
|
|
|
}
|
|
|
|
|
|
|
|
static int live_active_context(void *arg)
|
|
|
|
{
|
|
|
|
struct intel_gt *gt = arg;
|
|
|
|
struct intel_engine_cs *engine;
|
|
|
|
enum intel_engine_id id;
|
|
|
|
int err = 0;
|
|
|
|
|
2019-10-17 16:45:00 +07:00
|
|
|
for_each_engine(engine, gt, id) {
|
2019-12-21 23:03:24 +07:00
|
|
|
err = __live_active_context(engine);
|
2019-08-02 17:00:15 +07:00
|
|
|
if (err)
|
|
|
|
break;
|
|
|
|
|
2019-10-04 20:40:02 +07:00
|
|
|
err = igt_flush_test(gt->i915);
|
2019-08-02 17:00:15 +07:00
|
|
|
if (err)
|
|
|
|
break;
|
|
|
|
}
|
|
|
|
|
|
|
|
return err;
|
|
|
|
}
|
|
|
|
|
|
|
|
static int __remote_sync(struct intel_context *ce, struct intel_context *remote)
|
|
|
|
{
|
|
|
|
struct i915_request *rq;
|
|
|
|
int err;
|
|
|
|
|
|
|
|
err = intel_context_pin(remote);
|
|
|
|
if (err)
|
|
|
|
return err;
|
|
|
|
|
|
|
|
rq = intel_context_create_request(ce);
|
|
|
|
if (IS_ERR(rq)) {
|
|
|
|
err = PTR_ERR(rq);
|
|
|
|
goto unpin;
|
|
|
|
}
|
|
|
|
|
|
|
|
err = intel_context_prepare_remote_request(remote, rq);
|
|
|
|
if (err) {
|
|
|
|
i915_request_add(rq);
|
|
|
|
goto unpin;
|
|
|
|
}
|
|
|
|
|
|
|
|
err = request_sync(rq);
|
|
|
|
|
|
|
|
unpin:
|
|
|
|
intel_context_unpin(remote);
|
|
|
|
return err;
|
|
|
|
}
|
|
|
|
|
2019-12-21 23:03:24 +07:00
|
|
|
static int __live_remote_context(struct intel_engine_cs *engine)
|
2019-08-02 17:00:15 +07:00
|
|
|
{
|
|
|
|
struct intel_context *local, *remote;
|
2019-11-15 22:08:40 +07:00
|
|
|
unsigned long saved_heartbeat;
|
2019-08-02 17:00:15 +07:00
|
|
|
int pass;
|
|
|
|
int err;
|
|
|
|
|
|
|
|
/*
|
|
|
|
* Check that our idle barriers do not interfere with normal
|
|
|
|
* activity tracking. In particular, check that operating
|
|
|
|
* on the context image remotely (intel_context_prepare_remote_request),
|
|
|
|
* which inserts foreign fences into intel_context.active, does not
|
|
|
|
* clobber the idle-barrier.
|
|
|
|
*/
|
|
|
|
|
2019-11-15 22:08:40 +07:00
|
|
|
if (intel_engine_pm_is_awake(engine)) {
|
|
|
|
pr_err("%s is awake before starting %s!\n",
|
|
|
|
engine->name, __func__);
|
|
|
|
return -EINVAL;
|
|
|
|
}
|
|
|
|
|
2019-12-21 23:03:24 +07:00
|
|
|
remote = intel_context_create(engine);
|
2019-08-07 19:28:32 +07:00
|
|
|
if (IS_ERR(remote))
|
|
|
|
return PTR_ERR(remote);
|
2019-08-02 17:00:15 +07:00
|
|
|
|
2019-12-21 23:03:24 +07:00
|
|
|
local = intel_context_create(engine);
|
2019-08-07 19:28:32 +07:00
|
|
|
if (IS_ERR(local)) {
|
|
|
|
err = PTR_ERR(local);
|
2019-08-02 17:00:15 +07:00
|
|
|
goto err_remote;
|
|
|
|
}
|
|
|
|
|
2019-11-15 22:08:40 +07:00
|
|
|
saved_heartbeat = engine->props.heartbeat_interval_ms;
|
|
|
|
engine->props.heartbeat_interval_ms = 0;
|
|
|
|
intel_engine_pm_get(engine);
|
|
|
|
|
2019-08-02 17:00:15 +07:00
|
|
|
for (pass = 0; pass <= 2; pass++) {
|
|
|
|
err = __remote_sync(local, remote);
|
|
|
|
if (err)
|
|
|
|
break;
|
|
|
|
|
|
|
|
err = __remote_sync(engine->kernel_context, remote);
|
|
|
|
if (err)
|
|
|
|
break;
|
|
|
|
|
|
|
|
if (i915_active_is_idle(&remote->active)) {
|
|
|
|
pr_err("remote context is not active; expected idle-barrier (%s pass %d)\n",
|
|
|
|
engine->name, pass);
|
|
|
|
err = -EINVAL;
|
|
|
|
break;
|
|
|
|
}
|
|
|
|
}
|
|
|
|
|
2019-11-15 22:08:40 +07:00
|
|
|
intel_engine_pm_put(engine);
|
|
|
|
engine->props.heartbeat_interval_ms = saved_heartbeat;
|
|
|
|
|
2019-08-02 17:00:15 +07:00
|
|
|
intel_context_put(local);
|
|
|
|
err_remote:
|
|
|
|
intel_context_put(remote);
|
|
|
|
return err;
|
|
|
|
}
|
|
|
|
|
|
|
|
static int live_remote_context(void *arg)
|
|
|
|
{
|
|
|
|
struct intel_gt *gt = arg;
|
|
|
|
struct intel_engine_cs *engine;
|
|
|
|
enum intel_engine_id id;
|
|
|
|
int err = 0;
|
|
|
|
|
2019-10-17 16:45:00 +07:00
|
|
|
for_each_engine(engine, gt, id) {
|
2019-12-21 23:03:24 +07:00
|
|
|
err = __live_remote_context(engine);
|
2019-08-02 17:00:15 +07:00
|
|
|
if (err)
|
|
|
|
break;
|
|
|
|
|
2019-10-04 20:40:02 +07:00
|
|
|
err = igt_flush_test(gt->i915);
|
2019-08-02 17:00:15 +07:00
|
|
|
if (err)
|
|
|
|
break;
|
|
|
|
}
|
|
|
|
|
|
|
|
return err;
|
|
|
|
}
|
|
|
|
|
|
|
|
int intel_context_live_selftests(struct drm_i915_private *i915)
|
|
|
|
{
|
|
|
|
static const struct i915_subtest tests[] = {
|
2019-08-17 14:37:11 +07:00
|
|
|
SUBTEST(live_context_size),
|
2019-08-02 17:00:15 +07:00
|
|
|
SUBTEST(live_active_context),
|
|
|
|
SUBTEST(live_remote_context),
|
|
|
|
};
|
|
|
|
struct intel_gt *gt = &i915->gt;
|
|
|
|
|
|
|
|
if (intel_gt_is_wedged(gt))
|
|
|
|
return 0;
|
|
|
|
|
|
|
|
return intel_gt_live_subtests(tests, gt);
|
|
|
|
}
|