From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mail-qv1-f52.google.com (mail-qv1-f52.google.com [209.85.219.52]) (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 586163D3330 for ; Tue, 20 Jan 2026 13:11:53 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=209.85.219.52 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1768914715; cv=none; b=X9r6rRj9aphR79ozX7iWSTZOG88NM2W89Mv/BBMNg57yXa052B/x3Mn2SZSeIhJ4SAlrygRbh7TYuVtMxUYY0YPaIczxmde8qRaMRIrdIHXA1GVsNBJRAnQXQIvEL1XSnXGMstJVG8DyA11moIkTISF5opGCZ2Vxc9vW3g3GlME= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1768914715; c=relaxed/simple; bh=oWxRqXkSIAdlpRXurKw8PqWkt7+sbNg3g3rpNYKoLZc=; h=Date:From:To:Cc:Subject:Message-ID:References:MIME-Version: Content-Type:Content-Disposition:In-Reply-To; b=iN2bwvfW94PnleYGnQqF+ygKhfmbyx3QsdtcFoZbKUT3XsToWDaoy1uWmynYfWtaUWApIFzk6n2EkY4pSWn1/i4JaacoBTmyLyqH4geNLi1is/a6Doy7bwTNSGN1KBc1aLKSZ+MeCiTJgszrRLoyYumBtbQxuAqWypz622VJPCM= 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=MUSNSA5R; arc=none smtp.client-ip=209.85.219.52 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="MUSNSA5R" Received: by mail-qv1-f52.google.com with SMTP id 6a1803df08f44-88fca7bce90so62398616d6.3 for ; Tue, 20 Jan 2026 05:11:53 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ziepe.ca; s=google; t=1768914712; x=1769519512; 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=AFD8dduxHdXARbhmuw3nGz+HS5/qU93piZU3w6MAoZk=; b=MUSNSA5RUbC88BDrCXhLaUUsBlajOLVElMVHGXO4nqlWoSEAUrFdDQHF4AUdz2QlGv IaHtT8OAuIO11l9UasTtiyO2vkiDOtiPfhWM72lEGzX8i11o2GVpTO2FfR/eVi/EZrHM mW1iJaFlCMjeVCeOFcMn6uy93emB8h8ckI0iYMHUMaPzNhmK/KWKdvGJ8IB3Rs+9JQ2n bfE+auGVh2LHZTA0QXX7IKARGuwLZSMZqa+XQarK28J3w78+YuYMmcYtY2uFDypLpVzG mi5RtTIZcymL/NFfBfDEFHJdOf1tndHVBRoqXKfSer5cJL+W00ArCyIxXx7A5pusw/3C +DHQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1768914712; x=1769519512; 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=AFD8dduxHdXARbhmuw3nGz+HS5/qU93piZU3w6MAoZk=; b=b39sv/+zrI7BeUU3Jrk6NpBg6jK1ol992cfkZAeLb1gH19QmwsZjfJBHMKy/T2y31y xL46BPb7KAae4z4LJ+SkMg44e8Lux75ndzZw89pWCwCPz000HYcfAlewZE3ainYYbqJt 3znp/2TWf5L2FN7IUpPtlLn9MduWK/hdeX6gmkNyataU/JPmwo4O7J79f9RGF7PqpWY4 L85JftMczBJe6zrk2UTXf7F299CdR+w4TYMRqPAX3Tyd4gTxGAusR++IYagHHu/+ooZr j5G9A/mnYkNZ0ZKLmzZv3WQ5eB/5hyGx6FChNsACBz1ABOGJ8dPwGJjjEE9uz7NviD7i OXOA== X-Forwarded-Encrypted: i=1; AJvYcCUsojA8BB7TVtUOnwvrqQMr1oeEnRQJ//lOUJfMoC9JgfVtYogubytzHzNkH+gB0DEg2jz4sOjHZVHRXgM=@vger.kernel.org X-Gm-Message-State: AOJu0YxT77KD2LF/XaKbsfWWIZhc1bK4mW99w3RRtdzXmQ+144YGYnuv 6S9tg5GEdXTIPcWyfsd5Ip4O6sdNxhMzP5HHT3yENE2QePBKRf8aIa7P05XdkHtb7kI= X-Gm-Gg: AZuq6aJO0pKqnpZUs/cYyEDaeU7YgXdjXkf+yuYDgGtlQYOjbsow+1o4GbfbQ+tweN7 Oj55nXrVfYADYBWsnsBasmWhgmuLoJVc9fII7y4jJPmxDbjzrPCkOgw5fHIX51cTDpyqsyy5Qo5 IvjdGMKk5H3ciPvpUlbTw4txn1LndPmku//imdnm+3xzgXyXhKVODQaavZToKt2PzPls+27xR3x TwQ6eCZ93y5YyRBiXwhPJsgHsOf7zdldxxZmZEvnVsA4tS82Nzl3Wtl3hgFV6Te29be9h6Gqk63 N1WeyRq3taoqoWhaEp43vdpszOv43cwfqTSQIdnebmxeDsz3v5iu/gs2WNVHPIQR7ney0a9sOXs dOu8g+WBAQal66IvHfrr7gsiP0ut7eEuSNE6AgKvDk8s6lEvqWo+jdVNq3wdOWzILQk6DNvItY7 x0v9oV+rOL6/6vsVbcDai2iBRYoqxibrBCqZbnXnU5Kr55ghiycYX5TC1ouSAlJLuDsAA= X-Received: by 2002:a05:6214:21e2:b0:78d:be82:fffa with SMTP id 6a1803df08f44-89463e12ecbmr22544176d6.33.1768914711953; Tue, 20 Jan 2026 05:11:51 -0800 (PST) Received: from ziepe.ca (hlfxns017vw-142-162-112-119.dhcp-dynamic.fibreop.ns.bellaliant.net. [142.162.112.119]) by smtp.gmail.com with ESMTPSA id 6a1803df08f44-8942e5e5307sm104190186d6.9.2026.01.20.05.11.51 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Tue, 20 Jan 2026 05:11:51 -0800 (PST) Received: from jgg by wakko with local (Exim 4.97) (envelope-from ) id 1viBWQ-00000005W5W-3jR2; Tue, 20 Jan 2026 09:11:50 -0400 Date: Tue, 20 Jan 2026 09:11:50 -0400 From: Jason Gunthorpe To: Will Deacon Cc: Robin Murphy , Dawei Li , joro@8bytes.org, linux-arm-kernel@lists.infradead.org, iommu@lists.linux.dev, linux-kernel@vger.kernel.org, set_pte_at@outlook.com, stable@vger.kernel.org Subject: Re: [PATCH] iommu/arm-smmu-v3: Maintain valid access attributes for non-coherent SMMU Message-ID: <20260120131150.GM961572@ziepe.ca> References: <20251229002354.162872-1-dawei.li@linux.dev> <20260105145321.GD125261@ziepe.ca> <20260105185423.GI125261@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 Tue, Jan 20, 2026 at 12:14:43PM +0000, Will Deacon wrote: > I'm not against being more careful about the memory attributes used by > the non-coherent walker, but we shouldn't fool ourselves into thinking > that Linux can treat coherent devices as non-coherent and expect things > to work generally. Probably not generally, but we will need much more flexible coherent/non-coherent choices for some upcoming HW that cannot support cachable access for certain isochronous DMA flows. The device driver will know this, and it will know the underlying HW works properly, so it can safely opt in without worrying about "generally". PCIe defined no-snoop TLPs a long time ago for these isochronous cases and we haven't done a great job supporting this feature in Linux so far. > The use of non-cacheable mappings in > dma_alloc_coherent() and cache invalidation in the streaming API when > transferring buffer ownership back to the CPU can both lead to DMA > corruption if the device can snoop the CPU caches. That's a bit different situation, here we are talking about the SMMU itself and things like the page table walker are fine if the HW does cachable or non-cachable because we can flush the caches and the HW never writes. The same argument works for the stream table and CD tables, but they'd have to switch away from dma_alloc_coherent(). Certainly the end device driver doing DMA can't get off so easy, but it is also not so unreasonable to think that the driver should know that the SOC block it is driving has an appropriate HW implementation for no-snoop. > I think we're all agreed on that, but just wanted to make sure as this > is something that has come up before when talking to hardware folks > who seem to think that the "dma-coherent" property is a hint. What I've been pushing for is that the SMMU architected cache properties have to be followed. If the architecture says the transaction must be cachable then the HW must actually cache snoop it. However, this goes the other way too and if the architecture says the transaction should be uncached the HW can bypass the cache. Hence my interest in this series because HW that follows the architected cache properties is going to be sad if Linux doesn't set them right. If the HW actually implements the cache properties then the SW needs to select cached/non-cached on a (sub)stream basis to support isochronous flows. If the SW doesn't do this and just selects the deafult cachable then the DMAs will work and transfer the right data, but the realtime guarantees will fail and other parts of the system will have errors. Jason