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 _______________________________________________ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
