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=-14.2 required=3.0 tests=BAYES_00,DKIMWL_WL_HIGH, DKIM_SIGNED,DKIM_VALID,HEADER_FROM_DIFFERENT_DOMAINS,INCLUDES_CR_TRAILER, INCLUDES_PATCH,MAILING_LIST_MULTI,SPF_HELO_NONE,SPF_PASS autolearn=unavailable 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 DD297C11F66 for ; Tue, 29 Jun 2021 07:06:35 +0000 (UTC) Received: from bombadil.infradead.org (bombadil.infradead.org [198.137.202.133]) (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 9E04561DC6 for ; Tue, 29 Jun 2021 07:06:35 +0000 (UTC) DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org 9E04561DC6 Authentication-Results: mail.kernel.org; dmarc=none (p=none dis=none) header.from=solid-run.com 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=bombadil.20210309; h=Sender: Content-Transfer-Encoding:Content-Type:List-Subscribe:List-Help:List-Post: List-Archive:List-Unsubscribe:List-Id:Cc:To:Subject:Message-ID:Date:From: In-Reply-To:References:MIME-Version:Reply-To:Content-ID:Content-Description: Resent-Date:Resent-From:Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID: List-Owner; bh=ng/xapQHEWJcEcKDe56M60A4qlAr5a68YKa0kqrmyII=; b=pOeX4V1yrEnlwV 87De4hqdJ8ByxLyHIN1LDGyE1EPjxGs9uNuhnzz4g/cBhrASFN0YHDgqo+VBrDz0f4TxFYY6z4NhR u6P7iOw5IgZXKmAkTdtpObjXZ2QNzWvPfFpkyQqHRRcWzamOQdK23E51Q+NmciCDNP6yFYFgG7XMA Z5lF+kpVhK+81N1BJ9YKgCxG2WQ1i7sLrbwJx3oAhLIUfqbuMfkNChy7UGO/2LsBsTkDtZ/Bcm6OG Ws1XjDwAK7oVX7QftKggTiBy8r9922eP+LMXHiBUz//SnTp8lwJVfQKCdf+pzpVy5FgdgS6b2PwRh e+on1tG5+ucaopmHaJGg==; Received: from localhost ([::1] helo=bombadil.infradead.org) by bombadil.infradead.org with esmtp (Exim 4.94.2 #2 (Red Hat Linux)) id 1ly7ne-009zix-0W; Tue, 29 Jun 2021 07:04:50 +0000 Received: from mail-ej1-x632.google.com ([2a00:1450:4864:20::632]) by bombadil.infradead.org with esmtps (Exim 4.94.2 #2 (Red Hat Linux)) id 1ly7nZ-009zhi-S7 for linux-arm-kernel@lists.infradead.org; Tue, 29 Jun 2021 07:04:47 +0000 Received: by mail-ej1-x632.google.com with SMTP id o11so21371942ejd.4 for ; Tue, 29 Jun 2021 00:04:36 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=solid-run-com.20150623.gappssmtp.com; s=20150623; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=NYBTmnbrFY6e4uVDJho3HTMoNaiYI6JT+kpQ+czjgBc=; b=ubbHAgyQ+0/up/IYI6m2dbl28D92eV8V1EjvNKM2mtc2mwfewaWs651zFMwhO4/iUI V/QngHmNVz57v2VAELy6TB/A4Gs3HKFOsxSYkaPKMric5VI8q4e6RGpFxJl/PZRK1P1Z vQ4oWjoToo0geS57I9ByRm6DaObhdZWlbsgO7KhvRq26ssAgNth0DY9kNLw1deDKYXWa uaXW70YyHvJdDWVdW3pL97GaulAZCfJvaMkOw06iKlCjLC7LgSO+jV9b2898wO5e2Gyn nJKGmytoVCTwXkIaYoRDCttjNxFlnB6CwkjxtO7uz1CO1751NNXBkwrHhAM4i4C0K7MB EP/g== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=NYBTmnbrFY6e4uVDJho3HTMoNaiYI6JT+kpQ+czjgBc=; b=h4JwQGtxKmul+AtdqJ0P4xv/xY2QoV4h+ZeOcSGQpj8dK089IqpMxzHM1lIW6V94Bp qMsF5XTDhP7wxlnxpW+l9KjXjnzJ/jA6nX3tttG2ZAwnu+6UVWaa/SxZqfDgiUxSlkFd P/lOqJDiNmIxHO8COKmo+jGH6Fa8f4tIK5liH5RYQw1bge2/ftndgc87E3IdzwJvuCnw 8KDEvgWxUslhdznWfp6RvKDz5I4Hqx9UAjH3oeTGlxmriDijbpB0eUIXfTD50p/G1LjC NTnW1VA9UElAMYjQk95hPOMDNR7CiE5Ov3d/EYdUz/vNb/qJ/XinfR3B+4ZF8U2PrXRD pWkQ== X-Gm-Message-State: AOAM531EkyK6l/MGI3ozS5oZwSq7h7oNweNXGFhiwojPJRSLxbMTJkOF uxWV+6+QZhtAA/k4GPsfdYqcHV2dwE09hLW8x2yIqg== X-Google-Smtp-Source: ABdhPJxtQA+v0rp/NT2snj2jrDToSRx2to2k1C/zj58bDlD0p023vCUDoh9aRvnwnKFJjf8Le0Lu/hijhCo63Uyqk2Q= X-Received: by 2002:a17:907:c87:: with SMTP id gi7mr28276614ejc.452.1624950274959; Tue, 29 Jun 2021 00:04:34 -0700 (PDT) MIME-Version: 1.0 References: <20210524110222.2212-1-shameerali.kolothum.thodi@huawei.com> <20210524110222.2212-8-shameerali.kolothum.thodi@huawei.com> <2bc3ae21-f2af-ee2c-5e9d-d47633e0439e@arm.com> In-Reply-To: <2bc3ae21-f2af-ee2c-5e9d-d47633e0439e@arm.com> From: Jon Nettleton Date: Tue, 29 Jun 2021 09:03:57 +0200 Message-ID: Subject: Re: [PATCH v5 7/8] iommu/arm-smmu: Get associated RMR info and install bypass SMR To: Robin Murphy Cc: Shameer Kolothum , linux-arm-kernel , ACPI Devel Maling List , iommu@lists.linux-foundation.org, Linuxarm , Steven Price , Hanjun Guo , yangyicong , Sami.Mujawar@arm.com, wanghuiqiang X-CRM114-Version: 20100106-BlameMichelson ( TRE 0.8.0 (BSD) ) MR-646709E3 X-CRM114-CacheID: sfid-20210629_000445_978451_DE62BD9D X-CRM114-Status: GOOD ( 38.50 ) X-BeenThere: linux-arm-kernel@lists.infradead.org X-Mailman-Version: 2.1.34 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , 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 Mon, Jun 14, 2021 at 12:06 PM Robin Murphy wrote: > > On 2021-05-24 12:02, Shameer Kolothum wrote: > > From: Jon Nettleton > > > > Check if there is any RMR info associated with the devices behind > > the SMMU and if any, install bypass SMRs for them. This is to > > keep any ongoing traffic associated with these devices alive > > when we enable/reset SMMU during probe(). > > > > Signed-off-by: Jon Nettleton > > Signed-off-by: Steven Price > > Signed-off-by: Shameer Kolothum > > --- > > drivers/iommu/arm/arm-smmu/arm-smmu.c | 65 +++++++++++++++++++++++++++ > > 1 file changed, 65 insertions(+) > > > > diff --git a/drivers/iommu/arm/arm-smmu/arm-smmu.c b/drivers/iommu/arm/arm-smmu/arm-smmu.c > > index 6f72c4d208ca..56db3d3238fc 100644 > > --- a/drivers/iommu/arm/arm-smmu/arm-smmu.c > > +++ b/drivers/iommu/arm/arm-smmu/arm-smmu.c > > @@ -2042,6 +2042,67 @@ err_reset_platform_ops: __maybe_unused; > > return err; > > } > > > > +static void arm_smmu_rmr_install_bypass_smr(struct arm_smmu_device *smmu) > > +{ > > + struct list_head rmr_list; > > + struct iommu_resv_region *e; > > + int i, cnt = 0; > > + u32 smr; > > + u32 reg; > > + > > + INIT_LIST_HEAD(&rmr_list); > > + if (iommu_dma_get_rmrs(dev_fwnode(smmu->dev), &rmr_list)) > > + return; > > + > > + reg = arm_smmu_gr0_read(smmu, ARM_SMMU_GR0_sCR0); > > + > > + if ((reg & ARM_SMMU_sCR0_USFCFG) && !(reg & ARM_SMMU_sCR0_CLIENTPD)) { > > + /* > > + * SMMU is already enabled and disallowing bypass, so preserve > > + * the existing SMRs > > + */ > > + for (i = 0; i < smmu->num_mapping_groups; i++) { > > + smr = arm_smmu_gr0_read(smmu, ARM_SMMU_GR0_SMR(i)); > > To reiterate, just because a bootloader/crashed kernel/whatever may have > left some configuration behind doesn't mean that it matters (e.g. what > if these SMRs are pointing at translation contexts?). All we should be > doing here is setting the relevant RMR accommodations in our "clean > slate" software state before the reset routine applies it to the > hardware, just like patch #5 does for SMMUv3. > > Trying to safely reset an SMMU when we discover it with CLIENTPD=0 is > really another issue entirely, and I'd say is beyond the scope of this > series > > > + if (!FIELD_GET(ARM_SMMU_SMR_VALID, smr)) > > + continue; > > Note that that's not even necessarily correct (thanks to EXIDS). > > > + smmu->smrs[i].id = FIELD_GET(ARM_SMMU_SMR_ID, smr); > > + smmu->smrs[i].mask = FIELD_GET(ARM_SMMU_SMR_MASK, smr); > > + smmu->smrs[i].valid = true; > > + } > > + } > > + > > + list_for_each_entry(e, &rmr_list, list) { > > + u32 sid = e->fw_data.rmr.sid; > > + > > + i = arm_smmu_find_sme(smmu, sid, ~0); > > + if (i < 0) > > + continue; > > + if (smmu->s2crs[i].count == 0) { > > + smmu->smrs[i].id = sid; > > + smmu->smrs[i].mask = ~0; > > This is very wrong (as has now already been pointed out). > > > + smmu->smrs[i].valid = true; > > + } > > + smmu->s2crs[i].count++; > > + smmu->s2crs[i].type = S2CR_TYPE_BYPASS; > > + smmu->s2crs[i].privcfg = S2CR_PRIVCFG_DEFAULT; > > + smmu->s2crs[i].cbndx = 0xff; > > Nit: cbndx is left uninitialised for bypass/fault entries elsewhere, so > there's little point touching it here. > > > + > > + cnt++; > > + } > > + > > + if ((reg & ARM_SMMU_sCR0_USFCFG) && !(reg & ARM_SMMU_sCR0_CLIENTPD)) { > > + /* Remove the valid bit for unused SMRs */ > > + for (i = 0; i < smmu->num_mapping_groups; i++) { > > + if (smmu->s2crs[i].count == 0) > > + smmu->smrs[i].valid = false; > > + } > > If this dance is only about avoiding stream match conflicts when trying > to reprogram live SMRs, simply turning the SMMU off beforehand would be > a lot simpler. Robin, I am not sure what you mean here, and maybe Steve wants to jump in and help clarify. My understanding is that "dance" is required for regions that need to continue to work throughout the boot process. I think the example I have seen the most is for GOP drivers that use system memory rather than dedicated VRAM. -Jon > > Robin. > > > + } > > + > > + dev_notice(smmu->dev, "\tpreserved %d boot mapping%s\n", cnt, > > + cnt == 1 ? "" : "s"); > > + iommu_dma_put_rmrs(dev_fwnode(smmu->dev), &rmr_list); > > +} > > + > > static int arm_smmu_device_probe(struct platform_device *pdev) > > { > > struct resource *res; > > @@ -2168,6 +2229,10 @@ static int arm_smmu_device_probe(struct platform_device *pdev) > > } > > > > platform_set_drvdata(pdev, smmu); > > + > > + /* Check for RMRs and install bypass SMRs if any */ > > + arm_smmu_rmr_install_bypass_smr(smmu); > > + > > arm_smmu_device_reset(smmu); > > arm_smmu_test_smr_masks(smmu); > > > > _______________________________________________ linux-arm-kernel mailing list linux-arm-kernel@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-arm-kernel