From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mail-qk1-f177.google.com (mail-qk1-f177.google.com [209.85.222.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 60E902C08DC for ; Mon, 5 Jan 2026 14:53:24 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=209.85.222.177 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1767624806; cv=none; b=alVEcMIotXISJW64B1RP+RXI8xVmeZBJ4sstkF8yiAczhfMAPZ6dGOtzSdKckaLVhO5NeahroTd+T+yG73WPCHfZMe0/oZrYI2+abPKJNtpI4J1viYQZ3tNec4qkiFvgYpJBpG6pt8KVH/RN1VzS7NkVL2G/fly3r9+KzHCJQSw= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1767624806; c=relaxed/simple; bh=0VJAy1LxeO1DoMMmQqr6qf7GwbBJdW99Z0xb4rwj9wE=; h=Date:From:To:Cc:Subject:Message-ID:References:MIME-Version: Content-Type:Content-Disposition:In-Reply-To; b=F7FlUSOpMeiZaF0MyDO8vFxksKS5r4AsqfyjN9LaSGiSkyRqtuHzu7/ldr6iQCAcWafF3WPZr2omKce5Nxv5E1zIyYbtii40ZO5uvbLq9k4af05Usjg1JdZUmR0z2uBtBHqqgqMsInlnb7+TvPJtuAFcU7jVFQCGExoLMeZjglQ= 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=bV4/2Mgi; arc=none smtp.client-ip=209.85.222.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="bV4/2Mgi" Received: by mail-qk1-f177.google.com with SMTP id af79cd13be357-8b220ddc189so2012418085a.0 for ; Mon, 05 Jan 2026 06:53:24 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ziepe.ca; s=google; t=1767624803; x=1768229603; 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=0VJAy1LxeO1DoMMmQqr6qf7GwbBJdW99Z0xb4rwj9wE=; b=bV4/2MgikgXprMJ2j0430LwJLfgPNePxG71j/FosCi921Jf/s+2kE263Shgu2wUJ2G ZU31EA6BhMX5zGSZ0F0+wUYVNPbFcC4cq/agByDrdATBjGeEUrXVpIgGI4B73CyhJHGF cEgH+nOTt6YAjl/HrKSwfa6wFHumgZoxCEq9UCvZ/HP2QIaDkiATgadZg0hGNEePBB8B rTtk/Va+sPVgWwM7Tgtjf+gD+iDrnJmJchTypWUbNB+uMqbLqKjFoF7YU2fCAn8s4hgU uUkipGPs0aiaa9YoiuUT1saayDC5ku3ap9ZPFLmnhIlh9ednRqwPxL3mtHLbfMUqff0E 4bog== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1767624803; x=1768229603; 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=0VJAy1LxeO1DoMMmQqr6qf7GwbBJdW99Z0xb4rwj9wE=; b=ahojytLfxVZ+metbHLsdjCuqgZFuyhKwztpl3FQzTQ/iqabHkA2U4ZtVe83u78y7Ie CvIuUcomxkT61W8CXIjHkwqLAdb9it4mDCufHvu2dT3evCA5tHDpWagrfE0dzAFV7rch dVs14ZYL8T22ZgZA3vm76ONZBIlcrOVvEYhmZNBumslgqzSr539AVMkLC6ZWQk2VUKJ/ jQHcbkKow4O/sHKS4O7WO/NNOG4q5k8Q51RxtR8zZ+rJZkIRq/YQ5Sa9h5lv2pVyo8cA LJUkVoGo5lEPGDFFRTxcXBHUwElevalUDHo6bmZdN97oTVM20wk/mrvNpVZXjwAzdUaU cuow== X-Forwarded-Encrypted: i=1; AJvYcCU+yimaEuebbJXBMXScrIxD/BxNGMaJry+wP4MNzEcMAzylHhzRmON1WePSsVxG0Di0NO0BqkInEBUHXfI=@vger.kernel.org X-Gm-Message-State: AOJu0YzknCPIeZWnv9j7oltG/XNqDrxVP3nDEVefZklY0aFHC8m4yLGV YF1sykJ0mwv4kfgTwb05btOgKJ5y+0QnXZtp75LRI0PV+AtmH81kLeStgfVEdzdnx38= X-Gm-Gg: AY/fxX5E3YjfTsOaIZVoZ1jkFRpEUhpolsX2XTX2fO7S5eK872qxyo6EV4tlalXSd52 +XupJEde+wlMnHElaBHaxqxRu61CYHUWcxf21CRStGGCS4NQz0C5ololtLYsBAmxJzNyU/lYMcq Al3+34oE3wUxIGb+b+q/9719YbMNiiw1xomTLfmCKbMvTdSpl+SXHIYsWQMUMg+ihnW6/yoSelJ O61GvtoEOJj6khX6Ld3OPxHugiS4auUrzX0dAzZHU6KEKLcOd1+Me3qdtAKsnqVVrDvEMSyOO+U +qBPBiUcnqdY8Qvs9K8QUTtvRsKF8o6lMvGkqN2gFfGlanUXdwPCgRbyhx+pkUXpghlgrCnn5K4 EFj29PIEJLRmFurKoga8U55eLmu5DxNsLFV/P7+cnlN7jdwZE+8rvougjuBAYMXMjZSqEGjCgV/ L+dKrbDUWu+xQ2g7jE1g9X0WFroSH6FhoxdopMeSLDa/OO4h7OQxz/DfEO295IMpTgOiY= X-Google-Smtp-Source: AGHT+IFUt6wPvI9u2rR/xi8Np2VLLWZzGxeI/Po3U8DHhN0nYQEKldceIemvjTqj2Iro8b99/psoBA== X-Received: by 2002:a05:620a:4611:b0:89f:19e:46fa with SMTP id af79cd13be357-8c08fab5a22mr6994767385a.20.1767624803162; Mon, 05 Jan 2026 06:53:23 -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 af79cd13be357-8c0973f28e3sm3963769885a.45.2026.01.05.06.53.21 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Mon, 05 Jan 2026 06:53:22 -0800 (PST) Received: from jgg by wakko with local (Exim 4.97) (envelope-from ) id 1vclxR-00000001ANB-23EY; Mon, 05 Jan 2026 10:53:21 -0400 Date: Mon, 5 Jan 2026 10:53:21 -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: <20260105145321.GD125261@ziepe.ca> References: <20251229002354.162872-1-dawei.li@linux.dev> 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 01:33:34PM +0000, Robin Murphy wrote: > The assumption is that if the SMMU is not I/O-coherent, then the Normal > Cacheable attribute will inherently degrade to a non-snooping (and thus > effectively Normal Non-Cacheable) one, as that's essentially what AXI will > do in practice, and thus the attribute doesn't actually matter all that much > in terms of functional correctness. If the SMMU _is_ capable of snooping but > is not described as such then frankly firmware is wrong. Sadly I am aware of people doing this.. Either a HW bug or some other weird issue forces the FW to set a non-coherent FW attribute even though the HW is partially or fully able to process cachable AXI attributes. 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. I didn't see anything in the spec that says COHACC means the memory attributes are ignored and forced to non-coherent, even though that is the current assumption of the driver. > If prople have a good reason for wanting to use a coherent SMMU > non-coherently (and/or control of allocation hints), then that should really > be some kind of driver-level option - it would need a bit of additional DMA > API work (which has been low down my to-do list for a few years now...), but > it's perfectly achievable, and I think it's still preferable to abusing the > COHACC override in firmware. IMHO, this is a different topic, and something that will probably become interesting this year. I'm aware of some HW/drivers that needs optional non-coherent mappings for isochronous flows - but it is not the DMA API that is the main issue but the page table walks :\ Jason