On 3/21/2018 3:16 AM, Chris Wilson wrote:
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
Are you suggesting that we enable the cmd parser for every Gen < CNL for
this particular usage only? :P
_______________________________________________
Intel-gfx mailing list
Intel-gfx@xxxxxxxxxxxxxxxxxxxxx
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
