From mboxrd@z Thu Jan 1 00:00:00 1970 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: 8bit When high-speed NICs or multi-GPU setups are passed through into confidential 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 untrusted. DMA-capable devices require bounce buffers to mediate between encrypted private 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 = true; - x86_swiotlb_flags |= SWIOTLB_FORCE; + x86_swiotlb_flags |= SWIOTLB_ANY | SWIOTLB_FORCE; } } #else -- 2.47.1