From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mail-wm1-f44.google.com (mail-wm1-f44.google.com [209.85.128.44]) (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 C842F1E2834 for ; Mon, 11 May 2026 11:13:50 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=209.85.128.44 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1778498032; cv=none; b=izU65nY9O31yRhKrEebkXpbl/Mvq5yeWZZc9QDJ3u905Fm74g48Z/LAqTc6iYK6LXmh8b/KJtlJaWVKXji1azmv4iaP3TWI8IBEI7TuUdgqYmveq6FNRibMGeHWreemG0JDoaeMGYouznYaSJ69+XeUFPrb6CZBQ/8sKmUb8YYY= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1778498032; c=relaxed/simple; bh=XxgqOVAvsBiqccnVAD240XyEMuriRVfTF0T3UfzRmEc=; h=Date:From:To:Cc:Subject:Message-ID:References:MIME-Version: Content-Type:Content-Disposition:In-Reply-To; b=sq8jGkLGzmg5ew+1plwLhq2GlflxavSP5LJYAgajrHYrVejUCUWJjo5sTCC/IrDQgQPZmCghNe8U+cgrjwo0DbRXiKNbDwP0OXb4buevzFMVTGNwD+J3rIitfOoopHECtje7CEPhd09XK0bGzR3Af8tOekAsndY2ScFWbwO6jA4= 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=HCSCPZo4; arc=none smtp.client-ip=209.85.128.44 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="HCSCPZo4" Received: by mail-wm1-f44.google.com with SMTP id 5b1f17b1804b1-4891b4934ffso295e9.0 for ; Mon, 11 May 2026 04:13:50 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20251104; t=1778498029; x=1779102829; 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=OdpkiWeL2t8R+EHDk3fbd7ThTtXnMvXGE12dkE0RMC4=; b=HCSCPZo4ZftGVAr48smKsDbShXzBPQL4xzRLEHIgW60HBsNOdRc2rpO5WtCa7lrlCE v7B9Scq/p2kCJDipoaQMVYrUDvf1npIu/C7z52DWnUBCvHRYstEHPv2zl8kJhXmlUNwi 19nOrjTF6TPLWCQ6iCe3hv0dyuU3a4NyGSaZS6HCjFoPiqtDCEAP1ZlZTKHgFqhQ5Odm CvBZM3wIBCT9oKUjfrq4QEdXjU+RaUnc+PQaPokyD1WE6onouogI6ek95SBCbYj0PCpn JWCZA8f3MrOr5uqQ9KXE+YB+dCzTmzonBkFHpOdduiDX1syH4hK8y1wq/3bjXPPq96Kj i8wA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20251104; t=1778498029; x=1779102829; 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=OdpkiWeL2t8R+EHDk3fbd7ThTtXnMvXGE12dkE0RMC4=; b=jcslfkKVYvrANUA7+hpBJvyaavd1tEkxY5nrxzELE0X8mom7Z1DYVQaWJ4YkMgABAK p8CsfvbkVGAY6nrsJa9fX+etJl2FxKZFaJsuHntc3/PguMHb8zWYfwn9aHDxvxiUfUWr qeyv6QRfKV9qK1+i4DcCmYfr9AkLschuKGzlNN70BxgWKScuHI4+mGn5JNPEfeTPbvMz 52HzPyasbhYRtop3pWqwYbqYP9pWXUuOAxbvdDLNivuUaRs4pP1s0ZYInDt2wrPDzHim zhjVE6xJpT3zN6AWVvdTaNd9fyHqTsMUc2IBCOZb/xnjnSwEIr0non/3rBXkUnszJqdQ C7eQ== X-Forwarded-Encrypted: i=1; AFNElJ8ENvHBGgq1qOR88m7dlnuqBShAGBOrCHGGiqMjPWNqcluKMdX9RDuRGX1dUht5QD8+AqHSTceiYQT2/V8=@vger.kernel.org X-Gm-Message-State: AOJu0YxxjHRiUnII83vdvJPod5hJ43w2lLYFZQmajMN5x/H/G8FuyS5Q /3YXpPUFtjkxV9QvqMWLFi23uJ/Hp2REbu+/STJqZ+hCC8PNQ+QrYHVfgV2S48tXkcpIjOdobKK NqGgUsg== X-Gm-Gg: Acq92OFZIUGIdoSx4+98xKafSDOJ698hVH3LyJthaKnQhkE+8aLx5JAoBMEcMf0kyPn Hv79QRj+nQ6CBAfYKRpUQPnM/OiSOmVjFG0PjEoncAroLGbDbEmXapCroPRSf8gzJScSZiMy0ZG 1bDVSwSj6VHdMVJzG1O2Qz1tfzsdDCkfqWVISFcKjo1MZ66XkJQ0IdXzV/xq5V+nKtEwfAGM1HK DNTF2CdxrJB783dSWbRA5UirslawjGb++irQ3eqqBp9X35CrFPmN9RKbzhJmuY7TZJRxWqnB/Ri d/nSyE9t+d9N3H7Q26ziQCO2RjDGXY1FyDEItg0tcxLkONOn89DRqQtAj2tQ4rL4d4MSYImmme0 VlEcft+Lowg4COW+UvGfxdUqQEVTzv+ijQlWdLqx8dxPBnMF2GWiNRxWnJOBCU86CnrifiRU+aF q0f2qpcbsCWYW5DYGfwdoQB2uMLnZOggd3jd/WvWtSBESeoZK6MZY/RkUrwaBId0cZg7c= X-Received: by 2002:a05:600c:a11c:b0:47d:1e65:e841 with SMTP id 5b1f17b1804b1-48e6f504706mr1661475e9.9.1778498028611; Mon, 11 May 2026 04:13:48 -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-48e6db1413csm61259705e9.29.2026.05.11.04.13.47 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Mon, 11 May 2026 04:13:47 -0700 (PDT) Date: Mon, 11 May 2026 11:13:43 +0000 From: Mostafa Saleh To: Catalin Marinas Cc: "Aneesh Kumar K.V (Arm)" , iommu@lists.linux.dev, linux-kernel@vger.kernel.org, Robin Murphy , Marek Szyprowski , Will Deacon , Marc Zyngier , Steven Price , Suzuki K Poulose , Jiri Pirko , Jason Gunthorpe , Petr Tesarik , Alexey Kardashevskiy , Dan Williams , Xu Yilun Subject: Re: [PATCH v3 0/9] dma-mapping: Use DMA_ATTR_CC_SHARED through direct, pool and swiotlb paths Message-ID: References: <20260427055509.898190-1-aneesh.kumar@kernel.org> 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 Fri, May 08, 2026 at 06:28:11PM +0100, Catalin Marinas wrote: > On Mon, Apr 27, 2026 at 11:25:00AM +0530, Aneesh Kumar K.V (Arm) wrote: > > This series propagates DMA_ATTR_CC_SHARED through the dma-direct, > > dma-pool, and swiotlb paths so that encrypted and decrypted DMA buffers > > are handled consistently. > > I think this series makes sense, using DMA_ATTR_CC_SHARED throughout the > DMA API, either for alloc or for streaming to decide/check what bouncing > does. Sashiko has a few interesting reports, it probably breaks s390 as > well (it might be similar to the pKVM case). I have this series on my review list, I believe there is an overlap with my series, I can rebase mine on top of this if that makes sense, I will probably wait for a new version to address the current comments and Sashiko notes. Thanks, Mostafa > > I don't think it addresses earlier Mostafa's issues with pKVM, although > I'd rather base additional pKVM related fixes on top of this series. > With pKVM, cc_platform_has(CC_ATTR_MEM_ENCRYPT) returns false, as does > force_dma_unencrypted(). I think we should update protected guests to > return true for these if they need shared buffers (the whole > decrypted/shared terminology is messy but in most places it just means > buffer not private to the protected guest, whether encryption is > available or not). > > That said, does CC_ATTR_GUEST_MEM_ENCRYPT actually make more sense than > CC_ATTR_MEM_ENCRYPT throughout this series? We'd need to change arm64 > realms as well to use this one. > > -- > Catalin