From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org X-Spam-Level: X-Spam-Status: No, score=-2.5 required=3.0 tests=DKIMWL_WL_HIGH,DKIM_SIGNED, DKIM_VALID,MAILING_LIST_MULTI,SPF_HELO_NONE,SPF_PASS,URIBL_BLOCKED, USER_AGENT_SANE_1 autolearn=no autolearn_force=no version=3.4.0 Received: from mail.kernel.org (mail.kernel.org [198.145.29.99]) by smtp.lore.kernel.org (Postfix) with ESMTP id 93ED8C433E0 for ; Wed, 1 Jul 2020 10:56:15 +0000 (UTC) Received: from merlin.infradead.org (merlin.infradead.org [205.233.59.134]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mail.kernel.org (Postfix) with ESMTPS id 6111520702 for ; Wed, 1 Jul 2020 10:56:15 +0000 (UTC) Authentication-Results: mail.kernel.org; dkim=pass (2048-bit key) header.d=lists.infradead.org header.i=@lists.infradead.org header.b="IuCEddJ+"; dkim=fail reason="signature verification failed" (1024-bit key) header.d=kernel.org header.i=@kernel.org header.b="MgR12O8n" DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org 6111520702 Authentication-Results: mail.kernel.org; dmarc=fail (p=none dis=none) header.from=kernel.org Authentication-Results: mail.kernel.org; spf=none smtp.mailfrom=linux-arm-kernel-bounces+linux-arm-kernel=archiver.kernel.org@lists.infradead.org DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=lists.infradead.org; s=merlin.20170209; h=Sender:Content-Transfer-Encoding: Content-Type:Cc:List-Subscribe:List-Help:List-Post:List-Archive: List-Unsubscribe:List-Id:In-Reply-To:MIME-Version:References:Message-ID: Subject:To:From:Date:Reply-To:Content-ID:Content-Description:Resent-Date: Resent-From:Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID:List-Owner; bh=dVokN0FKsCwpI5rKcTktATj48EyMHilX8gD4tg16+Ac=; b=IuCEddJ+mDiJoGrlXIsd+jZhG ZTH/JsVtCJa+apWbH6jnvvD5kuG9R0kWH9flqwvm7KPM5p8wwyd4Cibj36wqiK2uit3BQNBu/1MSX zbQoURlX4z5+oPK4MDxrhq7nq2Ap6Hc64T7s8spCb55510nnCcqaE68EYiXyMNTiCy2THfrwY3XCB Yxc6+9AmpMWlCLEyRcmNlP8AunAEB+5hWZZrGhHFF+UkLdURLcsS5UOu2TjjDaXj6ld19iWxu3ANd ZKeoxRoFTPv4q1wT9EWcF1Cap2YLK6b4f7foynptB2mHGvrQBF7Px2db/szMsGiO1qZ0KRTNKCM23 dOWsky2OA==; Received: from localhost ([::1] helo=merlin.infradead.org) by merlin.infradead.org with esmtp (Exim 4.92.3 #3 (Red Hat Linux)) id 1jqaOL-0000wt-9U; Wed, 01 Jul 2020 10:55:01 +0000 Received: from mail.kernel.org ([198.145.29.99]) by merlin.infradead.org with esmtps (Exim 4.92.3 #3 (Red Hat Linux)) id 1jqaOJ-0000wH-15 for linux-arm-kernel@lists.infradead.org; Wed, 01 Jul 2020 10:54:59 +0000 Received: from willie-the-truck (236.31.169.217.in-addr.arpa [217.169.31.236]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mail.kernel.org (Postfix) with ESMTPSA id EBABC20772; Wed, 1 Jul 2020 10:54:56 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=default; t=1593600898; bh=kFLbdxE6sSIcNsnsddE2qZP4FZAiRNNpfl5wA+Xrld0=; h=Date:From:To:Cc:Subject:References:In-Reply-To:From; b=MgR12O8nRyvqokAVh6wbQMK5Ovx61t7pTRUxsEqpRRgDam5/Wioi2uTYGRtF0oUav o/j3NjcDMdGIPdHvroRHw/22S4Z24639UdcXlTEFTN86GEtAlsdP2Ra69RDntWcqHT NyOMy7+IXZOsU0q3rmsKRSXbY9aO+mEX1zvBlEZs= Date: Wed, 1 Jul 2020 11:54:54 +0100 From: Will Deacon To: Bjorn Andersson Subject: Re: [RFC 0/2] iommu: arm-smmu: Add support for early direct mappings Message-ID: <20200701105453.GG14959@willie-the-truck> References: <20191209150748.2471814-1-thierry.reding@gmail.com> <20200228025700.GA856087@builder> <20200514193249.GE279327@builder.lan> <20200527110343.GD11111@willie-the-truck> <20200602063210.GT11847@yoga> <20200701074050.GO388985@builder.lan> MIME-Version: 1.0 Content-Disposition: inline In-Reply-To: <20200701074050.GO388985@builder.lan> User-Agent: Mutt/1.10.1 (2018-07-13) X-CRM114-Version: 20100106-BlameMichelson ( TRE 0.8.0 (BSD) ) MR-646709E3 X-CRM114-CacheID: sfid-20200701_065459_150502_67E6FB0D X-CRM114-Status: GOOD ( 21.35 ) X-BeenThere: linux-arm-kernel@lists.infradead.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Cc: linux-arm-msm , iommu@lists.linux-foundation.org, Jordan Crouse , Thierry Reding , John Stultz , linux-tegra@vger.kernel.org, Robin Murphy , linux-arm-kernel Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: "linux-arm-kernel" Errors-To: linux-arm-kernel-bounces+linux-arm-kernel=archiver.kernel.org@lists.infradead.org On Wed, Jul 01, 2020 at 12:40:50AM -0700, Bjorn Andersson wrote: > On Wed 03 Jun 04:00 PDT 2020, Robin Murphy wrote: > > at that point I'm inclined to suggest we give up and stop trying to > > drive these things with arm-smmu. The XZR thing was bad enough, but if > > they're not even going to pretend to implement the architecture correctly > > then I'm not massively keen to continue tying the architectural driver in > > further knots if innocent things like CONFIG_IOMMU_DEFAULT_PASSTHROUGH are > > going to unexpectedly and catastrophically fail. We have qcom-iommu for > > hypervisor-mediated SMMUs, and this new hypervisor behaviour sounds to me > > more like "qcom-iommu++" with reassignable stream-to-context mappings, > > rather than a proper Arm SMMU emulation. > > > > I've been going through over and over, hoping to perhaps be able to > evolve qcom_iommu into a qcom-iommu++, but afaict the new hypervisor is > different enough that this isn't feasible. In particular, the platforms > using qcom_iommu relies entirely on the hypervisor to configure stream > mapping etc - and we can't even read most of the registers. > > On the other hand I agree with you that we're messing around quite a bit > with the arm-smmu driver, and I'm uncertain where we are on supporting > the various GPU features, so I'm adding Jordan to the thread. > > So, afaict we have the options of either shoehorning this too into the > arm-smmu driver or we essentially fork arm-smmu.c to create a > qcom-smmu.c. > > While I don't fancy the code duplication, it would allow us to revert > the Qualcomm quirks from arm-smmu and would unblock a number of > activities that we have depending on getting the SMMU enabled on various > platforms. We added the impl hooks to cater for implementation differences, so I'd still prefer to see this done as part of arm-smmu than introduce another almost-the-same-but-not-quite IOMMU driver that has the lifetime of a single SoC. Will _______________________________________________ linux-arm-kernel mailing list linux-arm-kernel@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-arm-kernel