Received: by 2002:a05:6a10:6744:0:0:0:0 with SMTP id w4csp3785772pxu; Mon, 12 Oct 2020 00:35:49 -0700 (PDT) X-Google-Smtp-Source: ABdhPJyD4I6GZWDXosZPtytRi5gLRbOAj6m79V8abgJyWJqKW5uumh3xAcnTGOfl73hmOO0n5F/N X-Received: by 2002:aa7:c390:: with SMTP id k16mr13192646edq.40.1602488148983; Mon, 12 Oct 2020 00:35:48 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1602488148; cv=none; d=google.com; s=arc-20160816; b=uB8PvTNOuDT24PGleOLUi8Mo1M7oA5oASnGb95Kld6WUQ9RI4pBUbOj6dPOw1YjgG4 TKZzezzFtwj4VimKEFzrgv8VeKdi1rdNfUoyXuxUtZth1FdntI5szwimk5T3XLaPEhIl sLJinG9kHP7fFXI9AgeefBaqgPobC2O7RtqhVoE5oF53MbCzimTjaaPv2CuXbzKVBkZW zE8Rq06khYom3KX1ePxc/v/ToHBBzFTRCy3K/5zwKaJnoIygFRPO2GrbxOe+YiLfDEfp JWQJOnl8XKasul9CTPvvpWxxiMdBl4NpVYP+vjVX8cXCiJ9TlmjanZJCKfalALth3/zh 0eBQ== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:in-reply-to:content-disposition:mime-version :references:message-id:subject:cc:to:from:date:dkim-signature; bh=CzDxLaDLFJzWcap/ARMkfpBesRsQ6cFDLsAfzEHhwNg=; b=XYfc6opCRNqjDtIdViB3CIHChzR3GQYMJTWNrPw4SEwp0bs5ATV2webjQPSW0a33Dk eBF5PmRezSedneoGPHZvUuk37GbmBXrTRdRxFNPbbDcl4hKaJ408kAFipI5aXhRIRYRL 9gEc89WKWZPeD4fs0IJPhM0M8in51JXYBJm0WoT8WQjugIQg8X4OCh/BatawLSONlw6A IKroAm4zO0yPLszUhoq2AKRY6wvzkshWLG5RI25hHzhQ3FFeJpBv6HebfMtlZDpmG5A7 W++N6lTvk/c47PbnL3vEhloMkX0bBRSNuXho2qPrpt9Y64aadlex2P/ZiGAf4B/i8RZM nOoQ== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@linaro.org header.s=google header.b=b0UFofGe; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=linaro.org Return-Path: Received: from vger.kernel.org (vger.kernel.org. [23.128.96.18]) by mx.google.com with ESMTP id r1si11468957eja.274.2020.10.12.00.35.25; Mon, 12 Oct 2020 00:35:48 -0700 (PDT) Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) client-ip=23.128.96.18; Authentication-Results: mx.google.com; dkim=pass header.i=@linaro.org header.s=google header.b=b0UFofGe; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=linaro.org Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1727417AbgJLHb6 (ORCPT + 99 others); Mon, 12 Oct 2020 03:31:58 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:58832 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1727392AbgJLHb6 (ORCPT ); Mon, 12 Oct 2020 03:31:58 -0400 Received: from mail-ed1-x541.google.com (mail-ed1-x541.google.com [IPv6:2a00:1450:4864:20::541]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 2C098C0613CE for ; Mon, 12 Oct 2020 00:31:56 -0700 (PDT) Received: by mail-ed1-x541.google.com with SMTP id x1so15861111eds.1 for ; Mon, 12 Oct 2020 00:31:56 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=linaro.org; s=google; h=date:from:to:cc:subject:message-id:references:mime-version :content-disposition:in-reply-to; bh=CzDxLaDLFJzWcap/ARMkfpBesRsQ6cFDLsAfzEHhwNg=; b=b0UFofGey9MHN4SSKeWJne/jISh0kZ4rKs08Umat1GtUhptcnknv3VsZFMe74YDxK8 +JFbEMLjSb3QLuIDhnLOtzA8nFoFEAtB07cpzErKshtf7030J2/yyB2L8QDfIJM6IFMG wOgjFRhEoC0PoIJ1v5e52Av5WQBBAKNAChPIDSvM3CHvCIEEA1uWvjmJ9cXZJvrc70R2 DbQR1JXv2jr8nGlgyMO1cZ1JtR6tayglpD8EwubGrKVXQgUgRCvptXMtyhJBm+3VbHFc qPo/L0Y73MO+zXoSQ+VKiA4TKFVoReqFKJE9CBqM6095iH22+gT3A2xMNboe/ZQxGfxl uF3w== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:date:from:to:cc:subject:message-id:references :mime-version:content-disposition:in-reply-to; bh=CzDxLaDLFJzWcap/ARMkfpBesRsQ6cFDLsAfzEHhwNg=; b=XvOEXAuXKgRrt4DC4edclmH8+H4syRWInOFUgY7IejAvzWWTjWscU0U2ktBYIrUdol tmPkdzsFyPAQSVsVJgOlDUXOV4Xm3ol42vA/0ASgvnb4juEEY+TYMv9vqWMLi0xk9IWj onnYvpxr5q2YIsmERP5Vd3xRCVdd5lpDlFXNQv9eMiWAd2Ae+LwCqBxgamEjh26HWfJ7 M0cu2WPj42vho0oe13MHrFGsxyC5UtmAsUoWrJHkMfxhOHC/Gh5ZSNHj91pioo3/yWuK kNbt07znARYKRgAgLnAMCSherC3l9hG+G4tBu/kwPU6XGPWgCWuHqIx+K/g3qsZQDsd7 Sz6w== X-Gm-Message-State: AOAM533bNVFrtVFPiOBVComrOqzN9oA+MGaRlri1eLZHFffHN97hxrWD dGMHdWN3LhvvXo52dXoaQNHY8A== X-Received: by 2002:aa7:dcc7:: with SMTP id w7mr12914876edu.80.1602487914471; Mon, 12 Oct 2020 00:31:54 -0700 (PDT) Received: from yoga ([194.182.8.81]) by smtp.gmail.com with ESMTPSA id n22sm10021525eji.106.2020.10.12.00.31.53 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Mon, 12 Oct 2020 00:31:53 -0700 (PDT) Date: Mon, 12 Oct 2020 09:31:52 +0200 From: Bjorn Andersson To: Will Deacon Cc: Robin Murphy , Joerg Roedel , Sai Prakash Ranjan , Jordan Crouse , Rob Clark , Sibi Sankar , linux-arm-kernel@lists.infradead.org, iommu@lists.linux-foundation.org, linux-kernel@vger.kernel.org, linux-arm-msm@vger.kernel.org Subject: Re: [PATCH v3 6/8] iommu/arm-smmu: Add impl hook for inherit boot mappings Message-ID: <20201012073152.GA2998@yoga> References: <20200904155513.282067-1-bjorn.andersson@linaro.org> <20200904155513.282067-7-bjorn.andersson@linaro.org> <0bfcc8f7-d054-616b-834b-319461b1ecb9@arm.com> <20200913032559.GT3715@yoga> <20200921210814.GE3811@willie-the-truck> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20200921210814.GE3811@willie-the-truck> Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Mon 21 Sep 23:08 CEST 2020, Will Deacon wrote: > On Sat, Sep 12, 2020 at 10:25:59PM -0500, Bjorn Andersson wrote: > > On Fri 11 Sep 12:13 CDT 2020, Robin Murphy wrote: > > > On 2020-09-04 16:55, Bjorn Andersson wrote: > > > > Add a new operation to allow platform implementations to inherit any > > > > stream mappings from the boot loader. > > > > > > Is there a reason we need an explicit step for this? The aim of the > > > cfg_probe hook is that the SMMU software state should all be set up by then, > > > and you can mess about with it however you like before arm_smmu_reset() > > > actually commits anything to hardware. I would have thought you could > > > permanently steal a context bank, configure it as your bypass hole, read out > > > the previous SME configuration and tweak smmu->smrs and smmu->s2crs > > > appropriately all together "invisibly" at that point. > > > > I did this because as of 6a79a5a3842b ("iommu/arm-smmu: Call > > configuration impl hook before consuming features") we no longer have > > setup pgsize_bitmap as we hit cfg_probe, which means that I need to > > replicate this logic to set up the iommu_domain. > > > > If I avoid setting up an iommu_domain for the identity context, as you > > request in patch 8, this shouldn't be needed anymore. > > > > > If that can't work, I'm very curious as to what I've overlooked. > > > > > > > I believe that will work, I will rework the patches and try it out. > > Did you get a chance to rework this? > Finally got a chance to dig through this properly. Initial results where positive and with an implementation of cfg_probe in qcom_smmu_impl I'm able to probe the arm-smmu driver just fine - and display (e.g. efifb) stays alive. Unfortunately as the display driver (drivers/gpu/drm/msm) is about to probe a new iommu domain is created, which due to its match against qcom_smmu_client_of_match[] becomes of type IOMMU_DOMAIN_IDENTITY. This results in a S2CR of BYPASS type, which the firmware intercepts and turns the stream into a type FAULT. So while the cfg_probe looks very reasonable we're still in need of a mechanism to use the fake identity context for the iommu domain associated with the display controller. The workings of the display driver is that it gets the iommu domain setup for byass and then after that creates a translation context for this same stream where it maps the framebuffer. For testing purposes I made def_domain_type always return 0 in the qcom impl and the result is that we get a few page faults while probing the display driver, but these are handled somewhat gracefully and the initialization did proceed and the system comes up nicely (but in the case that the display driver would probe defer this leads to an storm of faults as the screen continues to be refreshed). TL;DR I think we still need to have a way to get the arm-smmu driver to allow the qcom implementation to configure identity domains to use translation - but we can make the setup of the identity context a detail of the qcom driver. Regards, Bjorn