Quoting Zhenyu Wang (2018-05-21 04:44:34) > On 2018.05.18 11:22:06 +0100, Chris Wilson wrote: > > Quoting Zhenyu Wang (2018-05-18 11:13:05) > > > When we do shadowing, workload's request might not be allocated yet, > > > so we still require shadow context's object. And when complete workload, > > > delay to zero workload's request pointer after used for update guest context. > > > > Please allocate the context earlier then. The point is that until you > > do, shadow_ctx->__engine[ring_id]->state is *undefined* and this code is > > still illegal. :-p > > > > The intent is that you start tracking the lifetime of the state you are > > using because the assumptions made here will not hold for much longer. > > Chris, after double check, for shadowing we do assure to pin our > context earlier for target engine context, so shadow_ctx->__engine[ring_id]->state > is always valid. We just don't require the real request be generated earlier > during scan/shadow, so use pinned context state pointer directly. Will that be > a problem in future? It's just a matter of how you get it. The only reason I was using the request was that had an explicit pointer to the pinned context; it looked easier to keep using that rather than add a separate context member. If you would rather do that, do so -- please don't keep tacitly using the gem_context to derive the intel_context without any obvious sign of protection. (It's just that the link between gem_context and intel_context is going to become more tenuous, so it is important we make the ownership and lifecycle of intel_context more explicit.) -Chris _______________________________________________ Intel-gfx mailing list Intel-gfx@xxxxxxxxxxxxxxxxxxxxx https://lists.freedesktop.org/mailman/listinfo/intel-gfx
