From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mail-wm1-f74.google.com (mail-wm1-f74.google.com [209.85.128.74]) (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 05496324B33 for ; Mon, 30 Mar 2026 14:51:19 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=209.85.128.74 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1774882281; cv=none; b=Q8Q2Hl4N6y5Hm4qYaJ0Uioz4ntZv0fQhSZkzyWInO4zJ5bSmBsRgF58A2QUrL5ctriHIIOnjJOigwdaNiIRViDzrjSoryriHLiLRmcyrFRZKAP1xn0Pwjcmjh56FBj+A1Oi/5L4ax5s+VlF8scVfhItdCF7bF0Fj0Pgpx8ZxHpg= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1774882281; c=relaxed/simple; bh=Ypn7VsJHNmNpvsEiDQXA8hTHZWc8FmimY/PDF1kujJ0=; h=Date:Mime-Version:Message-ID:Subject:From:To:Cc:Content-Type; b=CRgA3RCpd0byiMuFvyKqNCYDmrpr8g7FsuEOHWZIa3e9YWy1sQCQATtp0HtU9JGkH6rzeowKpfSg+fufXZMV/WhG0BvOuYMsZgoV2hgAXBC3Up0BWkhSngLgFfDBrzcMPlAA7NensH8GMh7G4odUlPT5GLCfQ22/zm+/Xwo1rVA= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dmarc=pass (p=reject dis=none) header.from=google.com; spf=pass smtp.mailfrom=flex--smostafa.bounces.google.com; dkim=pass (2048-bit key) header.d=google.com header.i=@google.com header.b=JJZY8LBx; arc=none smtp.client-ip=209.85.128.74 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=flex--smostafa.bounces.google.com Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=google.com header.i=@google.com header.b="JJZY8LBx" Received: by mail-wm1-f74.google.com with SMTP id 5b1f17b1804b1-48531e8ae62so35686395e9.3 for ; Mon, 30 Mar 2026 07:51:19 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20251104; t=1774882278; x=1775487078; darn=vger.kernel.org; h=content-transfer-encoding:cc:to:from:subject:message-id :mime-version:date:from:to:cc:subject:date:message-id:reply-to; bh=AzIiOc6BA0REXre6fSe/SWgZG5Uq5hkiPQ2+ZLc7PMw=; b=JJZY8LBxv1Ro2DLc7odva4KTSeiW+Ky20bxl8MWNr8N+2dD0CskyoJ8eOJeHqJF0CT Dl55RXD6qN4mMa7haGkx0g8eO4YCL8jROeYmzuYMLQtDOpnAWn2kW4dPU+iBBy+Vc2Ow yob4HqwS4aEZ1AbdhSdCUN/RESOzvtrvXTsAsBzlTtQ2dwug4n8lyPlD1IuV1u5WrZkw dgwZebWjD6rFFpZKk68RvJ4Qc38wpJKU5vuZVWrM6XQ1AWKE9cEai5AiJdJOS0+aFUyi RGm5zgR6jS1NR1CYMtuYus/OCqVa2d31TlAl4SpBAnL89s/2P+3akyzm0ihLKXETxeVS EdxQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20251104; t=1774882278; x=1775487078; h=content-transfer-encoding:cc:to:from:subject:message-id :mime-version:date:x-gm-message-state:from:to:cc:subject:date :message-id:reply-to; bh=AzIiOc6BA0REXre6fSe/SWgZG5Uq5hkiPQ2+ZLc7PMw=; b=VMdwcnYR21W6nIKVBy+Pczep9SRhnwLJ+vrQ+TfCb6dZjWtCT56+QiF+2AMRNf5saO 9ZPaUgSZiMtOL5QD05ekR1RIFrizZU05LN57Xb4u5dNQyV27Y5iE4ny75KqVL7IjUrnk r21Ltbnc5hyfW0D845Ejw/2NUuY5vlXhkQZAV8X+JzYel32odz2pCi4x7X2J3jQcodTM qPc0G/hfhMh1cyCSIvNi/Jk+sryAJC2LbWjmduYsShN1Uc7gawIVxkGe3lFrPkPRzvdw O9fy4Z5rw5uPzGm8Z+okMnQtuKB8y4G92CBIEjc2Nh84YnreGLHgkabwq3o5+1mmnYPY NyNQ== X-Forwarded-Encrypted: i=1; AJvYcCU8jr+2giygRscHNU+2cMAXC4+QIGxTieFsw2tL0TvbJkYBukxxtSwM/NwZXHZxBZ7SP43FMDspPs842gA=@vger.kernel.org X-Gm-Message-State: AOJu0YxE0Ir2tjp9E78JFa3YkXMcQRY5hWehGP3dw0VVPMpT8p9BLEEH ttYY6Ly4zighjUw3ObkyLWWltgBy8x3/arzd8103GELTDrDXBTcY62EaHUSZuzsfBPtqIRsQq2F MzgLFngipwOcIww== X-Received: from wmmu1.prod.google.com ([2002:a05:600c:c1:b0:483:7a98:f072]) (user=smostafa job=prod-delivery.src-stubby-dispatcher) by 2002:a05:600c:a00b:b0:485:34b3:8587 with SMTP id 5b1f17b1804b1-48727d8ffc5mr222050275e9.10.1774882278308; Mon, 30 Mar 2026 07:51:18 -0700 (PDT) Date: Mon, 30 Mar 2026 14:50:38 +0000 Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: Mime-Version: 1.0 X-Mailer: git-send-email 2.53.0.1185.g05d4b7b318-goog Message-ID: <20260330145043.1586623-1-smostafa@google.com> Subject: [RFC PATCH v2 0/5] dma-mapping: Fixes for memory encryption From: Mostafa Saleh To: iommu@lists.linux.dev, linux-kernel@vger.kernel.org Cc: 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, jgg@ziepe.ca, aneesh.kumar@kernel.org, Mostafa Saleh Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Introduction =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D This is the second version of the fixes for direct-dma dealing with memory encryption and restricted-dma. In this version, one more fix is included and I go a step further and attempt to clean up the code to consolidate it and make it less error prone. Especially with more users coming, such as using decrypted dma-bufs [1] which also interacts with dma-direct. Lastly I added a new documentation for memory encryption based on my conclusion (Documentation/core-api/dma-direct-memory-encryption.rst) Background =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D At the moment the following hypervisor guests will need to deal with memory encryption: - pKVM (ARM): Documentation/virt/kvm/arm/hypercalls.rst - ARM CCA: Documentation/arch/arm64/arm-cca.rst - Intel TDX: Documentation/arch/x86/tdx.rst - AMD SEV: Documentation/arch/x86/amd-memory-encryption.rst - PPC SVM: Documentation/arch/powerpc/ultravisor.rst - Hyper-V: Documentation/virt/hyperv/coco.rst AFAICT, all (confidential) guests running under those have the memory encrypted by default and guests will then explicitly share the memory back if needed. The main use cases for decrypting(sharing) memory are: - Sharing memory back to the host through SWIOTLB (for virtio...) - Hypervisor specific communication (ex: snp_msg, GHCB, VMBUS...) - Shared/emulated resources: VGARAM (x86-SEV), GIC ITS tables (arm64) While encrypting memory is typically used for reverting the set_memory_decrypted() either in error handling or in freeing shared resources back to the kernel. Design =3D=3D=3D=3D=3D=3D 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. Instead of open coding many checks with is_swiotlb_for_alloc() and force_dma_unencrypted() which doesn=E2=80=99t have the same exact semantics= , add some helpers to abstract that logic into the code: * dma_external_decryption(dev): Returns true if the pages are decrypted but managed externally. * dma_owns_decryption(dev): Returns true if the pages need to be explicitly decrypted and managed by the `dma-direct` layer (as the architecture forces unencrypted DMA). * is_dma_decrypted(dev): Returns true if the memory being used is in a decrypted state, regardless of who manages it. Testing =3D=3D=3D=3D=3D=3D=3D I was able to test this only under pKVM (arm64) as I have no access to other systems. Future work =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D Two other things I am also looking at which are related to restricted DMA pools, so they should be a different series. 1) Private pools: Currently all restricted DMA pools are decrypted (shared) by default. Having private pools would be useful for device assignment when bouncing is needed (as for non-coherent devices) 2) Optimizations for memory sharing. In some cases, allocations from restricted dma-pools are page aligned. For CoCo cases, that means that it will be cheaper to share memory in-place instead of bouncing. Both of these add new semantics which need to be done carefully to avoid regressions, and might be a good candidate for a topic in the next LPC. Patches =3D=3D=3D=3D=3D=3D=3D - 1-3 Fixes - 4 Refactoring - 5 Documentation v1: https://lore.kernel.org/all/20260305170335.963568-1-smostafa@google.com= / [1] https://lore.kernel.org/all/20260305123641.164164-1-jiri@resnulli.us/ Mostafa Saleh (5): dma-mapping: Avoid double decrypting with DMA_RESTRICTED_POOL dma-mapping: Use the correct phys_to_dma() for DMA_RESTRICTED_POOL dma-mapping: Decrypt memory on remap dma-mapping: Refactor memory encryption usage dma-mapping: Add doc for memory encryption .../core-api/dma-direct-memory-encryption.rst | 77 +++++++++++++++++++ kernel/dma/direct.c | 51 ++++++++---- 2 files changed, 114 insertions(+), 14 deletions(-) create mode 100644 Documentation/core-api/dma-direct-memory-encryption.rst --=20 2.53.0.1185.g05d4b7b318-goog