From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mail-qt1-f175.google.com (mail-qt1-f175.google.com [209.85.160.175]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id CAF47346E72 for ; Thu, 23 Apr 2026 22:37:18 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=209.85.160.175 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1776983840; cv=none; b=iZkRF+poNYy/LQ45tHiN3xaTLWY7ucjhp2TmUpanmGQGzrN/k0/xzqvvIsaX2XGVOzpOvaNpTuLKIKTpjE/jWkj3SWbCSKsR82BArkDqhxLA5KwwpmjxseTvTySRQ6vmUdjlwuAqorLJ2/hv4QFRl9fNVGzsrGtB9T5Yaqg9nLE= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1776983840; c=relaxed/simple; bh=jz6d2Rk2R9fNPwkMSiv35sDmoM0WBb2VdkFyl4+3Wzg=; h=Date:From:To:Cc:Subject:Message-ID:References:MIME-Version: Content-Type:Content-Disposition:In-Reply-To; b=r2Q+UXFKfooY5lPQaOlalZ5GdUfxS1vjsvVRO1IVbxPZRfSodACLstYJN/0odfojQn14qUZeLRwgXIPTyjXmdZH8hEXkSbk+8K8s7Q5YbMG0hjBqxIhqNxBDvxjKioyabyPe+n2RcuS5KMET5CZu8QMZFQ1k7DyzLXpfQMl+3Oo= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dmarc=none (p=none dis=none) header.from=ziepe.ca; spf=pass smtp.mailfrom=ziepe.ca; dkim=pass (2048-bit key) header.d=ziepe.ca header.i=@ziepe.ca header.b=mClKUHfz; arc=none smtp.client-ip=209.85.160.175 Authentication-Results: smtp.subspace.kernel.org; dmarc=none (p=none dis=none) header.from=ziepe.ca Authentication-Results: smtp.subspace.kernel.org; spf=pass smtp.mailfrom=ziepe.ca Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=ziepe.ca header.i=@ziepe.ca header.b="mClKUHfz" Received: by mail-qt1-f175.google.com with SMTP id d75a77b69052e-50fb18c55beso38082181cf.2 for ; Thu, 23 Apr 2026 15:37:18 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ziepe.ca; s=google; t=1776983837; x=1777588637; darn=vger.kernel.org; h=in-reply-to:content-disposition:mime-version:references:message-id :subject:cc:to:from:date:from:to:cc:subject:date:message-id:reply-to; bh=Os93XZ5HK9zO/mWUsxanxIiJC+1bt4BZQrH2i+zDIdk=; b=mClKUHfzIZsurD2b7CLGLbU6hYbxSY0m/zqkYf/EAHT3g8aKQBJ3C6gCQxJCQee87X vMouNHBEXZ+FynD9lKVj0uFJv+hr2Rap8FjSQEY65d7UeQr8dCdvZz1xYNCJe2jetwUn 9b8i1jk2qrc5LuNSJ53zptUXACOD2WxnsVG69SIMJ4MDV+mUe4+Xz4tSpYp+pUMZ+r9J dzZUrtOCKpM7F9TkoGoQXGHBM4cg9BOa5EekhTZ/T6R27KKSzvgCndCvFLliPdtj9rOT zGlL2S3ctUlEVcyWwX22mdQRwfF5jLvDVAmBQCk+vgMGJ3UTgHbDASEMBNYn8sXLmwUV lh2g== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20251104; t=1776983837; x=1777588637; h=in-reply-to:content-disposition:mime-version:references:message-id :subject:cc:to:from:date:x-gm-gg:x-gm-message-state:from:to:cc :subject:date:message-id:reply-to; bh=Os93XZ5HK9zO/mWUsxanxIiJC+1bt4BZQrH2i+zDIdk=; b=ntUjtRPfUencriz74jyZlCNsVRUYmx0/vsWS/bLvtTiakMvhC1sqIW93IkpjAf7HCT pSI/lQlBROVvevevbuCofIam56Y7jm2qUcREoyrqjG+87OY0BRh3bWRyZHPFd51NpwrJ vAAJS1WyX3GT1oEyo/MJBVg2QF3N+TZRmZac6BSTqdb9fPGquYjdWUs5MZrQ3bDVpUTF r5dwVE4n96Ug1mqHy/lZ27jmTYd/xyf4ZRuFSq7KCHo7W+xdWEfUJVD5XOUssZCPHLRX HEiyW1KWYJgDx3V2cO3wP7UBuWvQV8VWhKM4iNt2+Ky3v2Mz7pGilZbXRPc/EM+EfsQY e2NQ== X-Forwarded-Encrypted: i=1; AFNElJ/ZI/vna6c/qURv0bhUceVWxlqfiX6k2s1RMGcftlILQxj64e8gRowVLXxi8y0tfNBd3/ddBsLhAqDGETY=@vger.kernel.org X-Gm-Message-State: AOJu0Yxm0W5CPAcVjekNZP1Dbu7S6jSwCGOCOvdb+56xGy6+tsZAOf5H hnD754Ldt85h6xvgzN2dUnGUifDU9EedGMv3DHGtU4olTFt1rRNYS79WjRmz51Hk1M4= X-Gm-Gg: AeBDietn+XTeVQc5Gq6KUEnv0d0GZJLFnvUKKIz3OEumlVv/+5RUZVdIPyB/yUsfxhC GRkDZLbBdpJ+ZGJe/jpMVNwrgzc+c9JgC+WA5CYrftozVLHQ6LQjzeBaggxqdX8asHrJE9DMmtx 5KVuDH3SEwwABF+FVx3LpCVwlUEYuXYtxHoLensjhjf/FrBmBCMCvd2yiKpFjS4MLTahSsHqUUQ JYHPIVhRfunHWzNxOmntXThNnkXKEb/mEpuln9F51bfnFBxGWGlxKyOmEXDvrUFHdW1RqQL+4em ET8O9m3hbVIY+hl/en7yd5PI5ezCUI3ICYyb8t2j8m1vUKHfjFFspvUiZ7cQujlBjznu16PuLHs 9+SSfMGr00ymYwrqDYWQmFNSFzCNdrjasjSsKElpSvfSiPlK4l9mpYr6G/Jhb3qYQRLqRk3KwDG CWc+nXKvtsm8Dj8wPLmR3TTHzJc/UIeINPGPu7efMt0UDVe5doBCLN5VXIaAzV1jkNj3CoThHjJ thuoxfJ/OOMjrINNfw98rq9t7E= X-Received: by 2002:ac8:7f90:0:b0:50d:5a11:1b5 with SMTP id d75a77b69052e-50e3694a5a4mr448735281cf.17.1776983837535; Thu, 23 Apr 2026 15:37:17 -0700 (PDT) Received: from ziepe.ca (crbknf0213w-47-54-130-67.pppoe-dynamic.high-speed.nl.bellaliant.net. [47.54.130.67]) by smtp.gmail.com with ESMTPSA id 6a1803df08f44-8b02ac72915sm172200376d6.15.2026.04.23.15.37.16 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Thu, 23 Apr 2026 15:37:16 -0700 (PDT) Received: from jgg by wakko with local (Exim 4.97) (envelope-from ) id 1wG2fc-0000000GJhm-1AI6; Thu, 23 Apr 2026 19:37:16 -0300 Date: Thu, 23 Apr 2026 19:37:16 -0300 From: Jason Gunthorpe To: Will Deacon Cc: Evangelos Petrongonas , Robin Murphy , Joerg Roedel , Nicolin Chen , Pranjal Shrivastava , Lu Baolu , linux-arm-kernel@lists.infradead.org, iommu@lists.linux.dev, linux-kernel@vger.kernel.org, nh-open-source@amazon.com, Zeev Zilberman Subject: Re: [PATCH] iommu/arm-smmu-v3: Allow disabling Stage 1 translation Message-ID: <20260423223716.GS3611611@ziepe.ca> References: <20260420123221.20801-1-epetron@amazon.de> <20260420124032.GO2577880@ziepe.ca> <20260422064431.GA49867@dev-dsk-epetron-1c-1d4d9719.eu-west-1.amazon.com> <20260422162351.GK3611611@ziepe.ca> <20260423142326.GP3611611@ziepe.ca> Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: On Thu, Apr 23, 2026 at 06:07:23PM +0100, Will Deacon wrote: > I don't think it's that odd given that the STE/CD entries are bigger > than PTEs and the SMMU permits a lot more relaxations about how they are > accessed and cached compared to the PTW. Well I'm not sure bigger really matters, but I wasn't aware there was a spec relaxation here that would make the cachable path not viable for STE but not PTW... > Having said that, the page-table code looks broken to me even in the > coherent case: > > ptep[i] = pte | paddr_to_iopte(paddr + i * sz, data); > > as the compiler can theoretically make a right mess of that. Heh, great. The iommupt stuff does better.. It does a 64 bit cmpxchg to store a table pointer and a 64 bit WRITE_ONCE to store the pte, then a CMO through the DMA API. DMA API has to guarentee the right ordering, so we only have the question below: > > STE/CD is pretty simple now, there is only one place to put the CMO > > and the ordering is all handled with that shared code. We no longer > > care about ordering beyond all the writes must be visible to HW before > > issuing the CMDQ invalidation command - which is the same environment > > as the pagetable. > > You presumably rely on 64-bit single-copy atomicity for hitless updates, > no? Yes, just like the page table does.. I hope that's not a problem or we have a issue with the PTW :) > > I also don't like this "lot of systems thing". I don't want these > > powerful capabilities locked up in some giant CSP's proprietary > > kernel. I want all the companies in the cloud market to have access > > to the same feature set. That's what open source is supposed to be > > driving toward. I have several interesting use cases for this > > functionality already. > > Sorry, the point here was definitely _not_ about keeping this out of > tree, nor was I trying to say that this stuff isn't important. But the > mobile world doesn't give a hoot about KHO and _does_ tend to care about > the impact of CMO, so we have to find a way to balance the two worlds. Yes, that make sense. My argument is that the CMO on STE/CD shouldn't bother mobile, you could even view it as an micro-optimization because we do occasionally read-back the STE/CD fields. But if you say the SMM STE/CD fetch doesn't have to follow the single copy rules and PTW does, then ok.. And if Samiullah can tackle dma_alloc_coherent then maybe the whole question is moot. Jason