From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mail-qt1-f181.google.com (mail-qt1-f181.google.com [209.85.160.181]) (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 9EF403E63A4 for ; Thu, 11 Jun 2026 11:30:41 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=209.85.160.181 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1781177443; cv=none; b=KExhWs36rXHVIDIIMpnWl76ZcEQr7BvPx7dCAOBU3YsRmORdpRsbk4ilpCYfW14J70SSoIpk0kSMmjC4jj5yt93JN4A9rMXXIRE/kbQzqooLtISJqkl9XHVbC/S4wkOH73+5S63lgpJX8P/ckxefi4M92gZGHMQa/32cECGZpm0= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1781177443; c=relaxed/simple; bh=haH/H6OcYua3Z5rTl0sktjLmKVSLqKAqacU21OYuo/8=; h=Date:From:To:Cc:Subject:Message-ID:References:MIME-Version: Content-Type:Content-Disposition:In-Reply-To; b=UL1tpIU9jcTk4zpPPRBG/3Ym/Z2FZis0HCYvUtS4b+wxIlDQhIb20uQqAi+McZzBUnbtDiIkrBhj06SojhgYriU1sNbVlVpHH9vui0H4a5GwhLF2hvAKVau4IDvOnXx6Z0uCaNiZss2Rlor3siJTKNAI6H/DNjTBcU1ac+EdYPc= 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=MyNabGlA; arc=none smtp.client-ip=209.85.160.181 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="MyNabGlA" Received: by mail-qt1-f181.google.com with SMTP id d75a77b69052e-517583cb07aso84172741cf.2 for ; Thu, 11 Jun 2026 04:30:41 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ziepe.ca; s=google; t=1781177440; x=1781782240; 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=haH/H6OcYua3Z5rTl0sktjLmKVSLqKAqacU21OYuo/8=; b=MyNabGlAZBcmJYXJm+nAthqbBxFK6Vr+8+tJWxPzF7PoTmW0QHIxbwoM+iChDFjqTy tQgX1Mo0svelEyIyWY61MW3De3muxYFDkLELZG3VvqRARTsBAc8YN4xxsYwYbJwug5KU 1pm+yJ5BDM2QCwIIg4CIXnaOubGbg6rvb1u3E2tLT3JmjTi3jzZ/F9nFAUBSmvCHudG+ NsTyWrHFyFnHYEivUjsJnHUa9XOG9+M7ILUula6wVX2VkJi+BIVuVli13a3Ij+ffg0Cn 7i1WFoUXhu164H9n2V2/3L4CAAJXtE7YD7NOINm2X9T12wmyiTTbfk/7/tadVpYGSaR0 e7qg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20251104; t=1781177440; x=1781782240; 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=haH/H6OcYua3Z5rTl0sktjLmKVSLqKAqacU21OYuo/8=; b=QuY+dKxQw0tk4JIxCzUOvwg31TsFgGLpkdrDb36WmBmkWQj2gGba++2QrJsGWKvt6G JsLj6UmXnzdQqSXQwa+AKW85ilPHl/tFLxkPcgCbUiAzz8+NsR+1Z7R/1Y/OyQ686BRt rVEZNztvUbDrA6de6nyxWvTnd/MzpraDfj4SNtv0ViBclrT3fexHbCTADeyT5XOvggWS 54RZ32XUovG4433QAuAUOwgCtEBmGY2iJTXY1qs26Yk6MmkI6l+E7BkjN3MNbU/xT0tN GVHtJgPse27wvkSKLsi+IcTic5BBgNio9tj7BZC2mQG3RzLO79wRFGw4RO6/qR+UjKHU fXng== X-Forwarded-Encrypted: i=1; AFNElJ8TvpRrrRDei8HmKcl1fGg1aHMRPAgZ/oV4X6w+x0CBwtpF5VwSYsRpG7MISPVIB6azNYRveUxLookUVDA=@vger.kernel.org X-Gm-Message-State: AOJu0YzAcxVkOWz4jhekV5b3ZI2HIb51B4ZaXfQzFAuetVuFnlWBa1Vh /8pUKMKbfEKioXVkWyXjIVa/Rb5Bgx9Qnd3wmknbscv1nhKDLj2pJtsAFnDrKc2mnRg= X-Gm-Gg: Acq92OGz018hNuX02YjuJXnpqOTqE7TEHUua6tVENN+vr9mwrECfN+jrhEOSvKUH/92 r4lqNHSdQgJcwACfczCHUW9roFAXLUQ+fvyygMsr/El+uKud9dqXtkmTcb/uXWufUw+FkytECfR szcN+l/eIs/pHgSvPf8ogEDGPkA/3KPQwOnf/bDh4XlGNIw2wpsmQaGdaJSf5R3bUNaPJByYY2q eB0Mv3mtQDD+2p5cnd+PXbfK/cMmNVx7w7jMCaGCKtp+Wi4Sd1q1+wxD7IJ1jdrhk8+Qi8KjyOe pL9jlyNzj7fjvrt2qQMQdb3n+le2Mujtaj/X0tH0NvjyfLlYzkEfvMfLEwhXja2lVC+1VyIVOs5 0Tadak2xRD2mdhgg87jmOvjxhffjsyhkK70vsuyfeOAHYK3Vpm/yJfLnTDuQqA7R6YTjTpWLJz8 2GZoAIJm3o0c6Eiow6NULqiUr4QaYNqxPaXMRmxLZ/IXw3FAHPbFx+hRgIFy2IqBQE3xubRouE+ hFHgDwzexhjg8rV X-Received: by 2002:a05:622a:354:b0:517:875a:d619 with SMTP id d75a77b69052e-517ede4125cmr35159281cf.6.1781177440327; Thu, 11 Jun 2026 04:30:40 -0700 (PDT) Received: from ziepe.ca (crbknf0213w-47-54-130-67.pppoe-dynamic.high-speed.nl.bellaliant.net. [47.54.130.67]) by smtp.gmail.com with ESMTPSA id d75a77b69052e-517ef61dfeasm14521801cf.24.2026.06.11.04.30.38 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Thu, 11 Jun 2026 04:30:39 -0700 (PDT) Received: from jgg by wakko with local (Exim 4.97) (envelope-from ) id 1wXdcM-00000005deq-1WZO; Thu, 11 Jun 2026 08:30:38 -0300 Date: Thu, 11 Jun 2026 08:30:38 -0300 From: Jason Gunthorpe To: "Aneesh Kumar K.V" Cc: 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 , Mostafa Saleh , 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, Jiri Pirko , Michael Kelley Subject: Re: [PATCH v6 04/20] dma-pool: track decrypted atomic pools and select them via attrs Message-ID: <20260611113038.GA1066031@ziepe.ca> References: <20260604083959.1265923-1-aneesh.kumar@kernel.org> <20260604083959.1265923-5-aneesh.kumar@kernel.org> <20260609143242.GK2764304@ziepe.ca> <20260610164153.GQ2764304@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=us-ascii Content-Disposition: inline In-Reply-To: On Thu, Jun 11, 2026 at 10:21:50AM +0530, Aneesh Kumar K.V wrote: > If we are adding DMA_ATTR_ALLOC_SHARED, should we also allow > dma_alloc_attrs() to take that attribute value? I don't think we should.. It is hard to see any reason to allocate shared memory through the DMA API. The way the DMA API works only the device that it is allocated for can access that memory, so it is effectively private to the device. Thus what purpose is shared device private memory? > +DMA_ATTR_CC_SHARED > +------------------ > + > +This attribute indicates that a DMA mapping is shared, or decrypted, for > +confidential computing guests. For normal system memory, the caller must > +already have marked the memory decrypted with set_memory_decrypted(). CPU > +PTEs for the mapping must use pgprot_decrypted(), and the same shared > +semantic may be passed to a vIOMMU when it sets up the IOPTE. > + > +This attribute describes an existing mapping. It does not allocate shared > +backing pages and must not be passed to dma_alloc_attrs(). For MMIO, use > +this together with DMA_ATTR_MMIO to indicate shared MMIO. Unless > +DMA_ATTR_MMIO is provided, the mapping requires a struct page. Yes, though we need to fix a few ATTR_MMIO users to make this statement true > +DMA_ATTR_ALLOC_CC_SHARED > +------------------------ > + > +This attribute indicates that a dma_alloc_attrs() allocation must use > +shared, or decrypted, backing pages for confidential computing guests. > +Allocation paths use this request when they select shared DMA pools, > +decrypt newly allocated pages or restore encryption on free. > + > +DMA_ATTR_ALLOC_CC_SHARED differs from DMA_ATTR_CC_SHARED in that it > +requests shared backing memory from the allocation path. DMA_ATTR_CC_SHARED > +describes an already-shared mapping and requires the caller to have > +prepared normal system memory before mapping it. Callers that need shared > +memory from dma_alloc_attrs() should request DMA_ATTR_ALLOC_CC_SHARED > +instead of DMA_ATTR_CC_SHARED. The semantic is right, but I would make it a private attribute since no driver should use it. Jason