From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mail-qk1-f178.google.com (mail-qk1-f178.google.com [209.85.222.178]) (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 6ED023DDDCF for ; Fri, 24 Apr 2026 15:42:59 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=209.85.222.178 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1777045382; cv=none; b=MWkiIG/XbKkNoyIYOW+1TVVuBJUROSwvrUSrBxxX7gBznQyjDsnyrQWxkYZfNdL7odhuetqhTw0rfGXB7WinIfVxPO97pErdAjAl9QpDsGd4kQdpWcjr2cOjQ+j5ersQ6J7eFt3ODYwFmkCLh2XDpaAbYCqV+FrYOM7zwXXpI1o= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1777045382; c=relaxed/simple; bh=1b2hJGuGyhOo3qIRp/Yl/Ae+G7xajvKnsKglp+k6kgQ=; h=Date:From:To:Cc:Subject:Message-ID:References:MIME-Version: Content-Type:Content-Disposition:In-Reply-To; b=bGbv3SvGlXLN0+qJTMBWSdubGXnNnmLIeh7oi4O7jzWz+OIrMPmP5as7bCz0JoAabz3vsrTZ7A1mYJzIWsbLh1VNrTu90JKN1+EdzLpPTYbEdz8yKk2NuAoRCx68B1chGS6JtEswaNcPe9Azbm5D9I7aDmtX58ozDe68PLNoTvo= 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=G08EpPNN; arc=none smtp.client-ip=209.85.222.178 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="G08EpPNN" Received: by mail-qk1-f178.google.com with SMTP id af79cd13be357-8dbbc6c16b2so997536885a.0 for ; Fri, 24 Apr 2026 08:42:58 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ziepe.ca; s=google; t=1777045377; x=1777650177; 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=/x75TqXNcWuPRjyy/KdKbQT3qJql0Oi7XAZXrmCpBRk=; b=G08EpPNNsAnaNK61cmupiB+/48rwa0tof00oTz4Q2nnhg4BlSRhA2uGsLolZ862ooF oruRk5o5wAAoWVk/aEdFx6TGhAM9AzRp4XOj/xdKW4uMRFenqajJslNZJEXE0iYg/e2r 2aVo1YTO0DGlEiNE5N5CouyACE3JAaYpey3U18G7z0xGH2s8O/UzEKXOFO21C20oDvIn CkVpqqRfqTnHhzN/kDVJlv9N7PEfVhO1+6lCLDhY0K8Cmf76t4G3nj2TbKmxzlLXlazl KmQ9JU+zhMT2KxzqLWDWmhWb0gxEmcSXdSGgOPWOkKVjMEUIlBMWWUXwLRV9F0b43v/I odqw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20251104; t=1777045377; x=1777650177; 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=/x75TqXNcWuPRjyy/KdKbQT3qJql0Oi7XAZXrmCpBRk=; b=qXlVAu576lLaad/ehvL3nLcr/IJBm+FW+iE88DVKOGleW07/42VOJwbEr80/MrqGeo xktgrI4ppv317Za1Fomv/NzYpkN4mVaXtIKAGwoLWoE2iOGgGEhyyt4CXDOQhZ+3iKof n2tf9u7w4qjN47SYYKptQM86gIR0v46JpEqI2LgW1sWn1ElHdQM3Pre+eM9U2WiIqB8R CIasgWB6fZ2ABPM3L+2Mpa8u2+ec6T7DVuO/j5QNxeuqV818J40fMdijV9etGoBD/AZy pMNYiVylMBSJ/FE2DVxNn+QZnAZufXnRNVXzcU5DNdMqq0vJLny76z0BeWHUosKdi5l0 4d5g== X-Forwarded-Encrypted: i=1; AFNElJ9LF82EXZh0LfhFNEVo0qqG1njnXj7WDjj3E236IJmKWm7i1gCDn4Hel3PDn5WLJKFTLR7mwiFd7m6C1Xc=@vger.kernel.org X-Gm-Message-State: AOJu0YzcANlw336RPsIomH8kDTjSJUxmi6QodsgKGTn6PxqBLTbribK0 De6hL8FtBT9Gh4UrPo+720fGywK0gsVOM12VUg8iZzFr9uWoLqpUvj7cki+1TYBwOhY= X-Gm-Gg: AeBDietJEX9WHAr0AZDneUosdydODH6U9rUpJGU5UtCtFiwo6hwc/I443ss5ckFUNr7 E2zk5SuMfssAWYv/jdIpaBM9PMm1ZTkS8Ao2MSRcue5bWjS7s2DDOreWQaTcBQJfdMwF+P6KvaQ fi7Mds7OpnJpM7rq0mjoH32QNMgWJzU3vhwl4JKntizDlHAR1MkcjRXCoJ6+HskboNHolvtEJvT Zcvl1N0bNKJbhMy8OLHxFiJca9NwYlOfbT2JcfAAip9cyrS00rpiplZmkSKVFRruGVnWnbwCGi3 LsgoKPoFJK4T0YE9/lhlm3x2h8/W8BaMiITwVACIW68FII8yUd3Iuax2dFDsDpZcYuhtXWL4YRP lD0MGl5z+DZl0DK4otBANYJRS3jJkMNJFlL2PZUuOHkXa/+Dnm3rTLgSl1nuZumvYc1C4BuG/zK S48ig223h+b/hHU5vQiSf1WszTxYclsrcS19+Q9qVmoJ87LnmOToEx7gVCbZZe32jqtloo6N0Wu AIlVSsrWE781ME1 X-Received: by 2002:a05:620a:31a5:b0:8d7:c82f:ff7b with SMTP id af79cd13be357-8e78cab251cmr3765152685a.35.1777045377193; Fri, 24 Apr 2026 08:42:57 -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-8b02ae7fef0sm181782366d6.38.2026.04.24.08.42.56 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Fri, 24 Apr 2026 08:42:56 -0700 (PDT) Received: from jgg by wakko with local (Exim 4.97) (envelope-from ) id 1wGIgC-000000035kk-0Ekr; Fri, 24 Apr 2026 12:42:56 -0300 Date: Fri, 24 Apr 2026 12:42:56 -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: <20260424154256.GF3611611@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> <20260423223716.GS3611611@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 Fri, Apr 24, 2026 at 04:16:17PM +0100, Will Deacon wrote: > > > > 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 :) > > You trimmed the part from my reply where I think we _do_ have an issue > with the PTW. Here it is again: > > The non-coherent case looks more fragile, because I don't _think_ the > architecture provides any ordering or atomicity guarantees about cache > cleaning to the PoC. Presumably, the correct sequence would be to write > the PTE with the valid bit clear, do the CMO (with completion barrier), > *then* write the bottom byte with the valid bit set and do another CMO. I wasn't sure if you are being serious. CMO + barriers must provide an ordering guarentee about cache cleaning to POC otherwise the entire Linux DMA API is broken. dma_sync must order with following device DMA. IMHO that's not negotiable for Linux. All ARM iommus rely on 64 bit atomic non tearing. No bugs reported? Any fix to that is going to have major performance downsides.. I also strongly suspect it is provided on real HW. It would be hard to even build HW where <= 64 bit quanta can tear. Maybe this is something ARM should take a look at. At the very least it would warrant an IORT flag for safe HW to use to opt into the faster cachable flow. > > 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. > > I was against that read-back, iirc :) Yes, but it is OK :) > > And if Samiullah can tackle dma_alloc_coherent then maybe the whole > > question is moot. > > Yes, that would be great, but we probably need to fix the page-table > code too. You really want to deal with the likely perf regressions that would cause on Android/etc? Jason