From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mail-wm1-f49.google.com (mail-wm1-f49.google.com [209.85.128.49]) (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 1525238B140 for ; Wed, 15 Apr 2026 20:43:11 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=209.85.128.49 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1776285793; cv=none; b=pui//aArutgXb3hITSvBuZk4sgg7Q9+N8ZzE5UQzH+C5GzwefanJ1ELchd0YBhsnWrmjpL8epA0V0Y+y4GIczijgz7z4P7G17Z/uhRTQ+x7iWwkKcBgkcRoBNlfWzqKpCtcTIq9Crig7eQhivG4OhUYDpwk2Wd6KKo1f4tDw7Bc= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1776285793; c=relaxed/simple; bh=vfi6Q1Mu41b5c1Pr+FpKRKl3TJAWTCn0dsYCuTL07Ko=; h=Date:From:To:Cc:Subject:Message-ID:References:MIME-Version: Content-Type:Content-Disposition:In-Reply-To; b=BAMEguiRGa9CZo7xGlQlYZjdVptwNoh/BkBXAj/uRZ4cEZjnzkwqrigBaGFOspC/iSZx3XB2P0MWeGsm8Oe2LEYLM9GoFJqK3Sj6i5l8aYVotwjF1sA+sF+TFSWCmCmSHEuqQ+hz0iZTCys0iKmCRj2xGAZVoti/DZ/MeC6HRio= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dmarc=pass (p=reject dis=none) header.from=google.com; spf=pass smtp.mailfrom=google.com; dkim=pass (2048-bit key) header.d=google.com header.i=@google.com header.b=FakYCZRX; arc=none smtp.client-ip=209.85.128.49 Authentication-Results: smtp.subspace.kernel.org; dmarc=pass (p=reject dis=none) header.from=google.com Authentication-Results: smtp.subspace.kernel.org; spf=pass smtp.mailfrom=google.com Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=google.com header.i=@google.com header.b="FakYCZRX" Received: by mail-wm1-f49.google.com with SMTP id 5b1f17b1804b1-488a62b7372so25805e9.1 for ; Wed, 15 Apr 2026 13:43:11 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20251104; t=1776285790; x=1776890590; 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=4YRQzWoS4RDEswHnpylQeJ+99oJ3JUS+eOagFQY/XkM=; b=FakYCZRXp6AKYS0Vp0QdHfTGtqK5UM6C6MPsz2hxsdPfHmEdaoMWdMgmPuMskaFKgp 5mYs1+RAhMoMCyUM7hx46Xtvp4AQOYXDjg7QRVQVFv5Nh7dYv48gKaOzBj9Jj3O0zdH9 JmRcfE9/C/d/cQA31qZ4GHd9Anao5vyqrYY2q3rRpUArDMIEDaUBKbds7R/E+Rtt+qWe T2Q/5WBLD9WfG+WEtIj6JtsjxLMbHtZ4IHbI2GfqwkMt/CXlzrNon2f4p0gl7VG0Ne3Q lE5uQKDqPcnKF4Pi0cP7zwT4KE5B4lprGfBUiLZD9aUpXsNO/dmaEZXBDqqLZ1EiJZzC APFA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20251104; t=1776285790; x=1776890590; 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=4YRQzWoS4RDEswHnpylQeJ+99oJ3JUS+eOagFQY/XkM=; b=OreHhH3wJUovEcdhY1vTFO0Eu/xGrnoVur8bkpVGyqHSYF5R1j8d1v1c3tiZTdHX2j kfIPCE9Aibj9rnJip7ZjZwMbq3u8PoUQ9EjrNTEJhRnbNtz/W6b2oCQxp454wPP5HT7w Sa6Y5Yny7X0pmJzxRHG+70m93wPMeV7Yo0k1gpYvjV3oqpOCN0+IT8Rlfa8mw679k5bh 2uYnxWC4gpFv52IksRhTvdZTRaVsKFs+o0uXK9J6ygYfsl7vPlhLDN1aIV8Wa22vANxf vIuaZhed+65OzxU2PToWS+Cd5mxyLQDKrGiD9Z3G/XV8GuBNWi9Q61kFjx7iuQtNp8oR UtHw== X-Forwarded-Encrypted: i=1; AFNElJ9XcSJd7uF76RAZh+DdN/uB6+RSpSyltEhaZczmouBsKrG3ZcsUFP6x8hKMz2ONMRXVNctqrt2obD9IY6k=@vger.kernel.org X-Gm-Message-State: AOJu0Yx5duCUOilXy41EHBJUnTGS/PSFFNq+6jwouypdyYqj8QBg/LCG tkD3+MACRJKzyLEa5thGFeTxb3FKR+m3kAT8h4ErQh24hXK0jiHB6K7+oOXerUaV0w== X-Gm-Gg: AeBDietz2GBaKSkh+4ifX8aHPqoRco7uvrkB2LKRYM5GlHJmesPy6090cJDNVI1WTfA YcOEnEcsOaEkEDJ8xhfUBG9e2aeWNA8X7oXdM7KpeuI3vMapCr5qiZRTD/7bs1R1lPWx90w4aTs ErZCXUpmsoxu0MZNoD91AU85dykhu0a13MFty3yWlwGLJt0kKShDQMRmu4HbvVxXP6L3Wo1h97E DlRk/2MsBa12hXjGqnwaUVLuUYjdH6B6UrJXmWKyslgOiLF1cEhM1NWskJSa6yf6aTM289fjmhE MWQiK9N0vFG0N5KR5ok2zbUhfIZ19z3AEBWDy83WdfQlyS6Dlv2iJGQVKQc0xm+5egdnBod/ipI Z1gC+/Cm8e2xpIeU+uN7KdmH1hz6TFS+uzzyjwTe6XQDjqy8kRt7iUMwcnseEuCFD1LZvXDR7Wg Zcvfqq14k0C7udNnn6iO1+k8KlD2tfOCKl2FzIku4wxuTcVSDb5QfcqCW9Xq91ylYXS8OROIXEB jzqvd3HHmFjlz5i X-Received: by 2002:a05:600d:1b:b0:486:fe1d:a60e with SMTP id 5b1f17b1804b1-488f4d77023mr103595e9.0.1776285790115; Wed, 15 Apr 2026 13:43:10 -0700 (PDT) Received: from google.com (8.181.38.34.bc.googleusercontent.com. [34.38.181.8]) by smtp.gmail.com with ESMTPSA id 5b1f17b1804b1-488ede1e05bsm257930935e9.6.2026.04.15.13.43.09 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Wed, 15 Apr 2026 13:43:09 -0700 (PDT) Date: Wed, 15 Apr 2026 20:43:06 +0000 From: Mostafa Saleh To: "Aneesh Kumar K.V" 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, jgg@ziepe.ca Subject: Re: [RFC PATCH v3 1/5] swiotlb: Return state of memory from swiotlb_alloc() Message-ID: References: <20260408194750.2280873-1-smostafa@google.com> <20260408194750.2280873-2-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: On Tue, Apr 14, 2026 at 02:55:33PM +0530, Aneesh Kumar K.V wrote: > Mostafa Saleh writes: > > > Make swiotlb_alloc() return the state of the allocated memory, at > > the moment all the pools are decrypted but that would change soon. > > In the next patches dma-direct will use the returned state to > > determine whether to decrypt the memory and use the proper memory > > decryption/encryption related functions. > > > > Also, add swiotlb_is_decrypted(), that will be used before calling > > swiotlb_free() to check whether the memory needs to be encrypted > > by the caller. > > > > Signed-off-by: Mostafa Saleh > > --- > > include/linux/swiotlb.h | 25 +++++++++++++++++++++++-- > > kernel/dma/direct.c | 2 +- > > kernel/dma/swiotlb.c | 23 ++++++++++++++++++++++- > > 3 files changed, 46 insertions(+), 4 deletions(-) > > > > diff --git a/include/linux/swiotlb.h b/include/linux/swiotlb.h > > index 3dae0f592063..24be65494ce8 100644 > > --- a/include/linux/swiotlb.h > > +++ b/include/linux/swiotlb.h > > @@ -63,6 +63,7 @@ extern void __init swiotlb_update_mem_attributes(void); > > * @area_nslabs: Number of slots in each area. > > * @areas: Array of memory area descriptors. > > * @slots: Array of slot descriptors. > > + * @decrypted: Whether the pool was decrypted or left in default state. > > * @node: Member of the IO TLB memory pool list. > > * @rcu: RCU head for swiotlb_dyn_free(). > > * @transient: %true if transient memory pool. > > @@ -77,6 +78,7 @@ struct io_tlb_pool { > > unsigned int area_nslabs; > > struct io_tlb_area *areas; > > struct io_tlb_slot *slots; > > + bool decrypted; > > #ifdef CONFIG_SWIOTLB_DYNAMIC > > struct list_head node; > > struct rcu_head rcu; > > @@ -281,16 +283,31 @@ static inline void swiotlb_sync_single_for_cpu(struct device *dev, > > > > Should this be a property of struct io_tlb_mem ? I envisioned that this would be mainly used by restricted-dma so in that case it doesn’t seem to matter. But generally, I guess it would depend on the discovery mechanism of this memory property and I can imagine a memory allocator that has multiple pools with different attributes. So propably it's better to be per pool. Thanks, Mostafa > > -aneesh