On 2018.05.18 09:42:47 +0100, Chris Wilson wrote:
> Quoting Tvrtko Ursulin (2018-05-18 08:43:33)
> > 
> > On 18/05/2018 04:21, Zhenyu Wang wrote:
> > > On 2018.05.17 22:26:32 +0100, Chris Wilson wrote:
> > >> To ease the frequent and ugly pointer dance of
> > >> &request->gem_context->engine[request->engine->id] during request
> > >> submission, store that pointer as request->hw_context. One major
> > >> advantage that we will exploit later is that this decouples the logical
> > >> context state from the engine itself.
> > >>
> > >> v2: Set mock_context->ops so we don't crash and burn in selftests.
> > >>      Cleanups from Tvrtko.
> > >>
> > >> Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
> > >> Cc: Tvrtko Ursulin <tvrtko.ursulin@intel.com>
> > >> ---
> > >>   drivers/gpu/drm/i915/gvt/mmio_context.c       |   6 +-
> > >>   drivers/gpu/drm/i915/gvt/mmio_context.h       |   2 +-
> > >>   drivers/gpu/drm/i915/gvt/scheduler.c          | 141 +++++++-----------
> > >>   drivers/gpu/drm/i915/gvt/scheduler.h          |   1 -
> > > 
> > > gvt change looks fine to me.
> > > 
> > > Acked-by: Zhenyu Wang <zhenyuw@linux.intel.com>
> > 
> > Excellent, thanks!
> > 
> > And I think I already have my r-b earlier for non-GVT parts. So let me 
> > repeat it:
> > 
> > Reviewed-by: Tvrtko Ursulin <tvrtko.ursulin@intel.com>
> 
> Thanks. Applied, please yell if I broke anything, or better yet donate
> some machines to testing intel-gfx@ :)

Well, looks it does break guest boot, patch mail is following. ;)
I do like to have gvt regression test for CI at least for easy case e.g
VM boot normal and better instruct some igt cases after boot. If that's
just machine resource issue, I can raise to mangement to see if anyone
can help.

> 
> There will be a few more changes to make struct intel_context a first
> class citizen for i915_request if Tvrtko manages to whip me or the api
> into shape. So expect a little more upheaval in the coming months.
> I'm thinking an api like:
> 
> 	ce = intel_context_get_and_lock(context, engine);
> 
> 	rq = i915_request_get(ce);
> 	...
> 	i915_request_add(rq);
> 
> 	intel_context_put_and_unlock(ce);
> 
> (get_and_lock() is a helper around _get() and _lock())
> 
> In the gvt case, I expect you will want to manage your intel_contexts
> explicitly as the ref/pin/locked phases is slightly longer for you than
> the typical construct-a-request used elsewhere. Note also that the goal
> is to replace the struct_mutex with fine grained locks.

yeah, looks we do need better refactor for those request/context
preparation and shadowing steps, even we've tried twice.

-- 
Open Source Technology Center, Intel ltd.

$gpg --keyserver wwwkeys.pgp.net --recv-keys 4D781827