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

[Du, Changbin]

On Fri, Feb 17, 2017 at 02:45:20PM +0800, Zhenyu Wang wrote:
> 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.
> 
ok, got your idea. That has the same effect. Just checked the code,
commit 90d27a (drm/i915/gvt: fix deadlock in workload_thread) already
insert a lock there now.

So, please skip this patch.

> -- 
> Open Source Technology Center, Intel ltd.
> 
> $gpg --keyserver wwwkeys.pgp.net --recv-keys 4D781827



-- 
Thanks,
Changbin Du
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 473 bytes
Desc: not available
URL: <https://lists.freedesktop.org/archives/intel-gvt-dev/attachments/20170217/a90b81ff/attachment.sig>