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 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 smtp.lore.kernel.org (Postfix) with ESMTPS id F41F7CD54BE for ; Mon, 25 Sep 2023 18:36:11 +0000 (UTC) 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:MIME-Version:In-Reply-To:References: Message-ID:Subject:Cc: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=XHpLwqw3OTbYUqNkdEEqF/UJvY598eD/avTodGPDWJY=; b=aq3Kmffq9JEw3c UhzgCIp3Bl9L8Xip2cs4CmorN+UNw3+kaCzANwVme1ukM3lL6l1lyYTc9iC+yEjz+LYPgCokbT1LY MXuQO9WxRf5CtVTCMzrzWJNpFcHM66s7+IJV6v0V1g6qn+Av4oGGEleQXhXnMaDyunao8tYWxc8+y 7+HVXtNKmP058XgZ/sK0oZy+BjgdWCIKhgfa5a5Cro/Tgatkg07bcXR4RAoGyhiton4RDJEKEkkgj nUFqe/97t06j2sJD0BZ3QHa/s9zSW5cGOuDlOEq3zAGYMuRrxrKlr/9jpEh6agCq8tNeC2yJKrQte dawcocPjBnrRzoKnVKPA==; Received: from localhost ([::1] helo=bombadil.infradead.org) by bombadil.infradead.org with esmtp (Exim 4.96 #2 (Red Hat Linux)) id 1qkqQh-00EqZH-26; Mon, 25 Sep 2023 18:35:35 +0000 Received: from mail-dm6nam12on20603.outbound.protection.outlook.com ([2a01:111:f400:fe59::603] helo=NAM12-DM6-obe.outbound.protection.outlook.com) by bombadil.infradead.org with esmtps (Exim 4.96 #2 (Red Hat Linux)) id 1qkqQd-00EqYT-1z for linux-arm-kernel@lists.infradead.org; Mon, 25 Sep 2023 18:35:33 +0000 ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=RwvOXMm5vjMSX7X+ZUJV4zpOS7Ja1I/WfZWI6V2gEew9kmDfTq7nTuj/ae1/O6HhrtaVxQAJO21YgCB/Yxua8IYXikOzp8DYKTfh7D784NkSiQxtE0Uxrpeuk3RulvWn/RncPfT49DW8H/7dA4eCDDQiAdhkTt2luAZUJXzy+RS48PiOpbrwk5hru927DSFzhWihzW4YVikmb35fyjrEcsLNdvyHvtUnifkr2R58noM51mE32BZYBDCO8v6qLsduuqzbNBedOrUubsHN3kLz+C5skX9hLVK0S1cZZVb6dGHnjdPyt5l5zujvDJ72ai45tUDDelRdjy3sl1k3JJhILQ== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector9901; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1; bh=fEOxq62bgI2lhrHjM4fnL5vIJAEBYGkH1TMeqqY/DfI=; b=dVrbRY6Z2AmhwblJofiyuR77WEt3rQ2vL5ScTx6nNvDrif7LWSG5EwhA0MObjZOqXjX8g01u4H6gcbfqoU4Ga98oJrm8YATbXK22BqzdVV4YLQl3E7kCUWyUPWnJlwTB4pWm/pvfU/KSbfHiDBgSENm2P4Qg9Wo/Nyycsk6zjL4z+m12KhfEUVQaLfdXWClwMTvE8HIB+VAZLwcrVooJjVQZdPHeCFM7wQMwFoMvOZgIfQJ0uID/KHV6feK8dxAaBYO+E4y9oDbf5bTo/v7pXXhE/SFNYQyeZD3To/XlPTp/B2H0cDZjozj/iiA6GscrBpxliKu65YA63NX4r97f5g== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=nvidia.com; dmarc=pass action=none header.from=nvidia.com; dkim=pass header.d=nvidia.com; arc=none DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=Nvidia.com; s=selector2; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=fEOxq62bgI2lhrHjM4fnL5vIJAEBYGkH1TMeqqY/DfI=; b=VmogJ0vrU65LoM11F41CrZ5H71yRw7t/nuCxlY8RhyTzi5o9OSl1HZIUbjHZx2M6Gws8i4feNvtBJ+Jtrc+LPuzjH4Ns5PdQ0bBJ0HRk/tU31x9PFO+6xX9bnuZAW586cIyPEdndgMvuzijUQjJ9t47JE19GLOpCMymD+i3KHxzwnb40ImHYvXyVRbr/5l9/G1zimFWIkLrFD3ucF0DrHj+Fdrx0GztdqMhi68GqEdkF7JbeU2LDxmqRMjYXaFuuHR04Oz7nREHfNNk4lrq9a1nW0AnkQlZehcfiJgHWhnUVLErnJMg8+cTH4FVR2r7i3M2Q6oJvBmzxfo06dUMPGQ== Authentication-Results: dkim=none (message not signed) header.d=none;dmarc=none action=none header.from=nvidia.com; Received: from LV2PR12MB5869.namprd12.prod.outlook.com (2603:10b6:408:176::16) by CY5PR12MB6599.namprd12.prod.outlook.com (2603:10b6:930:41::11) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.6813.21; Mon, 25 Sep 2023 18:35:25 +0000 Received: from LV2PR12MB5869.namprd12.prod.outlook.com ([fe80::faf:4cd0:ae27:1073]) by LV2PR12MB5869.namprd12.prod.outlook.com ([fe80::faf:4cd0:ae27:1073%6]) with mapi id 15.20.6792.026; Mon, 25 Sep 2023 18:35:24 +0000 Date: Mon, 25 Sep 2023 15:35:23 -0300 From: Jason Gunthorpe To: Nicolin Chen Cc: will@kernel.org, robin.murphy@arm.com, joro@8bytes.org, jean-philippe@linaro.org, mshavit@google.com, linux-kernel@vger.kernel.org, linux-arm-kernel@lists.infradead.org, iommu@lists.linux.dev Subject: Re: [PATCH v4 2/2] iommu/arm-smmu-v3: Refactor arm_smmu_write_strtab_ent() Message-ID: <20230925183523.GJ13733@nvidia.com> References: <6e1fdea8ab43ea28e7e3c79eb6605dea71548c53.1695242337.git.nicolinc@nvidia.com> Content-Disposition: inline In-Reply-To: <6e1fdea8ab43ea28e7e3c79eb6605dea71548c53.1695242337.git.nicolinc@nvidia.com> X-ClientProxiedBy: BL1PR13CA0371.namprd13.prod.outlook.com (2603:10b6:208:2c0::16) To LV2PR12MB5869.namprd12.prod.outlook.com (2603:10b6:408:176::16) MIME-Version: 1.0 X-MS-PublicTrafficType: Email X-MS-TrafficTypeDiagnostic: LV2PR12MB5869:EE_|CY5PR12MB6599:EE_ X-MS-Office365-Filtering-Correlation-Id: 45782ecf-a96a-4a3e-0182-08dbbdf62ebf X-MS-Exchange-SenderADCheck: 1 X-MS-Exchange-AntiSpam-Relay: 0 X-Microsoft-Antispam: BCL:0; X-Microsoft-Antispam-Message-Info: xo6x4x81XQuIN3KCCxACotY7OzXpzpGlzarfEFPwf75IMIjngyYkCwtKKKuk7BpNSj6IoLMqoVetaPCHc7SpzIsi8enKC40IBh4A9BmyzHQAon6ApyijGkmkXl0RiHhIo4r3Xgy3haY/1Gf+RN12FMPzBvGu2nsVx5pFkwLUGmFsuafsDgmfR4+8JXmmf3FT1UxKd15M1+KKYpIekciGkMuyRONlGKAbDTGC2YCAIoDVPBOsl/tPIfJLWxHYKTgDtjY2/EpX7tl1su0v28OiGZJJLWx1kFSQ/p0lu9TMmtUmitnm2vZp0yByzJ2LWx95zH+YoVpbuf6gTEhxp/twvtP9JRLysMaJvYaK9H9vc4qSibRob0tN5fV1IKzqOE5kEx7vtPiYARmF4wAkll9T0iwKFJLHRFDy3RbtkUMG+3fsg3dP6EctpOP7nM0UhG+3pPpD2VD7wgp8jEAnpGqExw0la6aOxXcuCkUEBkKK1skKhNqrltr84myDA765NDdgUw+a1w4WIh3LCd592eJWPVEEVa0eBimiiTKbJKf23dovkQllbyStJiBfnqkT+lLVj/uI5ae2A8KAaAUkxFs0UZvv+9z8gM4DI9ktbr3/WLXdudjc+rcQDVGiTkwC2enf X-Forefront-Antispam-Report: CIP:255.255.255.255;CTRY:;LANG:en;SCL:1;SRV:;IPV:NLI;SFV:NSPM;H:LV2PR12MB5869.namprd12.prod.outlook.com;PTR:;CAT:NONE;SFS:(13230031)(346002)(366004)(376002)(136003)(39860400002)(396003)(230922051799003)(451199024)(1800799009)(186009)(316002)(86362001)(8676002)(8936002)(6636002)(4326008)(66556008)(41300700001)(66476007)(66946007)(5660300002)(6862004)(37006003)(83380400001)(38100700002)(478600001)(6506007)(2906002)(2616005)(6512007)(26005)(1076003)(6486002)(36756003)(33656002)(473944003);DIR:OUT;SFP:1101; X-MS-Exchange-AntiSpam-MessageData-ChunkCount: 1 X-MS-Exchange-AntiSpam-MessageData-0: =?us-ascii?Q?o+ZiIwn2260ncGFdKmgEXP1cJ8pWBsER616CJFitkQ+Ry/bu+iVePg2CT0Mc?= =?us-ascii?Q?bChk0Qs0EpedfH0bUzltHy1VhPIVRXf9Uf+V2obva7Z0Q2m3cEAiapIsGwtJ?= =?us-ascii?Q?p4bv04nbHBrce0sueLW0kAZhhJ9kI3tnpV6phEBsImCiGIIBk2C7lSm0Wf2+?= =?us-ascii?Q?pXG1TAB0Gw7mqJti+GEqFBl08w6ng1lCLDhEuMf7tObbN6ZhmP6Wq4d1ZwTK?= =?us-ascii?Q?iVygkuH7RWe95WYYpg1Qdxsf+8YyxYVz6tNBvLye4fdU1lRkZz598PXV2K/P?= =?us-ascii?Q?HosxTZ+U6dVZKgNlLa4Li0T+3wLFOvSdCutcNwGMe38fJAMk0bNyt5egH28l?= =?us-ascii?Q?fnrfBQ5lvVqDDtrI3v7NzFwBsSa3ZpMSQBqax/FtoDwiqgxAib0tp56krmXV?= =?us-ascii?Q?t9ELxlxZsfVrP9hR0q7j6UfQdSfSodssOFHXEcsWGuI5F2WqeFM6hGawZz1V?= =?us-ascii?Q?uqzII9hKy2fEfiy13GcElxaEsCeaYMAI02DJE7prwYM5dZBzMfFbzRe9Xkac?= =?us-ascii?Q?w7DIOjP1T4km89aYZTxQm5BIbEl4NHyjK5VBTs92oSWTq0Bf1Hd0A30vxvzX?= =?us-ascii?Q?rsRizLmGU755w+oVWP4qhffjMrIHlbJvCTneTdgoF8xdbv8sMAWEM1rQTa2u?= =?us-ascii?Q?IbGKQGNuH8LrjsvXM9wBZ/vEuTUsQkmkTYMb1EPX5gOWZu0VkFQWHPQGXJ4d?= =?us-ascii?Q?ydV6tdKlJ7KUoqicJhkYkFdK1PwuIW/6lekbx1x+ZkmTEQ9RF5MAi0bl9bXl?= =?us-ascii?Q?nNkDLlu5CeROJ8sMPI+1VnNX1GnCLcQrUBACwzYymiKc34YMsGx7rwsb7Obd?= =?us-ascii?Q?Zg470r6RTP2OnikoqnsWdvOBvLmMUGGzGlJIgFfl9czLsqfWcRWTqHV0vEeM?= =?us-ascii?Q?zkbI4SfFqdfpVbHXAO9jZf3D9N3rOEfQiQ/IRqveAoqna4A2WbwMt8A55F+3?= =?us-ascii?Q?jEPUnkcwuCEV/LInKBl4tBYjM1W2vAswSwHCt8vJGlyc0svnem5nGZmWPqOo?= =?us-ascii?Q?mcLQrdYHNpwJ8u43bFy4EWYAhBZyIyO75xWqH9A5N+56DmwysyRAQ59Q0LgP?= =?us-ascii?Q?9GUx8MiqM3kjnxt9DvWO0uL85/+ytzoG8JTgHw6aWJViSh0xEo141d4g3icj?= =?us-ascii?Q?ohQKRS3UxH79uue+S8PUgCIxDIUp4lD0ah4LEzG/h5Xkaf2KLP651dK9CTAS?= =?us-ascii?Q?47BZjqrAZMdfSxSxE/+MRGv8gHgvH74cYpXIKDixhv+m/W7N2hXNKUGudrnA?= =?us-ascii?Q?Awiu0jUP3TTt+Ur7LI3XTa0mZQc58m4I7bFE7g4SZgwYWW2S/DBJkioIghVG?= =?us-ascii?Q?ComeRc8OV1i0gaazRh+cdHir+5ZvbccXPBKAhLDiUe06+zbD+DarMMO0V+ns?= =?us-ascii?Q?mSwb159VXMdEHLL6OYirjWHW5AoRlSNGM27Wx6P/bqPSRN68uNIJEzV4Gsa8?= =?us-ascii?Q?yImSawOa8J+wyrWCb8gJQkM51s2R912yzGwelfgq1HgJFAp+DXKAZZb3UvjT?= =?us-ascii?Q?fF4JVfxgVDTEmZhZzTTmpv5VztK4D46GHr+ipMVlMzW78PgX/4vO+7TP6jvT?= =?us-ascii?Q?x6E+LDXf9nB78P1+7UnofWFKsB9lLsnpb47GSj5I?= X-OriginatorOrg: Nvidia.com X-MS-Exchange-CrossTenant-Network-Message-Id: 45782ecf-a96a-4a3e-0182-08dbbdf62ebf X-MS-Exchange-CrossTenant-AuthSource: LV2PR12MB5869.namprd12.prod.outlook.com X-MS-Exchange-CrossTenant-AuthAs: Internal X-MS-Exchange-CrossTenant-OriginalArrivalTime: 25 Sep 2023 18:35:24.8344 (UTC) X-MS-Exchange-CrossTenant-FromEntityHeader: Hosted X-MS-Exchange-CrossTenant-Id: 43083d15-7273-40c1-b7db-39efd9ccc17a X-MS-Exchange-CrossTenant-MailboxType: HOSTED X-MS-Exchange-CrossTenant-UserPrincipalName: 1kvSaIau8tMJoiCLf8a342sN1/wBJFz68k9VKuoEEvH7Sk8PWVu0Jn84zYNIseA5 X-MS-Exchange-Transport-CrossTenantHeadersStamped: CY5PR12MB6599 X-CRM114-Version: 20100106-BlameMichelson ( TRE 0.8.0 (BSD) ) MR-646709E3 X-CRM114-CacheID: sfid-20230925_113531_677126_BF031DBC X-CRM114-Status: GOOD ( 31.40 ) 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 Wed, Sep 20, 2023 at 01:52:04PM -0700, Nicolin Chen wrote: > > +static void arm_smmu_ste_stage2_translate(struct arm_smmu_master *master, > + u64 *ste) > +{ > + struct arm_smmu_domain *smmu_domain = master->domain; > + struct arm_smmu_device *smmu = master->smmu; > + struct arm_smmu_s2_cfg *s2_cfg; > + > + switch (smmu_domain->stage) { > + case ARM_SMMU_DOMAIN_NESTED: > + case ARM_SMMU_DOMAIN_S2: > + s2_cfg = &smmu_domain->s2_cfg; > + break; > + default: > + WARN_ON(1); > + return; > + } > + > + ste[0] |= FIELD_PREP(STRTAB_STE_0_CFG, STRTAB_STE_0_CFG_S2_TRANS); > + > + if (smmu->features & ARM_SMMU_FEAT_STALLS && !master->stall_enabled) > + ste[1] |= STRTAB_STE_1_S1STALLD; > + > + if (master->ats_enabled) > + ste[1] |= FIELD_PREP(STRTAB_STE_1_EATS, STRTAB_STE_1_EATS_TRANS); These master bits probably belong in their own function 'setup ste for master' The s1 and s2 cases are duplicating these things. > + > + ste[2] |= FIELD_PREP(STRTAB_STE_2_S2VMID, s2_cfg->vmid) | > + FIELD_PREP(STRTAB_STE_2_VTCR, s2_cfg->vtcr) | > +#ifdef __BIG_ENDIAN > + STRTAB_STE_2_S2ENDI | > +#endif > + STRTAB_STE_2_S2PTW | STRTAB_STE_2_S2AA64 | STRTAB_STE_2_S2R; > + > + ste[3] |= s2_cfg->vttbr & STRTAB_STE_3_S2TTB_MASK; > +} > + > +static void arm_smmu_ste_stage1_translate(struct arm_smmu_master *master, > + u64 *ste) > +{ Lets stop calling the cdtable 'stage 1' please, it is confusing. arm_smmu_ste_cdtable() > + struct arm_smmu_ctx_desc_cfg *cd_table = &master->cd_table; > + struct arm_smmu_device *smmu = master->smmu; > + __le64 *cdptr = arm_smmu_get_cd_ptr(master, 0); > + > + WARN_ON_ONCE(!cdptr); > + > + ste[0] |= (cd_table->cdtab_dma & STRTAB_STE_0_S1CTXPTR_MASK) | > + FIELD_PREP(STRTAB_STE_0_CFG, STRTAB_STE_0_CFG_S1_TRANS) | > + FIELD_PREP(STRTAB_STE_0_S1CDMAX, cd_table->s1cdmax) | > + FIELD_PREP(STRTAB_STE_0_S1FMT, cd_table->s1fmt); > + > + if (FIELD_GET(CTXDESC_CD_0_ASID, le64_to_cpu(cdptr[0]))) Reading the CD like that seems like a hacky way to detect that the RID domain is bypass, just do it directly: if (master->domain->stage == ARM_SMMU_DOMAIN_BYPASS) ste[1] |= FIELD_PREP(STRTAB_STE_1_S1DSS, STRTAB_STE_1_S1DSS_BYPASS); else ste[1] |= FIELD_PREP(STRTAB_STE_1_S1DSS, STRTAB_STE_1_S1DSS_SSID0); > + ste[1] |= FIELD_PREP(STRTAB_STE_1_SHCFG, STRTAB_STE_1_SHCFG_INCOMING) | > + FIELD_PREP(STRTAB_STE_1_S1CIR, STRTAB_STE_1_S1C_CACHE_WBRA) | > + FIELD_PREP(STRTAB_STE_1_S1COR, STRTAB_STE_1_S1C_CACHE_WBRA) | > + FIELD_PREP(STRTAB_STE_1_S1CSH, ARM_SMMU_SH_ISH); > + > + if (smmu->features & ARM_SMMU_FEAT_E2H) > + ste[1] |= FIELD_PREP(STRTAB_STE_1_STRW, STRTAB_STE_1_STRW_EL2); > + else > + ste[1] |= FIELD_PREP(STRTAB_STE_1_STRW, STRTAB_STE_1_STRW_NSEL1); > + > + if (smmu->features & ARM_SMMU_FEAT_STALLS && !master->stall_enabled) > + ste[1] |= STRTAB_STE_1_S1STALLD; > + > + if (master->ats_enabled) > + ste[1] |= FIELD_PREP(STRTAB_STE_1_EATS, STRTAB_STE_1_EATS_TRANS); > + > + if (master->domain->stage == ARM_SMMU_DOMAIN_NESTED) > + arm_smmu_ste_stage2_translate(master, ste); I think this needs a comment /* * SMMUv3 does not support using a S2 domain and a CD table for anything * other than nesting where the S2 is the translation for the CD * table, and all associated S1s. */ > + if (le64_to_cpu(dst[0]) & STRTAB_STE_0_V) { > + switch (FIELD_GET(STRTAB_STE_0_CFG, le64_to_cpu(dst[0]))) { > case STRTAB_STE_0_CFG_BYPASS: > break; > case STRTAB_STE_0_CFG_S1_TRANS: This thing could go into a function 'ste_is_live' too > + ste[0] = STRTAB_STE_0_V; > > + if (master->cd_table.cdtab && master->domain) { I think the weirdness in arm_smmu_detach_dev() causes trouble here? Despite the name the function is some sort of preperation to attach_dev. So if we change attachments while a cdtab is active we should not remove the cdtab. Basically, no master->domain check.. IMHO, I still don't like how this is structured. We have arm_smmu_detach_dev() which really just wants to invalidate the STE. Now that you shifted some of the logic to functions this might be better overall: static void arm_smmu_store_ste(struct arm_smmu_master *master, __le64 *dst, u64 *src) { bool ste_sync_all = false; for (i = 1; i < 4; i++) { if (dst[i] == cpu_to_le64(ste[i])) continue; dst[i] = cpu_to_le64(ste[i]); ste_sync_all = true; } if (ste_sync_all) arm_smmu_sync_ste_for_sid(smmu, sid); /* See comment in arm_smmu_write_ctx_desc() */ WRITE_ONCE(dst[0], cpu_to_le64(ste[0])); arm_smmu_sync_ste_for_sid(smmu, sid); } static void arm_smmu_clear_strtab_ent(struct arm_smmu_master *master, __le64 *dst) { u64 ste[4] = {}; ste[0] = STRTAB_STE_0_V; if (disable_bypass) arm_smmu_ste_abort(ste); else arm_smmu_ste_bypass(ste); arm_smmu_store_ste(master, dst, &ste); } And use clear_strtab_ent from detach ?? (but then I wonder why not set V=0 instead of STE.Config = abort?) > + arm_smmu_ste_stage1_translate(master, ste); > + } else if (master->domain && > + master->domain->stage == ARM_SMMU_DOMAIN_S2) { > BUG_ON(ste_live); > + arm_smmu_ste_stage2_translate(master, ste); This whole bit looks nicer as one if } else if (master->domain) { if (master->domain->stage == ARM_SMMU_DOMAIN_S2) arm_smmu_ste_stage2_translate(master, ste); else if (master->domain->domain.type == IOMMU_DOMAIN_IDENTITY) arm_smmu_ste_bypass(ste); else BUG_ON() } else { // Ugh, removing this case requires more work } (Linus will not like the bug_on's btw, the function really should fail) > + for (i = 1; i < 4; i++) { > + if (dst[i] == cpu_to_le64(ste[i])) > + continue; > + dst[i] = cpu_to_le64(ste[i]); > + ste_sync_all = true; > + } This isn't going to work if the transition is from a fully valid STE to an invalid one, it will corrupt the still in-use bytes. Though current code does this: dst[0] = cpu_to_le64(val); dst[1] = cpu_to_le64(FIELD_PREP(STRTAB_STE_1_SHCFG, STRTAB_STE_1_SHCFG_INCOMING)); dst[2] = 0; /* Nuke the VMID */ Which I don't really understand either? Why is it OK to wipe the VMID out of order with the STE.Config change? Be sure to read the part of the SMMU spec talking about how to update these things, 3.21.3.1 Configuration structure update procedure and nearby. Regardless there are clearly two orders in the existing code Write 0,1,2,flush (translation -> bypass/fault) Write 3,2,1,flush,0,flush (bypass/fault -> translation) You still have to preserve both behaviors. (interestingly neither seem to follow the guidance of the ARM manual, so huh) Still, I think this should be able to become more robust in general.. You have a current and target STE and you just need to figure out what order to write the bits and if a V=0 transition is needed. The bigger question is does this have to be more generic to handle S1DSS which is it's original design goal? Jason _______________________________________________ linux-arm-kernel mailing list linux-arm-kernel@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-arm-kernel