[Intel-gfx] [RFC v1] drm/i915: Add Exec param to control data port coherency.

[Chris Wilson]

Quoting Oscar Mateo (2018-03-20 18:43:45)
> 
> 
> On 3/19/2018 7:14 AM, Lis, Tomasz wrote:
> >
> >
> > On 2018-03-19 13:43, Chris Wilson wrote:
> >> Quoting Tomasz Lis (2018-03-19 12:37:35)
> >>> The patch adds a parameter to control the data port coherency 
> >>> functionality
> >>> on a per-exec call basis. When data port coherency flag value is 
> >>> different
> >>> than what it was in previous call for the context, a command to 
> >>> switch data
> >>> port coherency state is added before the buffer to be executed.
> >> So this is part of the context? Why do it at exec level?
> >
> > It is part of the context, stored within HDC chicken bit register.
> > The exec level was requested by the OCL team, due to concerns about 
> > performance cost of context setparam calls.
> >
> >>   If exec level
> >> is desired, why not whitelist it?
> >> -Chris
> >
> > If we have no issue in whitelisting the register, I'm sure OCL will 
> > agree to that.
> > I assumed the whitelisting will be unacceptable because of security 
> > concerns with some options.
> > The register also changes its position and content between gens, which 
> > makes whitelisting hard to manage.
> >
> 
> I think a security analysis of this register was already done, and the 
> result was that it contains some other bits that could be dangerous. In 
> CNL those bits were moved out of the way and the HDC_CHICKEN0 register 
> can be whitelisted (WaAllowUMDToControlCoherency). In ICL the register 
> should already be non-privileged.

The previous alternative to whitelisting was running through a command
parser for validation. That's a very general mechanism suitable for a
wide range of sins.
-Chris