[Intel-gfx] [RFC v1] drm/i915: Add Exec param to control data port coherency.
chris at chris-wilson.co.uk
Wed Mar 21 10:16:22 UTC 2018
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.
More information about the Intel-gfx