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? -- Open Source Technology Center, Intel ltd. $gpg --keyserver wwwkeys.pgp.net --recv-keys 4D781827
Attachment:
signature.asc
Description: PGP signature
_______________________________________________ Intel-gfx mailing list Intel-gfx@xxxxxxxxxxxxxxxxxxxxx https://lists.freedesktop.org/mailman/listinfo/intel-gfx