[Intel-gfx] [PATCH] drm/i915/gvt: disable GVT-g if host GuC submission is enabled

[Chris Wilson]

On Fri, May 05, 2017 at 11:55:14AM +0300, Joonas Lahtinen wrote:
> + Daniel
> 
> On ke, 2017-05-03 at 16:36 +0800, Zhenyu Wang wrote:
> > On 2017.05.02 16:58:31 +0800, Chuanxiao Dong wrote:
> > > 
> > > Currently GVT-g cannot work properly when host GuC submission
> > > is enabled, so disable GVT in this case.
> > > 
> > > Cc: Zhenyu Wang <zhenyuw at linux.intel.com>
> > > Signed-off-by: Chuanxiao Dong <chuanxiao.dong at intel.com>
> 
> <SNIP>
> 
> > > @@ -84,6 +84,11 @@ int intel_gvt_init(struct drm_i915_private *dev_priv)
> > >  		goto bail;
> > >  	}
> > >  
> > > +	if (i915.enable_guc_submission) {
> > > +		DRM_INFO("GPU guest virtualisation [GVT-g] disabled due to enabled GuC submission [i915.enable_guc_submission module parameter]\n");
> 
> Guest module parameter is not the correct way of detetecting if host
> has GuC submission enabled. And even if it was, the message is overly
> verbose (and it'll be incorrect once i915.enable_guc_submission
> defaults to something else than zero).

It needs to be verbose because it is a message to the user, it should
tell them what broke, what that will likely mean to them and if possible
how to rectify. Even then we know they won't read the entirety of the
message but at least it gives us a starting point for the inevitable
bugs. We should always aim for clarity and avoid too much jargon in
DRM_INFO+.

In this case, you could argue that i915.enable_guc_submission is an
unsafe parameter set to off by default and so the combination of gvt +
guc is pure user error and they can keep both pieces.

Ideally we wouldn't use i915.enable_guc_submission at all, but gvt
should be disabled upon enabling guc -- since the combination is currently
inoperable. But again, this is just a user error and we can just -EIO
the driver load...
-Chris

-- 
Chris Wilson, Intel Open Source Technology Centre