[RESEND PATCH] drm/i915/gvt: avoid dispatching workloads when host is resetting chip

Zhenyu Wang zhenyuw at linux.intel.com
Fri Feb 17 06:45:20 UTC 2017


On 2017.02.17 14:37:00 +0800, Du, Changbin wrote:
> On Fri, Feb 17, 2017 at 01:50:06PM +0800, Zhenyu Wang wrote:
> > On 2017.02.17 13:28:52 +0800, Du, Changbin wrote:
> > > On Fri, Feb 17, 2017 at 11:59:58AM +0800, Gao, Ping A wrote:
> > > > Do we really need this? as I915 hold the struct_mutexto do reset,
> > > > andrelease after reset complete,  this mutex hold the workload dispatch
> > > > in gvt also.
> > > >
> > > not all. eg. we can fail at i915_alloc_request() somewhere.
> > >
> > 
> > I admit that we should handle gpu reset in progress case, my only concern
> > is where to handle this gracefully, e.g before choose workload like this or
> > delay that at request alloc time to check in fail path and if reset in progress
> > but not wedged can do retry on that, as even with this change, there's still
> > possible that after workload pick, something else caused gpu reset then will
> > still discard this to make this change not much helpful...
> >
> This hint me that the wait mait move afteward to make code simpler since
> less ident. :)
> 
> We take a workload as 3 basic stages:
> 1. pick a workload from queue
> 2. diliver to i915 to process and wait complete
> 3. populate to guest and clean up the workload
> 
> For gpu chip reset case, handle at #1 simple and necessary, just wait.
> Then do we need retry during stage #2 & #3? I think it is not necessary.
> Because we alreay assert gpu is not resetting at stage #1, means we are
> the owner of gpu now (no other wordload running). If it fails at #2
> && #3, do you think we can rerun it?
> 

We only grab i915 mutex for request alloc and submit, alloc could fail
because of reset/wedged.

-- 
Open Source Technology Center, Intel ltd.

$gpg --keyserver wwwkeys.pgp.net --recv-keys 4D781827
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 163 bytes
Desc: not available
URL: <https://lists.freedesktop.org/archives/intel-gvt-dev/attachments/20170217/b90cdaba/attachment.sig>


More information about the intel-gvt-dev mailing list