On 27.11.2012 13:47, Lucas Stach wrote: > I guess we could change IOMMU address spaces for the graphics units > depending on the active channel. This would still be a bit of a > performance hit, because of the necessary TLB flushing and so on, but > should be much better than checking the whole command stream. This way > you at least get security on a process level, as no process is able to > corrupt another processes graphics resources. One physical channel is shared with all users of the 2D unit. Each job is just added to the queue, and host1x will happily cross from one job to the next without intervention from CPU. This is done to keep CPU overhead down to improve power and performance. This also means that we cannot change the IOMMU settings between jobs from different processes, unless we pause the channel after every job. This is still an interesting thought - can we postpone binding of a buffer to address space until submit time, and give each process its own address space? We would have a limit of "submits from three processes going on at once" instead of "three processes can open 2D channel at once". That's a limitation we could live with. Naturally, Tegra2 is still left in the cold. > This is the same level of security as provided by the nouveau driver. > But to do so all memory management has to be done in kernel and from the > current submissions of the 2D infrastructure I fear that the current > architecture does too much of that in userspace, but I'll hold back with > any judgement until we actually get to see the userspace parts. User space allocates buffer, exports as dmabuf fd, and passes the fd in submits to kernel, and frees the buffer. No other memory management is done in user space. > Also to implement this strategy you have to take ownership of the > graphics address space on a much lower level than the DMA API. This > might take some work together with the IOMMU guys. I'll go through this with Hiroshi, who knows that area. Terje _______________________________________________ dri-devel mailing list dri-devel@xxxxxxxxxxxxxxxxxxxxx http://lists.freedesktop.org/mailman/listinfo/dri-devel
