2019-08-02 18:00:15 +08:00
|
|
|
/*
|
|
|
|
|
* SPDX-License-Identifier: GPL-2.0
|
|
|
|
|
*
|
|
|
|
|
* Copyright © 2019 Intel Corporation
|
|
|
|
|
*/
|
|
|
|
|
|
|
|
|
|
#include "i915_selftest.h"
|
2019-11-15 23:08:40 +08:00
|
|
|
#include "intel_engine_heartbeat.h"
|
2019-08-17 15:37:11 +08:00
|
|
|
#include "intel_engine_pm.h"
|
2019-08-02 18:00:15 +08: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 19:19:10 +08:00
|
|
|
struct intel_timeline *tl = i915_request_timeline(rq);
|
2019-08-02 18:00:15 +08: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 19:19:10 +08:00
|
|
|
intel_timeline_get(tl);
|
2019-08-02 18:00:15 +08: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 19:19:10 +08:00
|
|
|
/* Opencode i915_request_add() so we can keep the timeline locked. */
|
|
|
|
|
__i915_request_commit(rq);
|
2020-05-14 01:35:04 +08:00
|
|
|
rq->sched.attr.priority = I915_PRIORITY_BARRIER;
|
2020-12-24 21:55:36 +08:00
|
|
|
__i915_request_queue_bh(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 19:19:10 +08:00
|
|
|
|
2019-08-02 18:00:15 +08: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 19:19:10 +08:00
|
|
|
if (timeout < 0)
|
2019-08-02 18:00:15 +08: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 19:19:10 +08:00
|
|
|
else
|
2019-08-02 18:00:15 +08: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 19:19:10 +08:00
|
|
|
|
|
|
|
|
lockdep_unpin_lock(&tl->mutex, rq->cookie);
|
|
|
|
|
mutex_unlock(&tl->mutex);
|
2019-08-02 18:00:15 +08: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 19:19:10 +08:00
|
|
|
intel_timeline_put(tl);
|
2019-08-02 18:00:15 +08:00
|
|
|
|
|
|
|
|
return err;
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
static int context_sync(struct intel_context *ce)
|
|
|
|
|
{
|
2019-08-10 02:25:18 +08:00
|
|
|
struct intel_timeline *tl = ce->timeline;
|
2019-08-02 18:00:15 +08:00
|
|
|
int err = 0;
|
|
|
|
|
|
2019-08-16 04:57:09 +08:00
|
|
|
mutex_lock(&tl->mutex);
|
2019-08-02 18:00:15 +08:00
|
|
|
do {
|
2019-11-22 21:24:04 +08:00
|
|
|
struct i915_request *rq;
|
2019-08-02 18:00:15 +08:00
|
|
|
long timeout;
|
|
|
|
|
|
2019-11-22 21:24:04 +08:00
|
|
|
if (list_empty(&tl->requests))
|
2019-08-02 18:00:15 +08:00
|
|
|
break;
|
|
|
|
|
|
2019-11-22 21:24:04 +08: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 18:00:15 +08:00
|
|
|
if (timeout < 0)
|
|
|
|
|
err = timeout;
|
|
|
|
|
else
|
2019-11-22 21:24:04 +08:00
|
|
|
i915_request_retire_upto(rq);
|
2019-08-02 18:00:15 +08:00
|
|
|
|
2019-11-22 21:24:04 +08:00
|
|
|
i915_request_put(rq);
|
2019-08-02 18:00:15 +08:00
|
|
|
} while (!err);
|
2019-08-16 04:57:09 +08:00
|
|
|
mutex_unlock(&tl->mutex);
|
2019-08-02 18:00:15 +08:00
|
|
|
|
2020-07-28 23:33:25 +08:00
|
|
|
/* Wait for all barriers to complete (remote CPU) before we check */
|
|
|
|
|
i915_active_unlock_wait(&ce->active);
|
2019-08-02 18:00:15 +08:00
|
|
|
return err;
|
|
|
|
|
}
|
|
|
|
|
|
2019-12-22 00:03:24 +08:00
|
|
|
static int __live_context_size(struct intel_engine_cs *engine)
|
2019-08-17 15:37:11 +08:00
|
|
|
{
|
|
|
|
|
struct intel_context *ce;
|
|
|
|
|
struct i915_request *rq;
|
|
|
|
|
void *vaddr;
|
|
|
|
|
int err;
|
|
|
|
|
|
2019-12-22 00:03:24 +08:00
|
|
|
ce = intel_context_create(engine);
|
2019-08-17 15:37:11 +08: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 18:58:56 +08:00
|
|
|
rq = intel_engine_create_kernel_request(engine);
|
2019-08-17 15:37:11 +08: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 17:45:00 +08:00
|
|
|
for_each_engine(engine, gt, id) {
|
2020-05-05 02:07:45 +08:00
|
|
|
struct file *saved;
|
2019-08-17 15:37:11 +08:00
|
|
|
|
|
|
|
|
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.
|
|
|
|
|
*/
|
2020-05-05 02:07:45 +08:00
|
|
|
saved = fetch_and_zero(&engine->default_state);
|
2019-08-17 15:37:11 +08:00
|
|
|
|
|
|
|
|
/* Overlaps with the execlists redzone */
|
|
|
|
|
engine->context_size += I915_GTT_PAGE_SIZE;
|
|
|
|
|
|
2019-12-22 00:03:24 +08:00
|
|
|
err = __live_context_size(engine);
|
2019-08-17 15:37:11 +08:00
|
|
|
|
|
|
|
|
engine->context_size -= I915_GTT_PAGE_SIZE;
|
|
|
|
|
|
2020-05-05 02:07:45 +08:00
|
|
|
engine->default_state = saved;
|
2019-08-17 15:37:11 +08:00
|
|
|
|
|
|
|
|
intel_engine_pm_put(engine);
|
|
|
|
|
|
|
|
|
|
if (err)
|
|
|
|
|
break;
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
return err;
|
|
|
|
|
}
|
|
|
|
|
|
2019-12-22 00:03:24 +08:00
|
|
|
static int __live_active_context(struct intel_engine_cs *engine)
|
2019-08-02 18:00:15 +08:00
|
|
|
{
|
2019-11-15 23:08:40 +08:00
|
|
|
unsigned long saved_heartbeat;
|
2019-08-02 18:00:15 +08: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-22 00:03:24 +08:00
|
|
|
ce = intel_context_create(engine);
|
2019-08-07 20:28:32 +08:00
|
|
|
if (IS_ERR(ce))
|
|
|
|
|
return PTR_ERR(ce);
|
2019-08-02 18:00:15 +08:00
|
|
|
|
2019-11-15 23:08:40 +08:00
|
|
|
saved_heartbeat = engine->props.heartbeat_interval_ms;
|
|
|
|
|
engine->props.heartbeat_interval_ms = 0;
|
|
|
|
|
|
2019-08-02 18:00:15 +08:00
|
|
|
for (pass = 0; pass <= 2; pass++) {
|
|
|
|
|
struct i915_request *rq;
|
|
|
|
|
|
2019-11-15 23:08:40 +08:00
|
|
|
intel_engine_pm_get(engine);
|
|
|
|
|
|
2019-08-02 18:00:15 +08:00
|
|
|
rq = intel_context_create_request(ce);
|
|
|
|
|
if (IS_ERR(rq)) {
|
|
|
|
|
err = PTR_ERR(rq);
|
2019-11-15 23:08:40 +08:00
|
|
|
goto out_engine;
|
2019-08-02 18:00:15 +08:00
|
|
|
}
|
|
|
|
|
|
|
|
|
|
err = request_sync(rq);
|
|
|
|
|
if (err)
|
2019-11-15 23:08:40 +08:00
|
|
|
goto out_engine;
|
2019-08-02 18:00:15 +08: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 23:08:40 +08:00
|
|
|
goto out_engine;
|
2019-08-02 18:00:15 +08:00
|
|
|
}
|
|
|
|
|
|
|
|
|
|
if (!intel_engine_pm_is_awake(engine)) {
|
|
|
|
|
pr_err("%s is asleep before idle-barrier\n",
|
|
|
|
|
engine->name);
|
|
|
|
|
err = -EINVAL;
|
2019-11-15 23:08:40 +08:00
|
|
|
goto out_engine;
|
2019-08-02 18:00:15 +08:00
|
|
|
}
|
2019-11-15 23:08:40 +08:00
|
|
|
|
|
|
|
|
out_engine:
|
|
|
|
|
intel_engine_pm_put(engine);
|
|
|
|
|
if (err)
|
|
|
|
|
goto err;
|
2019-08-02 18:00:15 +08:00
|
|
|
}
|
|
|
|
|
|
|
|
|
|
/* Now make sure our idle-barriers are flushed */
|
2019-11-15 23:08:40 +08:00
|
|
|
err = intel_engine_flush_barriers(engine);
|
|
|
|
|
if (err)
|
|
|
|
|
goto err;
|
|
|
|
|
|
2019-11-22 21:24:04 +08:00
|
|
|
/* Wait for the barrier and in the process wait for engine to park */
|
2019-08-02 18:00:15 +08: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 21:24:04 +08:00
|
|
|
intel_engine_pm_flush(engine);
|
|
|
|
|
|
2019-08-02 18:00:15 +08:00
|
|
|
if (intel_engine_pm_is_awake(engine)) {
|
|
|
|
|
struct drm_printer p = drm_debug_printer(__func__);
|
|
|
|
|
|
|
|
|
|
intel_engine_dump(engine, &p,
|
2019-11-15 23:08:40 +08:00
|
|
|
"%s is still awake:%d after idle-barriers\n",
|
|
|
|
|
engine->name,
|
|
|
|
|
atomic_read(&engine->wakeref.count));
|
2019-08-02 18:00:15 +08:00
|
|
|
GEM_TRACE_DUMP();
|
|
|
|
|
|
|
|
|
|
err = -EINVAL;
|
|
|
|
|
goto err;
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
err:
|
2019-11-15 23:08:40 +08:00
|
|
|
engine->props.heartbeat_interval_ms = saved_heartbeat;
|
2019-08-02 18:00:15 +08: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 17:45:00 +08:00
|
|
|
for_each_engine(engine, gt, id) {
|
2019-12-22 00:03:24 +08:00
|
|
|
err = __live_active_context(engine);
|
2019-08-02 18:00:15 +08:00
|
|
|
if (err)
|
|
|
|
|
break;
|
|
|
|
|
|
2019-10-04 21:40:02 +08:00
|
|
|
err = igt_flush_test(gt->i915);
|
2019-08-02 18:00:15 +08: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-22 00:03:24 +08:00
|
|
|
static int __live_remote_context(struct intel_engine_cs *engine)
|
2019-08-02 18:00:15 +08:00
|
|
|
{
|
|
|
|
|
struct intel_context *local, *remote;
|
2019-11-15 23:08:40 +08:00
|
|
|
unsigned long saved_heartbeat;
|
2019-08-02 18:00:15 +08: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 23:08:40 +08:00
|
|
|
if (intel_engine_pm_is_awake(engine)) {
|
|
|
|
|
pr_err("%s is awake before starting %s!\n",
|
|
|
|
|
engine->name, __func__);
|
|
|
|
|
return -EINVAL;
|
|
|
|
|
}
|
|
|
|
|
|
2019-12-22 00:03:24 +08:00
|
|
|
remote = intel_context_create(engine);
|
2019-08-07 20:28:32 +08:00
|
|
|
if (IS_ERR(remote))
|
|
|
|
|
return PTR_ERR(remote);
|
2019-08-02 18:00:15 +08:00
|
|
|
|
2019-12-22 00:03:24 +08:00
|
|
|
local = intel_context_create(engine);
|
2019-08-07 20:28:32 +08:00
|
|
|
if (IS_ERR(local)) {
|
|
|
|
|
err = PTR_ERR(local);
|
2019-08-02 18:00:15 +08:00
|
|
|
goto err_remote;
|
|
|
|
|
}
|
|
|
|
|
|
2019-11-15 23:08:40 +08:00
|
|
|
saved_heartbeat = engine->props.heartbeat_interval_ms;
|
|
|
|
|
engine->props.heartbeat_interval_ms = 0;
|
|
|
|
|
intel_engine_pm_get(engine);
|
|
|
|
|
|
2019-08-02 18:00:15 +08: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 23:08:40 +08:00
|
|
|
intel_engine_pm_put(engine);
|
|
|
|
|
engine->props.heartbeat_interval_ms = saved_heartbeat;
|
|
|
|
|
|
2019-08-02 18:00:15 +08: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 17:45:00 +08:00
|
|
|
for_each_engine(engine, gt, id) {
|
2019-12-22 00:03:24 +08:00
|
|
|
err = __live_remote_context(engine);
|
2019-08-02 18:00:15 +08:00
|
|
|
if (err)
|
|
|
|
|
break;
|
|
|
|
|
|
2019-10-04 21:40:02 +08:00
|
|
|
err = igt_flush_test(gt->i915);
|
2019-08-02 18:00:15 +08: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 15:37:11 +08:00
|
|
|
SUBTEST(live_context_size),
|
2019-08-02 18:00:15 +08: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);
|
|
|
|
|
}
|