From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mail-wm1-f45.google.com (mail-wm1-f45.google.com [209.85.128.45]) (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 65A6F3F5BF1 for ; Wed, 5 Aug 2026 09:10:24 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=209.85.128.45 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1785921026; cv=none; b=kz8zlpJxHveeB5tkBZjmxjOV1cvPYciM/PkflpRrvl6gn/U/5fKklTI3UGMQ3lCvqzRqD4+ORqOxj+G+R/wXAld1h5A63Tykq6WZ2f0nWcYULZKwJXrAmJsVIIA7IewCGy0Ilu/9SyAxQev2WfFmADjO3O0mAfL4fjjg3IvykGM= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1785921026; c=relaxed/simple; bh=gINDk3IoAOl14/uSe78s8gXta9IkyDgK1jiiLUqSSAs=; h=Date:From:To:Cc:Subject:Message-ID:References:MIME-Version: Content-Type:Content-Disposition:In-Reply-To; b=pOWbiEs750pb4Sygw4bto6kdRw5/GF6+Wg48C93tgB9Qwl7VPp/3z/IqAFWVfyRHZOEnusUl/5T53XHhhMXNDM/MqJQmHvsy+9tABiIcVWu8Zn/ZnKvm/QUptWhCedXytO9tJAnKOXY3yuFYmgzcp9ONK2WHFOABUeK+Sq1OP+A= 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=MUY4SAt3; arc=none smtp.client-ip=209.85.128.45 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="MUY4SAt3" Received: by mail-wm1-f45.google.com with SMTP id 5b1f17b1804b1-4954d5d814fso46355e9.0 for ; Wed, 05 Aug 2026 02:10:24 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20251104; t=1785921022; x=1786525822; darn=vger.kernel.org; h=in-reply-to:content-disposition:content-type:mime-version :references:message-id:subject:cc:to:from:date:from:to:cc:subject :date:message-id:reply-to:content-type; bh=Gc5m4+tIBvg0egjJhph4T+RN5CfIOJByD9/EsS70PrM=; b=MUY4SAt3iWUCThC9My4iK8q25dVRByYTSh8zwS4wvqRV1OTsIMqLh01YruBxXBHP/j E+whf8qm3opjNZdJl13Km4D3M7h2VcVrXsk+TvPwiraHMr77hEYWlOx85ow45SOuCbO+ d8v9XanvJCExvHD7Q1GPwe/o6dGPIcBgFCKzA4OLwu7FcQ9bBK5qH7Yr9/aEwu/t9gRl 2ijWQfUuNrJ8iHmyftvlcd5N1idOb8WKs7oGY61z53EwBd7V/0VXu5cOrwg6yJOKNMhd NOQMXQIgWoI6brBG/DMwFFMmgU0R8ZzHP9l4HFmdVy515LPtfUaR2aIu5lRVtTYtBdA0 50kg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20251104; t=1785921022; x=1786525822; h=in-reply-to:content-disposition:content-type: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 :content-type; bh=Gc5m4+tIBvg0egjJhph4T+RN5CfIOJByD9/EsS70PrM=; b=fVAK/cZ1d1uoPCYHbb3JGUUxOcNh4Tg/3o7uBUYelTIsT/jx6kGU6cD4ZFmFJi+FBA +NCY1xdBeFHWcbitErVWqJsMELhtRcFsH1vlEOxXENIAkRAP7nxT9/L2a1mTnoiyWMjj NH4LSgtew1Q2Sqm7q78Rz8fL/6kZu3MGoD0+zj/kkD+rYbp7ZjmI9FdtlvLmLeAkK9Cl suaROg3USn29zrlENo3qPIQepuswZeXjWu1tvHBOzfCe2ewq4qHg+gmTtlKJA1LJJJYO T5YhC1tSLwCfB2xzHi8vPgJrYvsRcgM934Vo5CYl3Oc2nZ7EpGw993qJXCAe9HR48O5n 4yyw== X-Forwarded-Encrypted: i=1; AHgh+Ro1FCXPWa3GXLZ9mc0T3kIRg5led/l5vYNUshkVoGCNFgISy7r9ktpSr6hA6mSdAgzwZcTkx5BbABYLZ7I=@vger.kernel.org X-Gm-Message-State: AOJu0Yymi7yAjmnos84zJEOTQ2YUteK2a2tXGeErqf6X1mbrcCBl86aG pDHdAxJOVamCPsAsTtxHY/yOvDUkiwI4Dbg0AivjcqfbVijDJOWgpsv/z0OJX2MAuA== X-Gm-Gg: AR+sD10WpEOJl0TlyM/+9mUBhEoN7H7UOcj28z4DO3jSl4pYvxmyW+nssEp1nBUz8hK eM7csCqWn+DZ2TgFqYtZJNvkya8PTn0WaYwLXQZc0fRTHBNJRrh8WZX1iV3+mao8VSQ1tN0GPCe o2Ygg01Gj51C4oGgemfoOCj8AxRhIyp9U6wB7k3SFJ7xbSG/Pp/LcNYpZTnjfNDJI7wG9pkulOD tVtVGHuPMM6x70slPSRyz9JnMvbPh1jymcKKphoKXYzXdCUs4EmD9jAeyhlsOuGg7FPwq/AeSzD T4DzIuCqWOVgmaCXG8O5fEXO3gvDzMRU8R9VD+8cfDj+jTJDU9dEdezI/ttWDp9V7ZFk9ljFy2w zfwH7xjNg+nho+HXQyI6tbch/7iyBNKSnXZCoJZr7xpX89AGIKHbpkkf6dmbu9g0W9DW4QuYlPt Fn3Sq6uT/lzGdGIlnU4Fv+8+viEozlVw4UzoKb/i9mp1uYG/rf++EPhOY/mE7C/BYVvpQalZPv4 g78nkvg3LFKTiC9YMNU+wwBrsw4mA== X-Received: by 2002:a05:600c:630f:b0:495:4069:b0de with SMTP id 5b1f17b1804b1-4994f123620mr696915e9.9.1785921021836; Wed, 05 Aug 2026 02:10:21 -0700 (PDT) Received: from google.com (250.192.189.35.bc.googleusercontent.com. [35.189.192.250]) by smtp.gmail.com with ESMTPSA id 5b1f17b1804b1-4994dfda45asm92632815e9.4.2026.08.05.02.10.20 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Wed, 05 Aug 2026 02:10:20 -0700 (PDT) Date: Wed, 5 Aug 2026 09:10:16 +0000 From: Mostafa Saleh To: Jason Gunthorpe Cc: "Aneesh Kumar K.V" , iommu@lists.linux.dev, linux-arm-kernel@lists.infradead.org, linux-kernel@vger.kernel.org, linux-coco@lists.linux.dev, Robin Murphy , Marek Szyprowski , Will Deacon , Marc Zyngier , Steven Price , Suzuki K Poulose , Catalin Marinas , Jiri Pirko , Petr Tesarik , Alexey Kardashevskiy , Dan Williams , Xu Yilun , linuxppc-dev@lists.ozlabs.org, linux-s390@vger.kernel.org, Madhavan Srinivasan , Michael Ellerman , Nicholas Piggin , "Christophe Leroy (CS GROUP)" , Alexander Gordeev , Gerald Schaefer , Heiko Carstens , Vasily Gorbik , Christian Borntraeger , Sven Schnelle , x86@kernel.org, Michael Kelley Subject: Re: [PATCH v8 12/23] dma: swiotlb: pass mapping attributes by reference Message-ID: References: <20260717180442.110954-1-aneesh.kumar@kernel.org> <20260717180442.110954-13-aneesh.kumar@kernel.org> <20260804142032.GC27883@nvidia.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: <20260804142032.GC27883@nvidia.com> On Tue, Aug 04, 2026 at 11:20:32AM -0300, Jason Gunthorpe wrote: > On Wed, Jul 29, 2026 at 06:12:38PM +0530, Aneesh Kumar K.V wrote: > > There is a possibility that we may support io_tlb_mem with cc_shared = > > false in the future. As a result, only swiotlb_map() knows which type of > > bounce buffer was used, making it the only place where the attributes > > can be updated correctly. > > Yeah, +1, the attribute should be changed at the same effective place > the source memory is changed away from what the DMA API user > provided. Only the thing providing the new memory (eg swiotlb) should > know its properties. I will keep the conversation here instead of 2 threads. That seems like a big leap, I'd be worried about devices that operate on confidential data that should not be shared/decrypted. One example for this which exists in pKVM (this part is not upstream yet) is non coherent devices that require bouncing but they still want to keep the data private. In that case ideally they get an encrypted SWIOTLB pool, but it's always better to fail than to use a decrypted pool behind it's back. I have not been following the work on T=1/T=0 devices, but IIRC, they required some complexity to handle their stage-2 as these modes will be emulated differently (for CCA, RMM vs untrusted host). I was thinking that it might be easier to represent those to the guest kernel as 2 separate devices (bounded to different groups...) where one is trusted and the other is not, and that way the DMA-API can have strict rules about memory sharing. Otherwise, SWIOTLB does not seem like the right place to me, as it does not understand the context the device is operating in, and the DMA-API should deduce that from the flags passed. Thanks, Mostafa > > Jason