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

[Du, Changbin]

Ping... This can reduce the impact of guest tdr spreading to other VMs.
We may need it.

On Thu, Feb 09, 2017 at 10:15:53AM +0800, changbin.du at intel.com wrote:
> From: Changbin Du <changbin.du at intel.com>
> 
> It is meaningless that dispatch workload request to i915 when i915 is
> resetting chip, especially when the hang is not caused by guest who own
> the workload. This patch can reduce possible guest vgpu hang when host
> or anthor VMs cause a chip reset.
> 
> Signed-off-by: Changbin Du <changbin.du at intel.com>
> ---
>  drivers/gpu/drm/i915/gvt/scheduler.c | 16 ++++++++++++++++
>  1 file changed, 16 insertions(+)
> 
> diff --git a/drivers/gpu/drm/i915/gvt/scheduler.c b/drivers/gpu/drm/i915/gvt/scheduler.c
> index 7ea68a7..ca29fb4 100644
> --- a/drivers/gpu/drm/i915/gvt/scheduler.c
> +++ b/drivers/gpu/drm/i915/gvt/scheduler.c
> @@ -406,8 +406,24 @@ static int workload_thread(void *priv)
>  	gvt_dbg_core("workload thread for ring %d started\n", ring_id);
>  
>  	while (!kthread_should_stop()) {
> +		workload = NULL;
>  		add_wait_queue(&scheduler->waitq[ring_id], &wait);
>  		do {
> +			/**
> +			 * we only wait for reset, but do not wait for wedged.
> +			 * For wedged, just let the workloads fail when dispatch
> +			 * them.
> +			 */
> +			if (i915_reset_in_progress(&gvt->dev_priv->gpu_error)) {
> +				gvt_dbg_core("wait i915 finish chip reset\n");
> +				ret = wait_on_bit_timeout(
> +						&gvt->dev_priv->gpu_error.flags,
> +						I915_RESET_IN_PROGRESS,
> +						TASK_UNINTERRUPTIBLE,
> +						HZ);
> +				if (ret)
> +					continue;
> +			}
>  			workload = pick_next_workload(gvt, ring_id);
>  			if (workload)
>  				break;
> -- 
> 2.7.4
> 

-- 
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/4dbfcd4e/attachment.sig>