From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mail-qt1-f177.google.com (mail-qt1-f177.google.com [209.85.160.177]) (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 4860B52F88 for ; Mon, 5 Jan 2026 18:54:26 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=209.85.160.177 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1767639267; cv=none; b=QUvLZwU6fYjt4Ka4DsAZp6pO7qXOlgUw6Ovj67qgkG1OHZAbxqTWgsZg58qegt+ewr3mUA0tagD7eln9QKzKjw+rX83BqVcCh05juBEa1EhUX2i9DH7Id+jpFY6b5NUXvI7GznfGrWXNOk0+moU9+YmDohh6NLhG0vG3xdVMkZU= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1767639267; c=relaxed/simple; bh=ye4WgWUCpvD2gGQR0QMsre2IOoSU2Qr1YG9uLKSAPu4=; h=Date:From:To:Cc:Subject:Message-ID:References:MIME-Version: Content-Type:Content-Disposition:In-Reply-To; b=eixLvCwz4hFUovc5mPngneAV1x623og4xSYFoEJzY32hkdmHRejqbtcairTXFyI5XBJjKLJgZbgdwx0HQUT9LykfUtio5zzFIAeCLQUVkxq6s+85HDfU5SBNh5DNVNl5CZvnL3KZDYQrYA8GdBUNXGQudLh97oCSXwlEAHUpfco= 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=lL6a0PUh; arc=none smtp.client-ip=209.85.160.177 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="lL6a0PUh" Received: by mail-qt1-f177.google.com with SMTP id d75a77b69052e-4f822b2df7aso2195081cf.2 for ; Mon, 05 Jan 2026 10:54:26 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ziepe.ca; s=google; t=1767639265; x=1768244065; 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=ffKzN1sLhhBqUNkiha1w3dy/564YXw9eASHrYEoDuBI=; b=lL6a0PUh5hFbD+jGwKhFYw+mmBcAwY9uyrnKVqBnvP2sucHLePyOzRttZJWE/wafk4 ZHm2+YzJy4BrPnPEYergxuY6nEy7xjuNwdarmAjljYTxDY59GhABCovuJt696uR/Wo45 yM9auSwFt82COCondpF8oTiRO7JvH7t+26PKozuwRj2LOQAPU+qyIT8Xpc1ThGQ+AvKX kLL884LCzAtdA3kybeuK4h6uenA4VRHqxx7oU6LcutyVujBYlu9NteAK37r/I1PwvA4D bQAmAvQn6FspMu8NtXEGeOzVOkdOqXUDfuiKQTLK7UHVHjE9w6MNlGrFARCI4q9TrMGs RggA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1767639265; x=1768244065; 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=ffKzN1sLhhBqUNkiha1w3dy/564YXw9eASHrYEoDuBI=; b=tHsBFmwbTDTNv77NmRk9lY1gd8auxcffHXWoL5UvjdyK/x/tlPbnaXFuD+5Nq/wXjd eKAJ5VvgZUNKCTqYC+3FdSnyG9zfB6/ftVJsdvIdS3NU/QxZ6vKwiD4NbG9aAbgG4stw Q5MwycSiCxcXKZyD4yp/tZcVBw8bxV+TWyh3UXfpLUh4/Wjh23I/olhlG/kUpK9LYNrw M/sBK2FaYTDl4vs6t4hio796UWBI9VJPeHG6MMtlSJlgv7DpY0l6iVDrOVRvXrIRNmvV Um+/p2veAwe5Tp1Y5f4UKdwhb+m5XwgymeT3J9NpOUNGQLN/GuQQnGNdrvU2wOu86NeU VUyg== X-Forwarded-Encrypted: i=1; AJvYcCUIzbcGwN1DKJA2AFo3/bk1+jweBYdNeMcr7sDyyiDInZ8YB9XdTIIhKdgz6RrBDEna/20H+4fnliwqOoA=@vger.kernel.org X-Gm-Message-State: AOJu0YwtwTB1ly/r4LCogbNI8xvC24SuqRv/3rhUPAZIpEUT10Nc8KAU oAhBmFo9UtZfbxnOE2c21U42rFgfe58tRna9rwwS6XP0TNttILWUiIRhwREMoMYz5wo= X-Gm-Gg: AY/fxX7xvYOMhDTOqNeNKfreqsOH8Bf4D/mDf2BlGLTNcqZIr4HjkxhCbRkoelXBYWE Dd+6JpYPunAjXzxD4/a7YAz6B+s4Nbxy4vX/nkZdnR4Nmo2ZfEugpqdyoRVsOnSzG6vgwd5DelE DjxgHnceqqjbVDiHwa8AAXEDk9qRfTWAac406zAY2WAXO8wyZqUo/itFGaiLuTIE37JaeZLGwSH ik0KujAgiRAvfouGRU8r/H338+w61a0rAz4EACJLqxKIl8/0E7QCmE93I4rSE+Q859tTaYNeZhF vy+S7YbI/OwvVIrpocL4aIZ1xv89a2uln+pnH86LiWyJF3Uk8iWKHQQ9Zy+V8ALNhnGXQpdepBV 69zyBwzHT/fze62icAGkvBtb20Q1IUUDfhv1GWR9qaLM4Lb508c95ktOlY4YzvBdVOcrtx75Se7 7Zjfq2FdeYx0GcOHkvIcFrX+hbaF1Qw7eMGPnLyBqveMUT4t3ElN43D3FWJNwIrCI17nU= X-Google-Smtp-Source: AGHT+IFPnEh+/aHLidYNOpkwlSqg6n9Ja4S07lmjAzoYGYdPvIKU/oQn/q1c0tGHGXl/b++dfA2K6Q== X-Received: by 2002:a05:622a:303:b0:4ed:af59:9df0 with SMTP id d75a77b69052e-4ffa77f5e8fmr6419151cf.40.1767639265008; Mon, 05 Jan 2026 10:54:25 -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 d75a77b69052e-4ffa71fc4bdsm3676911cf.31.2026.01.05.10.54.24 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Mon, 05 Jan 2026 10:54:24 -0800 (PST) Received: from jgg by wakko with local (Exim 4.97) (envelope-from ) id 1vcpih-00000001C7Y-21aN; Mon, 05 Jan 2026 14:54:23 -0400 Date: Mon, 5 Jan 2026 14:54:23 -0400 From: Jason Gunthorpe To: Robin Murphy Cc: Dawei Li , will@kernel.org, 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: <20260105185423.GI125261@ziepe.ca> References: <20251229002354.162872-1-dawei.li@linux.dev> <20260105145321.GD125261@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 Mon, Jan 05, 2026 at 04:02:34PM +0000, Robin Murphy wrote: > > It is reasonable that Linux will set the attributes properly based on > > what it is doing. Setting the wrong attributes and expecting the HW to > > ignore them seems like a hacky direction. > > Oh, I'm not saying that we *shouldn't* set our attributes more exactly - > this would still be needed for doing things the "right" way too - I just > want to be very clear on the reasons why. At least I know of HW where the SMMU fetches covered by COHACC: * Translation table walks. * Fetches of L1STD, STE, L1CD and CD. * Command queue, Event queue and PRI queue access. * GERROR, CMD_SYNC, Event queue and PRI queue MSIs, if supported. Have a mixture of coherency support. The SOC has multiple fabrics, one non-coherent one specifically for isochronous traffic. In HW some SMMU sub-units (like the table walk) been wired to the isochronous fabric, while others are using the normal coherent fabric. So when it comes to this statement: If either the SMMU or system cannot *fully* support IO-coherent access to SMMU structures/queues/translations, this reads as 0. The HW is "partially" IO-coherent, so COHACC is 0. It has been lucky that so far the incorrect attributes haven't caused a problem, but the next spin of this HW may have issue here. I'd like to see it fixed. > bug per se, and although it's indeed not 100% robust, the cases where it > doesn't hold are more often than not for the wrong reason. Therefore I would > say doing this purely for the sake of working around bad firmware - and > especially errata - is just as hacky if not more so. Yeah, maybe, I am also curious what is motivating Dawei to do this work.. > the DMA API aspect I mean is that in > general we need some sort of DMA_ATTR_NO_SNOOP when mapping/allocating such > isochronous buffers/pagetables etc., to make the DMA layer still do the > cache maintenance/non-cacheable remaps despite dev_is_dma_coherent() being > true. I have a feeling this missing support underlies some of the reasons why FW might lie and set COHACC=0 as it resolves "how does the GPU driver cache flush things" with no effort.. Jason