From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mail-wm1-f53.google.com (mail-wm1-f53.google.com [209.85.128.53]) (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 849D83822AC for ; Wed, 15 Apr 2026 20:26:01 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=209.85.128.53 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1776284763; cv=none; b=vEPbNKCrRBqGIJOp0vnVO3sO4nFiKFeQ0dzlTCK6nxSBeOe5Ufuks77sKp7q1B/EK18i1N8pchDxThb4eO8zt2TFjmO2jKiPf52hdmTl7W+G9FX/jKoXkrkhb7EHyCN+tT5T8ZcFG0FuiVb5VKm96MtVvDGOQXx3vJJNU5dMYjM= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1776284763; c=relaxed/simple; bh=D1SqgEwszCSlMw2AO/UNhnFUs69EEmK/QjpAWkmWeio=; h=Date:From:To:Cc:Subject:Message-ID:References:MIME-Version: Content-Type:Content-Disposition:In-Reply-To; b=NY0YsnSBBcQv83zi/8CqLsR5CEAXEz+GluAWn1rDWHzWwp396xBgwZyIoGtujHmru3EX9lGHDFasrLGuZJTbcWDnhJ/eCIUoOQCDo4W4fO96gGLb8M7maBcloBioTS9HEwScr5RyiZ8jMa23gY8PrMR0zQXs1pO6/drVd6yDXLc= 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=h9GMcrVe; arc=none smtp.client-ip=209.85.128.53 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="h9GMcrVe" Received: by mail-wm1-f53.google.com with SMTP id 5b1f17b1804b1-488940ccfa6so22645e9.1 for ; Wed, 15 Apr 2026 13:26:01 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20251104; t=1776284760; x=1776889560; 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=0AjMVKAHSpj8KfkpLbd1zkxWe8CEnOGcRvItgWy4AaQ=; b=h9GMcrVe6uOzZmeBDT+xSjmB7MTxT4e6pqwHkHKQY+5dIHQHblxb6h6Jq9RQzDCBtX KmPg/vuZYQwSpUfazb5czHGP6ecA0aFd/Tc3tXI/pLABZbVTQhkw2ZgreZbOnCeFDage 1kOOxnFxFKSzqS0SqsmkeeKChVMSwR8/TJT+tORQ6jKc3IXUOjaT2Im0ht1pb92vushb 1eILm7Uuyob0PwWh5A5AhUAYtln7Kr06AUBW6h95WTBLTJuNs5VD6XMNqwDdczPr+x7A cBbMI7npce+kO7w3YlMUx423Dk5g0EoO+qPgRjB2M8QXZGE8KX6pLreZhkJQU0j4jjBB BUNw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20251104; t=1776284760; x=1776889560; 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=0AjMVKAHSpj8KfkpLbd1zkxWe8CEnOGcRvItgWy4AaQ=; b=OrbODYR8t3n47o5VYoMPmIXmCdv4k6EvvJjvoA9QyYmVjjdrdYnYxJjV2eWNDMLkGd 5EI02rSAUkMEDp4NU7I/fMa9SWeg68Uh/SLRq416nVK69auzkb8ACL5QLxU3XCKro7vq ykyAQ8KJd6F1kBy5uVn7xv+V9tji5wZnX7yTwqjsVmPvLtlBGdOnlvPxTPuYn1Me3C6n 8++wfxJZ25i6Ka/TCS0e4PIZTqptOV4SHeVAsDU/PpRZ+ahfNW84EF+t5pyn0z1+zcWB KrZ4GUEffTT9bqQQ7YE3uwdLCk5vvK15U1FpwTOjjO3IVt9lYuDbs1UANue5a7xfo0e9 +SaA== X-Forwarded-Encrypted: i=1; AFNElJ/DsNUAfeci1wt4ovjSF5oWjHQUk5deYkR2gBIt90HEqlBpW7LUA3d5xTfAZfw7366aA87IZWxKrDQfvvM=@vger.kernel.org X-Gm-Message-State: AOJu0Yz1EcYCXkdWsKvfifkaPyE8/bEhVdl4b5R4u3f7EDnX87M6WJLo 10X6qz0XqiBwmrtMQK+4+0/8SIy8Qjxsti72M7KPSmyNd1lKbUFfhVN/VKNdU+4sxg== X-Gm-Gg: AeBDiesVB3b04ZufcnjbNR97BdjG/8dhvC92IAiAxuUJeYERO/KtphJ1EgBwM+V/xHh WTXp2h6zJux5WYvEDWzxff+hLvEGrY4Ngu83U+obIteL0mobbU/vOJCxk7iytsrecbq+3gTXzvc 4ccEBnLH8X2G8N/RaXbMjUD4e+ZXhS02qbfaKkmwiMGYKV8vyT4kbtcTMa76Px73iEDczHcFCNc W9l9hdzhn6ACiAaCS6KCbw37bMneJvfHhDEY4t/HUXPxG4vWtQP+pJffTcwt7Sc/QGkVm54vLcZ JjcEYlsuc81lvHFf9EYkhF6/bItwrUwINpcc5moM7WsWcUYfasKaVYwABx+vh1//IpGKwFiOInX yk42FneJjjL5hLZupEMaUqby96aHtFnhDsAFHvTK1jAImr1B5rjjMOOhXmbUjOtotuLMsvbRSkz L1wTXXFg1dZUyyXxDLE84UXb5IYM2oKKWu1W6MuD2sUmjfl2FwSfoOvCT8ywIVaGasofnQaDwWB 4f1fQ== X-Received: by 2002:a05:600d:8445:20b0:485:32b7:5b87 with SMTP id 5b1f17b1804b1-488f4aaae31mr150215e9.14.1776284759504; Wed, 15 Apr 2026 13:25:59 -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-488f208572bsm73115645e9.15.2026.04.15.13.25.58 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Wed, 15 Apr 2026 13:25:58 -0700 (PDT) Date: Wed, 15 Apr 2026 20:25:54 +0000 From: Mostafa Saleh To: Jason Gunthorpe 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, aneesh.kumar@kernel.org Subject: Re: [RFC PATCH v3 0/5] dma-mapping: Fixes for memory encryption Message-ID: References: <20260408194750.2280873-1-smostafa@google.com> <20260410174338.GC2551565@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: <20260410174338.GC2551565@ziepe.ca> On Fri, Apr 10, 2026 at 02:43:38PM -0300, Jason Gunthorpe wrote: > On Wed, Apr 08, 2026 at 07:47:37PM +0000, Mostafa Saleh wrote: > > Introduction > > ============ > > This is the third version of the fixes for direct-dma dealing with > > memory encryption and restricted-dma. > > > > Changes in v3: > > - Instead of extending the logic by using is_swiotlb_for_alloc(), > > follow Jason’s suggestion and propagate the state of the memory > > allocated. > > - Remove checks out of dma_set_*() based on Jason suggestion > > - Remove documentation for now until we are close to the final > > proposal and add it later if needed. > > There are a number of Sashiko remarks that look plausible that should > be investigated: > https://sashiko.dev/#/patchset/20260408194750.2280873-1-smostafa%40google.com I think the remap and NULL points are valid, I will address them. The case of dma_coherent_ok() is more tricky, it is not a regression, but I think it’s still a theoretical problem for some CCA solutions where encrypted/decrypted memory have different DMA aliases. It’s not easy to fix it without having some helper to check the memory state as force_dma_unencrypted and swiotlb_is_decrypted() which kind of defeat the purpose of returning the memory state from swiotlb_alloc() :// > > > Design > > ====== > > This series focuses mainly on dma-direct interaction with memory > > encryption which is the complicated case. > > At the moment memory encryption and dma-direct interacts in 2 ways: > > 1) force_dma_direct(): if true, memory will be decrypted by default > > on allocation. > > 2) Restricted DMA: where memory is pre-decrypted and managed by > > SWIOTLB. > > > > With a third possible usage on the way [1] where the DMA-API allows > > an attr for decrypted memory. > > This [1] was merged now I see, I will rebase on top of it and send v4. Thanks, Mostafa > > Jason