Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1754998Ab2K1NOM (ORCPT ); Wed, 28 Nov 2012 08:14:12 -0500 Received: from hqemgate03.nvidia.com ([216.228.121.140]:16599 "EHLO hqemgate03.nvidia.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1754284Ab2K1NOL (ORCPT ); Wed, 28 Nov 2012 08:14:11 -0500 X-PGP-Universal: processed; by hqnvupgp06.nvidia.com on Wed, 28 Nov 2012 05:13:55 -0800 Message-ID: <50B60EFF.1050703@nvidia.com> Date: Wed, 28 Nov 2012 15:17:51 +0200 From: =?ISO-8859-1?Q?Terje_Bergstr=F6m?= User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:16.0) Gecko/20121028 Thunderbird/16.0.2 MIME-Version: 1.0 To: Dave Airlie CC: Thierry Reding , Lucas Stach , "linux-tegra@vger.kernel.org" , "dri-devel@lists.freedesktop.org" , "linux-kernel@vger.kernel.org" , Arto Merilainen Subject: Re: [RFC v2 8/8] drm: tegra: Add gr2d device References: <1353935954-13763-1-git-send-email-tbergstrom@nvidia.com> <1353935954-13763-9-git-send-email-tbergstrom@nvidia.com> <50B46336.8030605@nvidia.com> <50B476E1.4070403@nvidia.com> <50B47DA8.60609@nvidia.com> <1354011776.1479.31.camel@tellur> <20121127103739.GA3329@avionic-0098.adnet.avionic-design.de> <50B4A483.8030305@nvidia.com> In-Reply-To: Content-Type: text/plain; charset="ISO-8859-1" Content-Transfer-Encoding: 7bit Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Length: 1436 Lines: 32 On 28.11.2012 01:00, Dave Airlie wrote: > We generally aim for the first, to stop the gpu from reading/writing > any memory it hasn't been granted access to, > the second is nice to have though, but really requires a GPU with VM > to implement properly. I wonder if we should aim at root only access on Tegra20, and force IOMMU on Tegra30 and fix the remaining issues we have with IOMMU. The firewall turns out to be more complicated than I wished. Biggest problem is that we aim at zero-copy for everything possible, including command streams. Kernel gets a handle to a command stream, but the command stream is allocated by the user space process. So the user space can tamper with the stream once it's been written to the host1x 2D channel. Copying with firewall is one option, but that would again kill the performance. One option would be user space unmapping the command buffer when it's sent to kernel, and kernel checking that it's unmapped before it agrees to send the stream to hardware. On Tegra30 with IOMMU turned on things are ok without any checks, because all access would go via MMU, which makes kernel memory inaccessible. Of course, better ideas are welcome. Terje -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/