On ma, 2017-05-08 at 10:30 +0000, Dong, Chuanxiao wrote:
<SNIP>
> > > > > + 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");
<SNIP>
Something along the lines: "Graphics virtualization is not yet
supported with GuC" would be most informative to user.
> > >
> > 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...
I agree that currently when GuC submission is not enabled by default,
enabling it could result in -EIO on driver load if GVT is enabled
simultaneously.
When GuC gets enabled by default, it would be preferable for GVT team
to have support ready, or enable_gvt probably needs to become an
_unsafe param.
Regards, Joonas
--
Joonas Lahtinen
Open Source Technology Center
Intel Corporation
_______________________________________________
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
