On 06/02/2020 15:29, Chris Wilson wrote:
Quoting Chris Wilson (2020-02-06 15:23:25)Virtual engines are fleeting. They carry a reference count and may be freed when their last request is retired. This makes them unsuitable for the task of housing engine->retire.work so assert that it is not used. Tvrtko tracked down an instance where we did indeed violate this rule. In virtal_submit_request, we flush a completed request directly with __i915_request_submit and this causes us to queue that request on the veng's breadcrumb list and signal it. Leading us down a path where we should not attach the retire. Reported-by: Tvrtko Ursulin <tvrtko.ursulin@xxxxxxxxx> Fixes: dc93c9b69315 ("drm/i915/gt: Schedule request retirement when signaler idles") Signed-off-by: Chris Wilson <chris@xxxxxxxxxxxxxxxxxx> Cc: Tvrtko Ursulin <tvrtko.ursulin@xxxxxxxxx>Alternatively we could fixup the rq->engine before __i915_request_submit. That would stop the spread of intel_virtual_engine_get_sibling(). This is likely to be the cleaner fix, so I think I would prefer this and then remove the get_sibling().
Yes it makes more sense for rq->engine to be always physical at the point of __i915_request_submit.
Regards, Tvrtko _______________________________________________ Intel-gfx mailing list Intel-gfx@xxxxxxxxxxxxxxxxxxxxx https://lists.freedesktop.org/mailman/listinfo/intel-gfx
