From nobody Tue Jun 30 13:56:18 2026 Received: from mgamail.intel.com (mgamail.intel.com [198.175.65.19]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id F1D4E288BA for ; Thu, 25 Jun 2026 01:25:54 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=198.175.65.19 ARC-Seal: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1782350756; cv=none; b=AANJZ2dH1Z8YQjFqYqc6zeA1UdhVTloECkZTG+IbIctrNCcbpnxhDrUAyMR7h9xEPLGAxfIBFQhQx/XXBnC20nyNoOokUU8M9lzRtlMlAtt6LMggAS0QUl//kaRQZz4hlfdEaViUPQ9FHX98S6/RzIvuaP95M3Kn5rYQosw32EE= ARC-Message-Signature: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1782350756; c=relaxed/simple; bh=B+09gNSlX63iLwE/AGE05KxkGH0pJ4GiWtfP9h+zUaE=; h=From:To:Cc:Subject:Date:Message-Id:MIME-Version; b=H+QLFMyDSls349S70WeQRCuONtQHxkI4wxvg8frnpR3luf8UmsH8BBTKxTv20e6hcxUANRrabT0n/cDvm6LaIuM/xqfIl4ThSd4DvsNdkWXU1wpp7z/Ww80Xagq9QouYAlYkSnwvNjqx4xMQ4yol9yj4rlrf95jPALbdWbgZatE= ARC-Authentication-Results: i=1; smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=intel.com; spf=pass smtp.mailfrom=intel.com; dkim=pass (2048-bit key) header.d=intel.com header.i=@intel.com header.b=UQEL0jx2; arc=none smtp.client-ip=198.175.65.19 Authentication-Results: smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=intel.com Authentication-Results: smtp.subspace.kernel.org; spf=pass smtp.mailfrom=intel.com Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=intel.com header.i=@intel.com header.b="UQEL0jx2" DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=intel.com; i=@intel.com; q=dns/txt; s=Intel; t=1782350755; x=1813886755; h=from:to:cc:subject:date:message-id:mime-version: content-transfer-encoding; bh=B+09gNSlX63iLwE/AGE05KxkGH0pJ4GiWtfP9h+zUaE=; b=UQEL0jx2g/rOAxIMZRy2OPnzsKv+q2mxsiCIW/tQlQLW86s+6ziYdz+R SqHYNvGDxGrl+uP6qAPGaGfT6OEO3CPUsnJGNvmwbneoM40ZtboO2qMgf 0y0i8vUwGVjuwaNi56MdJ811qEovI1n5AAcfY+9PyGYki+xmMZISeJhJK qhws2ENBZPWxXZ9DkqUqv/H8UsGTxAjXL0aBHxjsBc7T+UsiHI3ghBn/w dcOQnje9B5xrQo/srKywNnQKYVbROdJpB3oL2RAI2dV4+L6tz8IjoBArV AdJ1HeL+MGzkYPV7LQbHOEEHnmMs032QE2ygEGnsyKA7dSReeFbDk30NP w==; X-CSE-ConnectionGUID: +0H1w4TmSt+YsGqcCj2NHg== X-CSE-MsgGUID: KwmP0ZtERO+t+Y9FN2vcZg== X-IronPort-AV: E=McAfee;i="6800,10657,11827"; a="83127255" X-IronPort-AV: E=Sophos;i="6.24,223,1774335600"; d="scan'208";a="83127255" Received: from orviesa001.jf.intel.com ([10.64.159.141]) by orvoesa111.jf.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 24 Jun 2026 18:25:54 -0700 X-CSE-ConnectionGUID: 9kGAYiv2TLukzEoTWblZwQ== X-CSE-MsgGUID: itIV3vcmTXyIDlm0SdrR7g== X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="6.24,223,1774335600"; d="scan'208";a="288309427" Received: from ubuntu.bj.intel.com ([10.238.152.72]) by orviesa001.jf.intel.com with ESMTP; 24 Jun 2026 18:25:51 -0700 From: Jun Miao To: bp@alien8.de, tglx@kernel.org, mingo@redhat.com, dave.hansen@linux.intel.com, m.szyprowski@samsung.com, robin.murphy@arm.com, rick.p.edgecombe@intel.com Cc: x86@kernel.org, linux-kernel@vger.kernel.org, aakarsh.jain@oss.qualcomm.com, michael.roth@amd.com, fan.du@intel.com, jun.miao@intel.com Subject: [PATCH v4] x86/pci-dma: add a SWIOTLB_ANY flag to lift the low mem limitation Date: Thu, 25 Jun 2026 09:26:16 +0800 Message-Id: <20260625012616.2992535-1-jun.miao@intel.com> X-Mailer: git-send-email 2.32.0 Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="utf-8" When high-speed NICs or multi-GPU setups are passed through into confidenti= al VMs, the SWIOTLB bounce buffer becomes the critical path between private and shared memory. Restricting it to low memory limits throughput and fails to scale for larger workloads. AMD SEV-SNP and Intel TDX guests run in a TEE where the hypervisor is untru= sted. DMA-capable devices require bounce buffers to mediate between encrypted pri= vate memory and unencrypted shared memory. Confining these buffers to low memory= (<4GB) unnecessarily caps their size and degrades performance. Power SVM already supports this; x86 does not. See commit 8ba2ed1be9 ("swiotlb: add a SWIOTLB_ANY flag to lift the low memory restriction"). [ aakarsh: completely trim down/rewrite changelog ] Tested-by: Aakarsh Jain Suggested-by: Borislav Petkov Acked-by: Marek Szyprowski Reviewed-by: Aakarsh Jain Signed-off-by: Jun Miao --- v1 -> v2: - Updated commit message and description. - Add Reviewed and Tested. V1 Latest Feedback : https://lists.openwall.net/linux-kernel/2026/02/11/483 v2 -> v3: - We can alloc 4GB with the dynamic swiotlb, rather than 1GB. 1G is not correct. So change the commit log. v3 -> v4: - Not only TDX-specific but all encrypted guests include SEV. - SEV-SNP guest passed the test with the help of Aakarsh. Tested-by: Aakarsh Jain - Add "Acked-by: Marek Szyprowski" - Explain the usage case in the commit log following Boris`s suggestion. --- arch/x86/kernel/pci-dma.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/arch/x86/kernel/pci-dma.c b/arch/x86/kernel/pci-dma.c index 6267363e0189..73b9320c4a7d 100644 --- a/arch/x86/kernel/pci-dma.c +++ b/arch/x86/kernel/pci-dma.c @@ -61,7 +61,7 @@ static void __init pci_swiotlb_detect(void) */ if (cc_platform_has(CC_ATTR_GUEST_MEM_ENCRYPT)) { x86_swiotlb_enable =3D true; - x86_swiotlb_flags |=3D SWIOTLB_FORCE; + x86_swiotlb_flags |=3D SWIOTLB_ANY | SWIOTLB_FORCE; } } #else --=20 2.47.1