From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mail-qt1-f174.google.com (mail-qt1-f174.google.com [209.85.160.174]) (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 EE2852505B2 for ; Thu, 8 Jan 2026 14:45:22 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=209.85.160.174 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1767883525; cv=none; b=OeZVBfIG2RlRh15H8Hla9k3C+XJEaUFtXadjnQ0XUVn6W4nfsrszkKjqeghpH8xzGO7rseHvpyO2Q757g7HG7UI+sz3KjXk/H935LDVfuqsfYVCaBn4E+3aeHIlc0UBeB9Cuwl3NSrDYFsOQ1Bii26j4bKU211wD3dDeBYCm2No= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1767883525; c=relaxed/simple; bh=DhBkaXnKGIzDRLsxPLOuraqjH4fA+nbCX0ARvwiyQ1o=; h=Date:From:To:Cc:Subject:Message-ID:References:MIME-Version: Content-Type:Content-Disposition:In-Reply-To; b=bqD8WMdHZ2n9lST+g6vgzbbDaItX4sr6ssVcusbxDxmlnRbYSsm4xN90Qm2h4l+QIx1Gu+9zranuNB9WRIGxHSBSNpG2TSgTfTg/wKW995LQCKFrfZbMnPTtQweYmHFuJczQVhAkix10Rk+6zv8ZdRwJemsYO+YH+ZXbUthhFAY= 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=BHt0CQlj; arc=none smtp.client-ip=209.85.160.174 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="BHt0CQlj" Received: by mail-qt1-f174.google.com with SMTP id d75a77b69052e-4f822b2df7aso42668601cf.2 for ; Thu, 08 Jan 2026 06:45:22 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ziepe.ca; s=google; t=1767883522; x=1768488322; darn=vger.kernel.org; h=in-reply-to:content-transfer-encoding:content-disposition :mime-version:references:message-id:subject:cc:to:from:date:from:to :cc:subject:date:message-id:reply-to; bh=N4LHsOGc5pju7+ZZ7G/UCMXvDe5juRNxgmay6MHvgpc=; b=BHt0CQljt9rhtUIM5oYuO8rYHYnR4F6mbUdUvpOSwnjWruEkTumsaCY4K5yvMMN+U5 4iJdc7jiuLUHhnFcBShqzX8klKb/bNZMpWJO8YGSCJgHvj6wrz8YGzxsOOHaev38Pahy 1WkNOtD7YunFPHXRmA6CRWEiF3mc164IVVglAJIORvK5s+Roeoy5sUvBnWxPM/4YBXw6 ovpR+hEbQ6uE3K+PDTh8MRT+tbkESQ+CjK38Yhkdry79GQssQG/mskFlwZjcH7NiCU9V SIbrGA3RD+1ZAOiRtOKaAl5JzoTRBJK6Gy8wkw19iKioaFMYY7M7HJ3mBJ45xojHXHhP Lm+A== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1767883522; x=1768488322; h=in-reply-to:content-transfer-encoding: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=N4LHsOGc5pju7+ZZ7G/UCMXvDe5juRNxgmay6MHvgpc=; b=byty/FscCnShEXEZIdHPCcmlosDMLJUmQpGTg4m+5c1ej80Hbxb8Ly7AYljA5GYB44 Q9zhLN7CbGzVvJSMh5b3jSKfR3q49winZHnRGGdzJOb052Dik2JDFcHLPoTMFiP0Lg1l qLBVpCd60XPWqXOv1tbUtHitXJnyzxl8Uqx3CbY5tWGkLMMVlvguju3xBOejti186o4I qb/vS7wb/gKkKI81SKpmLX1PZ0nHzcd10XdXw0BpZwQBv5y7Vm5iQlQhQ4QvToYEpQ/d HNuU+wCr3LC5uI+tIUCfZT0X3tE3afqkGwwEOopZw+7Ju9QSLPHG7/yH6gioSGwM7wKB lLqA== X-Forwarded-Encrypted: i=1; AJvYcCX3OoVoTgxXJlwAidil+f9ICR2cpWzF6GFgkauFC78+QxuLGraBIvivJA6q7nCzppwmHhyjZD+SCC1BqRc=@vger.kernel.org X-Gm-Message-State: AOJu0Yw2Jy0T02jPkD2FuW1OjHVMBEuYyLeWpJVWVYR3RYACB8w1h/m2 m9eNh4Xie5t++aIlGLhOMAdcqu6gZpbQxfkbfxa9TGj1DVB6k+c9mLSE5AcuVs9QWIRVr4OBAAK Yg7cn X-Gm-Gg: AY/fxX7B8/8ilMAtYDycSTC1yVOkoSLyQ7ihL+AjfOqX0Os1put3PaqlShYTgLFr5gn zrcwhcbcwg0XycfBUl0BafiUaQWjjAcI/lrk/aVEKCIUGl72CfZ6A2NfRvrzcph3fdkHMak6THB p/I8TcuBYtq3/rQzb33mlfCjT0TCF6GPDbTs2LDnBTAUrfrxl6n7XSVy8PyFG0omBjd1tLTUl13 f2IydJHZ3NzflPKIbb+Xaa+bupnDMC8Gqtnk/QI/v6V+uIk/lJQdegSSy5clAkGCG84tTrU6jj7 yLiy041E3Ds/NLhlnQoT5AWWj+Bd7e6FWnhJS2gkPAP8Wd7O5EjprQUc7SeGDa4KCukDVFWi4yh l7mDUnPKIQ2m2HpwDNJ/VPrG1eCiZHapR8tEZxRTE/iAcLcur9/CGIzAcjkbk6KITR2okWvh7Bw vrtr4Of7/Vl659iIIWbuieK55r4neGlp/RvgaNE60TbSRR5Xey5nYaDUdFzZGkYYxdpfme+sZkb rhKOg== X-Google-Smtp-Source: AGHT+IES3ov00CDdYvOziEIM2g2UrgYu5X+EmgztTduCXnjzLnO2ob95S0v4/KfSRH05axzpnJtLpA== X-Received: by 2002:a05:622a:2297:b0:4ed:b8d6:e0e8 with SMTP id d75a77b69052e-4ffb48a86e1mr83270651cf.22.1767883521678; Thu, 08 Jan 2026 06:45:21 -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-4ffa8d64563sm48461021cf.13.2026.01.08.06.45.20 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Thu, 08 Jan 2026 06:45:21 -0800 (PST) Received: from jgg by wakko with local (Exim 4.97) (envelope-from ) id 1vdrGK-00000002MBP-1mPB; Thu, 08 Jan 2026 10:45:20 -0400 Date: Thu, 8 Jan 2026 10:45:20 -0400 From: Jason Gunthorpe To: Mostafa Saleh Cc: iommu@lists.linux.dev, linux-arm-kernel@lists.infradead.org, linux-kernel@vger.kernel.org, robin.murphy@arm.com, will@kernel.org, joro@8bytes.org Subject: Re: [PATCH] iommu/io-pgtable-arm: Drop DMA API usage for CMOs Message-ID: <20260108144520.GE545276@ziepe.ca> References: <20260108113846.56179-1-smostafa@google.com> <20260108125934.GB545276@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=utf-8 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: On Thu, Jan 08, 2026 at 01:44:51PM +0000, Mostafa Saleh wrote: > On Thu, Jan 8, 2026 at 1:27 PM Mostafa Saleh wrote: > > > > On Thu, Jan 8, 2026 at 12:59 PM Jason Gunthorpe wrote: > > > > > > On Thu, Jan 08, 2026 at 11:38:46AM +0000, Mostafa Saleh wrote: > > > > Jason pointed out that the DMA-API calls are not really needed [2]. > > > > > > > > Looking more into this. Initially, the io-pgtable API let drivers > > > > do the CMOs using tlb::flush_pgtable() where drivers were using the > > > > DMA API (map/unmap_single) only to do CMOs as the low-level cache > > > > functions won’t be available for modules. > > > > > > This isn't what I ment at all, the iommu-pages.h could do the flush > > > inside itself using the already existing > > > iommu_pages_flush_incoherent() instead of open coding the dma api > > > calls everwhere, and maybe that could directly call the arch function > > > on arm (as x86 does) which would be easier to implement in pkvm's > > > hypervisor. > > > > > > > I see, so basically, we add the check for IOMMU_PAGES_USE_DMA_API in > > iommu_pages_flush_incoherent() with the DMA-API stuff and call it from > > the io-pgtable-arm instead. > > > > iommu_pages_flush_incoherent() is also used to flush non-cacheable > pages in generic_pt from flush_writes_*(), so it might not be that > simple; We might need to add a new variant. There are no non-cachable pages in the iommu-pages system??? All memory comes from folios and is mapped to the CPU cachable. The general API requires the user of iommu-pages to know if the underlying HW is going to do non-coherent DMA, in this case it must call iommu_pages_flush_incoherent() before the HW does DMA. Effectively what I'm saying here is to convert the arm page table to use iommu-pages and then put your pkvm abstraction at the iommu-pages level instead of trying to hack up all these users. You can also do the same conversion to the smmu driver to use iommu-pages instead of DMA API, AMD and Intel are doing this already. Jason