[PATCH] drm/i915/gvt: Use fence error from GVT request for workload status

[Zhenyu Wang]

On 2017.06.23 03:26:29 +0000, Dong, Chuanxiao wrote:
> 
> 
> > -----Original Message-----
> > From: Zhenyu Wang [mailto:zhenyuw at linux.intel.com]
> > Sent: Friday, June 23, 2017 11:09 AM
> > To: Dong, Chuanxiao <chuanxiao.dong at intel.com>
> > Cc: intel-gvt-dev at lists.freedesktop.org
> > Subject: Re: [PATCH] drm/i915/gvt: Use fence error from GVT request for
> > workload status
> > 
> > On 2017.06.21 11:28:47 +0800, Chuanxiao Dong wrote:
> > > The req->fence.error will be set if this request caused GPU hang so we
> > > can use this value to workload->status to indicate whether this GVT
> > > request caused any problem. If it caused GPU hang, we shouldn't
> > > trigger any context switch back to the guest.
> > >
> > > Fixes: 8f1117abb408 (drm/i915/gvt: handle workload lifecycle properly)
> > > Signed-off-by: Chuanxiao Dong <chuanxiao.dong at intel.com>
> > > ---
> > >  drivers/gpu/drm/i915/gvt/scheduler.c | 17 ++++++++---------
> > >  1 file changed, 8 insertions(+), 9 deletions(-)
> > >
> > > diff --git a/drivers/gpu/drm/i915/gvt/scheduler.c
> > > b/drivers/gpu/drm/i915/gvt/scheduler.c
> > > index 488fdea..e7a18d8 100644
> > > --- a/drivers/gpu/drm/i915/gvt/scheduler.c
> > > +++ b/drivers/gpu/drm/i915/gvt/scheduler.c
> > > @@ -174,15 +174,6 @@ static int shadow_context_status_change(struct
> > notifier_block *nb,
> > >  		atomic_set(&workload->shadow_ctx_active, 1);
> > >  		break;
> > >  	case INTEL_CONTEXT_SCHEDULE_OUT:
> > > -		/* If the status is -EINPROGRESS means this workload
> > > -		 * doesn't meet any issue during dispatching so when
> > > -		 * get the SCHEDULE_OUT set the status to be zero for
> > > -		 * good. If the status is NOT -EINPROGRESS means there
> > > -		 * is something wrong happened during dispatching and
> > > -		 * the status should not be set to zero
> > > -		 */
> > > -		if (workload->status == -EINPROGRESS)
> > > -			workload->status = 0;
> > >  		atomic_set(&workload->shadow_ctx_active, 0);
> > >  		break;
> > >  	default:
> > > @@ -427,6 +418,14 @@ static void complete_current_workload(struct
> > intel_gvt *gvt, int ring_id)
> > >  		wait_event(workload->shadow_ctx_status_wq,
> > >  			   !atomic_read(&workload->shadow_ctx_active));
> > >
> > > +		/* If this request caused GPU hang, req->fence.error will
> > > +		 * be set. Use req->fence.error to set workload status so
> > > +		 * that when this request caused GPU hang, didn't trigger
> > > +		 * context switch interrupt to guest
> > > +		 */
> > > +		if (workload->status == -EINPROGRESS)
> > > +			workload->status = workload->req->fence.error;
> > > +
> > 
> > If gpu hang is not caused by request, still need to cover for guest state right?
> > With this need to check if it's really guilty for -EIO.
> 
> Right, so here is to check if req->fence.error is -EIO. If it is, workload->status = -EIO, otherwise workload->status = 0?
> 

yeah, you can resolve gvt workload state here or when you check it before
whether to update guest context.

-- 
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: 195 bytes
Desc: not available
URL: <https://lists.freedesktop.org/archives/intel-gvt-dev/attachments/20170623/c5151e8e/attachment-0001.sig>