From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mail-qv1-f41.google.com (mail-qv1-f41.google.com [209.85.219.41]) (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 3D7C61514F8 for ; Fri, 10 Apr 2026 18:05:07 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=209.85.219.41 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1775844308; cv=none; b=DrQqY+TxKULFmiq6ebF5HUDdlA0iwMEhXidQO7V30q/5PFfZYmSeLb6bTEN8ioVknM12vHeZzzHdk4ESJJuWQXY/bGADi66ER6c7hbX6n8qhTVEk/uqTYLPM6EDUHCw2K8BWK82xvEb1fJAloWA0/MIQ9vqMaZIvQ4wC6ELt/yw= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1775844308; c=relaxed/simple; bh=usWOYWnYcX1AbQl2wC2HZ47sqdaQ/cZVDz0+E3wJc2E=; h=Date:From:To:Cc:Subject:Message-ID:References:MIME-Version: Content-Type:Content-Disposition:In-Reply-To; b=UhmcKOffFfzXv19hikuI/r6rwYbU3/NsbooKESOmBEWb8cxJwgIwsn++LCjofeiqEWofINutnKpEFbyrHZd7lf+dE9zE7XV2LU6ahx6ZrC0LoKWMsEV/KI5/+A3Q0oyeu5SW/7eENKufooY41R8yMq3ek+tdsz6aV6bj3G7sNtc= 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=opYLYyRt; arc=none smtp.client-ip=209.85.219.41 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="opYLYyRt" Received: by mail-qv1-f41.google.com with SMTP id 6a1803df08f44-89cc71f4311so27155806d6.3 for ; Fri, 10 Apr 2026 11:05:07 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ziepe.ca; s=google; t=1775844306; x=1776449106; 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=DMIIkOGUTTrV8K244TmXAqc0Sap7K8R5PskuCUGSVEE=; b=opYLYyRteaEs2sgjzCa0EGCpdKu6A9m2qS3Ci7+st+MVCcLE/qOoccISiQf/lrcucp 2Dd6mOznm/kWHJWJsNtbU2/0B5KwVTbyT6vEZQaa8hLP7MOWOoipN7K0g0JL2YTdOehV 3eYhRqVO8aZAVWxCD/SUKnkP8obnYC6FsdjucOTJ/g4Cx4Q0Y3hoBrdSuTlyV4/r+yS4 UFNPkS8rJEj/OxfSCXQT3mOhjSXZsZLP1FYa0eaRJXFziq2dFWk56+S4QRPaXMGEb7Ji ffAoH11IrA2J2oXH9x2f8slsPblq5qa7G/cNdCG8ZDQqY5OR0fuVvksLIpwZQZVegQxX zUqQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20251104; t=1775844306; x=1776449106; 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=DMIIkOGUTTrV8K244TmXAqc0Sap7K8R5PskuCUGSVEE=; b=JGMt8OUWhuEAT+vT1ZSbBBekiMUxs3SVVbLREgKsaPgUUnJ77Ehyk6BOrj57/A5tYH wiJZE6CRqgKgBqpqag+IRfteBCxMfXUAEG5CUt+TqyzvwDLvuOFVQCXAKQFz+4EtlMMR 723xpQPa3VSgCrtsaNOWXwDtIGOAvSBP8LYdCiSM0pO6A7jcMn+aH/klpmJuHTeAzpse fl3sH1fU7EUWZ8pUQGzu9sCXpF0/F65uhNOu3hf5jkojR0rfwwjABy9wgaN7+5F37/kv i7WZBsGGrll+cnDKinHeloab2D2A1HOo3sy45RbzbVcwQMbWQ3N/tsZYahMKVegnRXBO qerA== X-Forwarded-Encrypted: i=1; AJvYcCUqwKCNR7gS3kLhAoVVYEFByVR53GrF+a9/MepcINBZBIgCRwciOnMQ24OuH7dRvBkvlWdGXnixg8s1ItU=@vger.kernel.org X-Gm-Message-State: AOJu0YzB47flD2+gBkU4Pf0lviCMBc9sSt22idGVxS7B7UCzMITFrvmY dXS3ySzNl3CSxtB/ISpSrLRJIXzX8GZ6HaXEF1hlcDyZridfP5fe/FZur5e2ytyL4ps= X-Gm-Gg: AeBDieuTxtBOpyyPrxdkryToNHJN1Q3bcTHYtpYnqL/5Bxd48xEUZ/mg3bcw29Cq3fe LLEFoOl+7Fs27+y/pNLzsWCaUqw7DhS3gjpCcmAF9GcLGFQuhNcUcPGPlIqqCJFbaSwz44hzQx0 ghtfbHq2lvssegORFFtJnDDMDH7Wmyp7mk7U1rdX0WjrXnko+BCMYFIl7X0pLsoOfp7rlgDlX+0 Aoco2BJ/1uiUYVRogJSDGRCr6f6Ee5SlbU/rnTjjTEBTlbD5xgvFfsCYdTU5w+/TQ7GAUJPwQXo x0OcqSmpJiPU8C4a9Ka5084lln1AdpiC/KDUjw3hhBitiCnX0g4iBg6wqhq/YcjQneM5Rz1eRI3 vHPEbdzm9i+ZvJ8WBU48TXIg2rICN22PUb7dHAl99+64LGdEh7gtoeDZt/Lj2WMOzJoOIo2MR0O rgFag16KHlwrBvwRVHs7+o3Ajby15cRW5p1NMJLvB4nWpKtLZ8YEHoUpxjPHUgVYhf1wv1wkvVL d6HfLfb X-Received: by 2002:ad4:5ecd:0:b0:899:f845:a29a with SMTP id 6a1803df08f44-8ac86299318mr67584926d6.41.1775844306091; Fri, 10 Apr 2026 11:05:06 -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-8ac849dbb32sm29585576d6.6.2026.04.10.11.05.05 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Fri, 10 Apr 2026 11:05:05 -0700 (PDT) Received: from jgg by wakko with local (Exim 4.97) (envelope-from ) id 1wBGE4-0000000FO91-401J; Fri, 10 Apr 2026 15:05:04 -0300 Date: Fri, 10 Apr 2026 15:05:04 -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 v3 4/5] dma-mapping: Encapsulate memory state during allocation Message-ID: <20260410180504.GE2551565@ziepe.ca> References: <20260408194750.2280873-1-smostafa@google.com> <20260408194750.2280873-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=us-ascii Content-Disposition: inline In-Reply-To: <20260408194750.2280873-5-smostafa@google.com> On Wed, Apr 08, 2026 at 07:47:41PM +0000, Mostafa Saleh wrote: > Introduce a new dma-direct internal type dma_page which is > "struct page" and a bit indicate whether the memory has been decrypted > or not. > This is useful to pass such information encapsulated through > allocation functions, which is currently set from swiotlb_alloc(). > > No functional changes. > > Signed-off-by: Mostafa Saleh > --- > kernel/dma/direct.c | 58 +++++++++++++++++++++++++++++++++++---------- > 1 file changed, 46 insertions(+), 12 deletions(-) > > diff --git a/kernel/dma/direct.c b/kernel/dma/direct.c > index de63e0449700..204bc566480c 100644 > --- a/kernel/dma/direct.c > +++ b/kernel/dma/direct.c > @@ -16,6 +16,33 @@ > #include > #include "direct.h" > > +/* > + * Represent DMA allocation and 1 bit flag for it's state > + */ I'd explain this wrappers a pointer and uses the low PAGE_SHIFT bits for flags.. > +struct dma_page { > + unsigned long val; unintptr_t ? > @@ -103,20 +130,21 @@ static void __dma_direct_free_pages(struct device *dev, struct page *page, > dma_free_contiguous(dev, page, size); > } > > -static struct page *dma_direct_alloc_swiotlb(struct device *dev, size_t size) > +static struct dma_page dma_direct_alloc_swiotlb(struct device *dev, size_t size) > { > - struct page *page = swiotlb_alloc(dev, size, NULL); > + enum swiotlb_page_state state; > + struct page *page = swiotlb_alloc(dev, size, &state); > > if (page && !dma_coherent_ok(dev, page_to_phys(page), size)) { > swiotlb_free(dev, page, size); > - return NULL; > + return DMA_PAGE_NULL; > } > > - return page; > + return page_to_dma_page(page, state == SWIOTLB_PAGE_DECRYPTED); Should the struct dma_page have been introduced earlier instead of the swiotlb_page_state ? Seems a bit odd to have both If these are actually internally allocated struct pages, could you use the struct page memory itself to record the decrypted state? That would require more significant changes to the allocator calls. > @@ -184,9 +212,11 @@ static void *dma_direct_alloc_from_pool(struct device *dev, size_t size, > static void *dma_direct_alloc_no_mapping(struct device *dev, size_t size, > dma_addr_t *dma_handle, gfp_t gfp) > { > + struct dma_page dma_page; > struct page *page; > > - page = __dma_direct_alloc_pages(dev, size, gfp & ~__GFP_ZERO, true); > + dma_page = __dma_direct_alloc_pages(dev, size, gfp & ~__GFP_ZERO, true); > + page = dma_page_to_page(dma_page); > if (!page) > return NULL; I would expect to see more usage of the dma_page here.. Like I don't think this is really right: *dma_handle = phys_to_dma_direct(dev, page_to_phys(page)); Does page_to_phys(page) really work on decrypted memory? On CCA it will return the protected alias which doesn't seem like something useful? static inline dma_addr_t phys_to_dma_direct(struct device *dev, phys_addr_t phys) { if (force_dma_unencrypted(dev)) return phys_to_dma_unencrypted(dev, phys); return phys_to_dma(dev, phys); Above is all nonsense now that you have a direct indication of the address is decrypted memory or not, it should also be used right here directly. if (is_dma_page_decrypted(dma_page)) *dma_handle = phys_to_dma_unencrypted(..) else *dma_handle = phys_to_dma(..); The later patch just makes it worse by adding even more confusing flags to phys_to_dma_direct(). I think it should work out that everyone already knows what memory type they are working with before they call down to phys_to_dma_direct() - the calls to force_dma_unecrypted() here are just hacks because it previously did not. Anyhow, I think this series is alot better than the previous one. If you work a little harder to make it so there is only one force_dma_unecrypted() per high level DMA API call that would be perfect. Jason