From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mail-qv1-f42.google.com (mail-qv1-f42.google.com [209.85.219.42]) (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 70708324B23 for ; Mon, 30 Mar 2026 15:27:15 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=209.85.219.42 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1774884436; cv=none; b=R1xbi/AngyIqWFg23FdC7EHrkWafD9MXLtvnCHP4F4BaRST/3nsioxBL+YeKBBnkuPNYk5GgBSVkHbXfnVkmk3ya5ar1/Xhdy4Y6DHlijuw/qlFb+jba6tOJajqxPOQlo21vH7Ynu+sbqlCMTu3YxAeFN56ijxuQ7jEERpFEPhw= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1774884436; c=relaxed/simple; bh=oIYwPCUTeaq503GoqCcrgdU/d71ypzxo9n4oPWrPllU=; h=Date:From:To:Cc:Subject:Message-ID:References:MIME-Version: Content-Type:Content-Disposition:In-Reply-To; b=oANbtM7E+tR+1EhrcowxncPKTXmxcatX5Nvb+WN7GdMuXJ/+AEFFqgOob/oBFnZswwrMLGKQQTVsj+L/G1+MtPNuUjrggmuJO1HBb1snQpMT6YfJ68G9/0PIgsnrgP6mWMtY4P8aj9Qnuq9lOz2ZxcKtoFE8WfB7XXfVLWexfqU= 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=W/nP4Fuc; arc=none smtp.client-ip=209.85.219.42 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="W/nP4Fuc" Received: by mail-qv1-f42.google.com with SMTP id 6a1803df08f44-8a0323830beso15059866d6.0 for ; Mon, 30 Mar 2026 08:27:15 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ziepe.ca; s=google; t=1774884434; x=1775489234; 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=v9C6Jq63vgWqSjlbaCEq8eF8GLl626VKV7hFMNLufRI=; b=W/nP4FucmliIdzoMm6yeo5TqYMid0fjD/rMC4QLKfVf2ss+4h+0eG76hbCIkdCs+lU HTEzA7qM1wTA77xn3Zj/3Ok+NO2gvjY7FJ+IhbK6xJ1l8iQp6JBGcfp/QeDmKxXA9Wdz 7qve96TcvUawzhKWW2QY7dNCwcJkXtdwAM+30KimMFRRKvrBSpJNPlSRfJFeSGk6KYRA IzDe1eBxVJvNd1o9jEijlyGqMLkktU4RusUBbvxHdsihmYm1pB7zk1kXwR8KK5JZ323z QPkPG3Oe9NXECuUF+vLVXEGoGVq4E5romYDQ08plqERwJCb/CJ5xUbBN+CzRLHLpyF7N YWqw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20251104; t=1774884434; x=1775489234; 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=v9C6Jq63vgWqSjlbaCEq8eF8GLl626VKV7hFMNLufRI=; b=HInrvd91c41PFa92DFp1tRquwrF0TtshAQjLd+aFXiVsibxKpTKFra89vulixT8XBL MriPLVkXyq1O0bNU6yMljPH9yX19osr08qDwbhgDpkeiSp0pBW0x5/g2+x9hFRZElvSX KtrL/a9O5x8P9CbXt2sRqOjatYPJ7oAANLQTHL3QWQHrBoUv9fZGqDwiMQje9t6/n5Nn JbXWEQPrL58TUBcSdJ8F7MV8XVm8MlcfI80nSEbmsfpZUiMZUBm8MHy1PiUHfMqj0es2 gzpB0YEOdxXCwLDm9q2yvIFjxyhWg2hOqusoPBoOrnLbDbTbwdB9HbBo9W0uxyjcG6sC 5GwA== X-Forwarded-Encrypted: i=1; AJvYcCUZvVmY/4qyEXjjjPXZgD0VgmuzPLQjPcENsB4D8NYhCWV9EpU5A3KINtIbXMyFZkP+elD4KVfMpJIMbIo=@vger.kernel.org X-Gm-Message-State: AOJu0YzQqTFCzuXt23jacVDG0SIyKUojUL0g/kSqYDNX7oGqDlTpHSvI SFcx++vAkhXpHaWCL2hGM1rVAjwgtJGBrLr344fDjadrTGLgIu6dX7oPHhfebt1X1m4= X-Gm-Gg: ATEYQzy3VbufexoC0TzfsCP+leIAL/TMVX0+PAKEJ9muhC9uLBN3dZkAVYcLD/e7iTY VUy8lCrplL+nt7c0ZxxA1hv2p9rSsDOpgM3QuRMqsbCNOC4vym/B5beq53nYnb+xO73A6dCwUWm s+1GnaZsLfg5u32ATQR5rYix5JDCq5eOJ+A6NdWM823Jdf91Ew2XJKN+BhyDrxrKoJDX9w490Vx py9mkzDu/Uy6TDxYAqH0XgDWZnDCoR+nwvk5fI1/6ZsUaWCIwAUcWNPmY13pIPhQomdaVqqTwo+ EQ8ivw/BM4LpFtjgnGuZIIBBbMmZrQYl4FuJ/Zk/jOvmypoxJuuckZkhforNT8E0fU7OVz0CDVd Q3M0abKwXjuNDlMX/C8uW21zhVPLCCyEj9yJokOECAWahIJCPXaheChG+AaQtMepzAOI/ggEx9b lmkrL3wV4urvSkaW/3pMQ86d6Y1O03wuOpy/t+97jkgoY3yQ0mmLbFhivrZyVuq2NPK5ogyQ== X-Received: by 2002:a05:6214:528e:b0:89c:5e33:2cc5 with SMTP id 6a1803df08f44-89ce8d93406mr169503266d6.20.1774884434097; Mon, 30 Mar 2026 08:27:14 -0700 (PDT) Received: from ziepe.ca (mctnnbsa70w-159-2-73-22.dhcp-dynamic.fibreop.nb.bellaliant.net. [159.2.73.22]) by smtp.gmail.com with ESMTPSA id 6a1803df08f44-89ecb5cba4dsm64471366d6.9.2026.03.30.08.27.13 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Mon, 30 Mar 2026 08:27:13 -0700 (PDT) Received: from jgg by wakko with local (Exim 4.97) (envelope-from ) id 1w7EWG-00000003UmP-39ia; Mon, 30 Mar 2026 12:27:12 -0300 Date: Mon, 30 Mar 2026 12:27:12 -0300 From: Jason Gunthorpe To: Mostafa Saleh Cc: iommu@lists.linux.dev, linux-kernel@vger.kernel.org, robin.murphy@arm.com, m.szyprowski@samsung.com, will@kernel.org, maz@kernel.org, suzuki.poulose@arm.com, catalin.marinas@arm.com, jiri@resnulli.us, aneesh.kumar@kernel.org Subject: Re: [RFC PATCH v2 4/5] dma-mapping: Refactor memory encryption usage Message-ID: <20260330152712.GD809900@ziepe.ca> References: <20260330145043.1586623-1-smostafa@google.com> <20260330145043.1586623-5-smostafa@google.com> 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: <20260330145043.1586623-5-smostafa@google.com> On Mon, Mar 30, 2026 at 02:50:42PM +0000, Mostafa Saleh wrote: > At the moment dma-direct deals with memory encryption in 2 cases > - Pre-decrypted restricted dma-pools > - Arch code through force_dma_unencrypted() > > In the first case, the memory is owned by the pool and the decryption > is not managed by the dma-direct. > > However, it should be aware of it to use the appropriate phys_to_dma* > and page table prot. > > For the second case, it’s the job of the dma-direct to manage the > decryption of the allocated memory. > > As there have been bugs in this code due to wrong or missing > checks and there are more use cases coming for memory decryption, > we need more robust checks in the code to abstract the core logic, > so introduce some local helpers: > - dma_external_decryption(): For pages decrypted but managed externally > - dma_owns_decryption(): For pages need to be decrypted and managed > by dma-direct > - is_dma_decrypted(): To check if memory is decrypted I can't even make sense of what this is trying to explain, talking about page management along with 'dev' is nonsense. The management of pages is intrinsic to the API, it doesn't change. I think start with adding a direct flags annotation and then come back to figure out if we need some kind of helpers. I would expect any helper taking in dev to only be answering two dev questions: 'dev can dma from encrypted(dev)' 'dev can dma from unencrytped(dev)' At each of the points in the API flow the phys under consideration is known to be encrypted or decrypted, and those two helpers tell everything needed. So I'd expect the restricted flow to look more like - phys comes in to be dma mapped, it is encrypted - 'dev can dma from encrypted(dev)' fails so we go to swiotlb - swiotlb allocates from a restricted pool, and learns through flags that the new phys is decrypted - decrypted phys flows through the rest of the machinery. We never check 'dev can dma from encrypted(dev)' a second time. Jason