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 B91C7405855 for ; Tue, 19 May 2026 11:06:58 +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=1779188820; cv=none; b=M0Z6NMUyfvtLLAKTtZAiWjW2MQpoXHuXAiO8/BmUJGdSYG7eKUSoYZZEdxrhq/R6cd/9aGgpc/4Qj5n/DMfKgmoQGPzn8AzhDKtFkWxlXtxUMkXA795C0yrlW2bZIBmUWyqwfv2afcVF+nE1RFXpVnlgr7cHEApKJZklI1xvXeQ= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1779188820; c=relaxed/simple; bh=bLHvC6K9JqJ0RlgA15nPRG2hHu4cpHRoKhj+9AVrCoU=; h=Date:From:To:Cc:Subject:Message-ID:References:MIME-Version: Content-Type:Content-Disposition:In-Reply-To; b=Frv8vtBM7PTUIo2G6mYXNfYx5aU1ByCkR1rrz4oumCJktICJcz+aGBHkFY1g0Myku+Y8hJlhb/FRW8G5pSvLuY2GgW3mbD/MzbPmMrc0dEV8UznnsqoIssQ4PBYgji/+bSZ3MnAEkNdaG53UT6t/a1oWrrh9h6ryBaggZubhGio= 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=oaAXiCKC; 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="oaAXiCKC" Received: by mail-wm1-f45.google.com with SMTP id 5b1f17b1804b1-48d1c670255so25e9.0 for ; Tue, 19 May 2026 04:06:58 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20251104; t=1779188817; x=1779793617; 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=gqrcVfnO7KvHz04L9yl4e6Ci0L4LjlQK4/aWUr5steg=; b=oaAXiCKCYSkRs3EK1SXjVNRdspqM6oRRzHoxbf0T20woVP0cVjiMZkh+fgSP/ut76F 1iGJbjHfVJkflGWAeC5xVR3NmrZkmNsU+cMYD6kviK91/2eHjQN2lwjlt6pG4A+piyIe kEFQ9g4pyEg6N1waV6TFOw7g9LXKP8j+tQ+9K1gxxpgSP99bmOIUr58FKTu/FQXQrEn5 DEiCmu0K96KfSte5i/8u0hjLSC0ghM01jmDpPdImBJsM1Ip8woEYl7o9sb4HR7vqFepH COKXgwfUsWkGpJ52qNUuekMnBDWTGE6qBsZgn4LEy8YHmtoJmT+gXZViWkNTk1GyYmub Trxg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20251104; t=1779188817; x=1779793617; 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=gqrcVfnO7KvHz04L9yl4e6Ci0L4LjlQK4/aWUr5steg=; b=kxSvTsOEG777mCuZit8w54YSptisqMy9kbPzbJUEo7GtG+WAdBdu+HPmW0dsDZpD/N sbY4UEiq3MATnkqyE0nzlf/U15AMEY2XOC2fd1gAnXssdE5O7OP3NYJ5Jk8UssZDacqy FjTcWoHfdJTWCuasHeYID20u5hKpjojM+Qqa4sKQu3rbBlg2a9qaYTS2pN6TysJYWyDZ Z13z9KYwi/TCrQNBjCDfk8Om1zS9ZMKw3qE2LoW5KFDXVYTGuP2q26uhyqO2kpVGNw3J gGrqrqWbAFTZbRgetPz+i97MT8imdEx6u0cZ7fskOD8Gl4QbgMXlPFTC44siupKgfcGH Ssig== X-Forwarded-Encrypted: i=1; AFNElJ8Nkvbiv0tR9OT3LBMa58zyf+kR1con5EUU1UZPgfOpehF7wU6ujeVTIR0pdvy6yXExo6e52JtkLFUE82U=@vger.kernel.org X-Gm-Message-State: AOJu0YwnrYHjV9bk/Dj8JJRq8DwA7cMjd9F7Cxc4hWd3GkUMpKTmzgH7 qYoPO0mF7YJUPf7oJv15KMAVAHzTzJoZFN30/0zh5tFTgm32PQ5IZxgZDqnoN0gI6Q== X-Gm-Gg: Acq92OF/sSbPsk7FJTREeDOCKkpjvq+Ww4a/eJbY1WjWssdCyKnE8nYlRtN9mhPfP7g M4qEq52F8vMRrX4VM3jSAaToEd/+FCxQ4uboqqXB7EAWV+v6UrjwMFkMVoaDSbahydhvmdLsVEb XNyyZe8KolSXHCtQe27GCqMue6BWevdEL01Us/EbW51ORgdcqPm+fRQt5UND5us+VWN/pk4Rmz/ OVjaQ5J3trWwJ6MgudKK1xrMDSiCpJSvOffdrx7vEAEHY0f6ujKxW4X1xnkTb6oqoyYRT1Iet5O EYXI4DA7LnvBkdTJGoYksSzGwGU0rir1D3nQBxoA6H6S+ZG3yX5sRuey6JknLydJcRSueB3u5E8 m1WJZ0AHMr0WcEJbzoBdKIyi0CkspcWwn2bfp7t734TUluLwt0AWzZvv9V33GBFpOZqt8H2GO+a pe4Mm6uAj6IEZJMCnIiDjlbDXql4Z/0ks6Hn/1XhLdL85VG7TGzcGXRY47tSWnupUFe55qsd3Ra MYWIugTTv72Tw== X-Received: by 2002:a05:600c:418b:b0:488:960f:60b8 with SMTP id 5b1f17b1804b1-48ffa5e1272mr2275185e9.6.1779188816592; Tue, 19 May 2026 04:06:56 -0700 (PDT) Received: from google.com (136.41.155.104.bc.googleusercontent.com. [104.155.41.136]) by smtp.gmail.com with ESMTPSA id 5b1f17b1804b1-48fe53767ecsm288995945e9.10.2026.05.19.04.06.55 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Tue, 19 May 2026 04:06:55 -0700 (PDT) Date: Tue, 19 May 2026 11:06:52 +0000 From: Mostafa Saleh To: Jason Gunthorpe Cc: "Aneesh Kumar K.V (Arm)" , 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 Subject: Re: [PATCH v4 04/13] dma: swiotlb: track pool encryption state and honor DMA_ATTR_CC_SHARED Message-ID: References: <20260512090408.794195-1-aneesh.kumar@kernel.org> <20260512090408.794195-5-aneesh.kumar@kernel.org> <20260513172450.GR7702@ziepe.ca> <20260514123529.GZ7702@ziepe.ca> <20260515225113.GN7702@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: <20260515225113.GN7702@ziepe.ca> On Fri, May 15, 2026 at 07:51:13PM -0300, Jason Gunthorpe wrote: > On Thu, May 14, 2026 at 02:43:39PM +0000, Mostafa Saleh wrote: > > > That's a somewhat different problem, we have the dev->trusted stuff > > > that is supposed to deal with this kind of security. We need it for > > > IOMMU based systems too, eg hot plug thunderbolt should have it. > > > > I see that it is used only for dma-iommu and for PCI devices. > > However, I think that should be a problem with other CCA solutions > > with emulated devices as they are untrusted. As I'd expect they > > would have virtio devices. > > Yes, any security solution with an out of TCB device should be using either > memory encryption so the kernel already bounces or this trusted stuff > and a force strict dma-iommu so the dma layer is careful. > > This is more policy from userspace what devices they want in or out of > their TCB. Like you make accept the device into T=1 but then still > want to keep it out of your TCB with the vIOMMU, I can see good > arguments for something like that. > > > > > While we can debate the aesthetics of the setup , this is > > > > the exisitng behaviour for Linux, which existed for years > > > > and pKVM relies on and is used extensively. > > > > And, this patch alters that long-standing logic and introduces > > > > a functional regression. > > > > > > Yeah, Aneesh needs to do something here, I'm pointing out it is > > > entirely seperate thing from the CC path we are working on which is > > > decoupling CC from reylying on force swiotlb. > > > > I am looking into converting pKVM to use the CC stuff, I replied with > > a patch to Aneesh in this thread. However, I need to do more testing > > and make sure there are not any unwanted consequences. > > Yeah, it is a nice patch and I think it will help reduce the > complexity if it aligns to CCA type stuff. > > > > In a pkvm world it should be the same, the S2 table for the SMMU will > > > control what the device can access, and if the SMMU points to a > > > "private" or "shared" page is not something the device needs to know > > > or care about. > > > > I see that's because dma-iommu chooses the attrs for iommu_map(). > > Long term the DMA API path through the dma-iommu will pass the > ATTR_CC_SHARED through to iommu_map so when the arch requires a > different IOPTE it can construct it. > > > In pKVM, dma_addr_t and IOPTE are the same for private and shared, > > so nothing differs in that case. > > Yes, so you don't have to worry. > > > We don’t expect pass-through devices to interact with shared > > memory (T=0) at the moment. > > However, I can see use cases for that, where the host and the guest > > collaborate with device passthrough and require zero copy. > > Once you add the CC patch it becomes immediately possible though > because the user can allocate a CC shared DMA HEAP and feed that all > over the place. > > > One other interesting case for device-passthrough is non-coherent > > devices which then require private pools for bouncing. > > Why does shared/private matter for bouncing? Why do you need to bounce > at all? Do cmo's not work in pkvm guests? At the moment, in iommu_dma_map_phys(), if a non coherent device tries to map an unaligned address or size it will be bounced. In pKVM, dma-iommu is used for assigned devices which operate on private memory, so bouncing that through the SWIOTLB would leak information from the guest as the SWIOTLB is decrypted. In that case, the device needs a pool which remains private. Thanks, Mostafa > > Jason