public inbox for linux-kernel@vger.kernel.org
 help / color / mirror / Atom feed
From: Vishal Annapurve <vannapurve@google.com>
To: x86@kernel.org, linux-kernel@vger.kernel.org
Cc: pbonzini@redhat.com, rientjes@google.com, bgardon@google.com,
	 seanjc@google.com, erdemaktas@google.com,
	ackerleytng@google.com,  jxgao@google.com, sagis@google.com,
	oupton@google.com, peterx@redhat.com,  vkuznets@redhat.com,
	dmatlack@google.com, pgonda@google.com,  michael.roth@amd.com,
	kirill@shutemov.name, thomas.lendacky@amd.com,
	 dave.hansen@linux.intel.com, linux-coco@lists.linux.dev,
	 chao.p.peng@linux.intel.com, isaku.yamahata@gmail.com,
	andrew.jones@linux.dev,  corbet@lwn.net, hch@lst.de,
	m.szyprowski@samsung.com, bp@suse.de,  rostedt@goodmis.org,
	iommu@lists.linux.dev,  Vishal Annapurve <vannapurve@google.com>
Subject: [RFC V1 3/5] x86: CVMs: Enable dynamic swiotlb by default for CVMs
Date: Fri, 12 Jan 2024 05:52:49 +0000	[thread overview]
Message-ID: <20240112055251.36101-4-vannapurve@google.com> (raw)
In-Reply-To: <20240112055251.36101-1-vannapurve@google.com>

CVMs used SWIOTLB for non-trusted IO using dma_map_* APIs. This series
will ensure that dma_alloc_* API to also allocate from SWIOTLB pools.
Initial size of SWIOTLB pool is decided using heuristics and has been
working with CVM usecases so far.

It's better to allow SWIOTLB to scale up on demand rather than keeping
the size fixed to avoid failures with possibly increased usage of
SWIOTLB with dma_alloc_* APIs allocating from SWIOTLB pools. This should
also help in future with more devices getting used from CVMs for
non-trusted IO.

Signed-off-by: Vishal Annapurve <vannapurve@google.com>
---
 arch/x86/Kconfig | 2 ++
 1 file changed, 2 insertions(+)

diff --git a/arch/x86/Kconfig b/arch/x86/Kconfig
index 1566748f16c4..035c8a022c4c 100644
--- a/arch/x86/Kconfig
+++ b/arch/x86/Kconfig
@@ -884,6 +884,7 @@ config INTEL_TDX_GUEST
 	select X86_MEM_ENCRYPT
 	select X86_MCE
 	select UNACCEPTED_MEMORY
+	select SWIOTLB_DYNAMIC
 	help
 	  Support running as a guest under Intel TDX.  Without this support,
 	  the guest kernel can not boot or run under TDX.
@@ -1534,6 +1535,7 @@ config AMD_MEM_ENCRYPT
 	select ARCH_HAS_CC_PLATFORM
 	select X86_MEM_ENCRYPT
 	select UNACCEPTED_MEMORY
+	select SWIOTLB_DYNAMIC
 	help
 	  Say yes to enable support for the encryption of system memory.
 	  This requires an AMD processor that supports Secure Memory
-- 
2.43.0.275.g3460e3d667-goog


  parent reply	other threads:[~2024-01-12  5:53 UTC|newest]

Thread overview: 28+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2024-01-12  5:52 [RFC V1 0/5] x86: CVMs: Align memory conversions to 2M granularity Vishal Annapurve
2024-01-12  5:52 ` [RFC V1 1/5] swiotlb: Support allocating DMA memory from SWIOTLB Vishal Annapurve
2024-02-14 14:49   ` Kirill A. Shutemov
2024-02-15  3:33     ` Vishal Annapurve
2024-02-15  9:44       ` Alexander Graf
2024-02-15 20:26         ` Michael Kelley
2024-02-24 17:07           ` Vishal Annapurve
2024-02-24 22:02             ` Michael Kelley
2024-03-05 17:19         ` Vishal Annapurve
2024-01-12  5:52 ` [RFC V1 2/5] swiotlb: Allow setting up default alignment of SWIOTLB region Vishal Annapurve
2024-01-12  5:52 ` Vishal Annapurve [this message]
2024-02-01 12:20   ` [RFC V1 3/5] x86: CVMs: Enable dynamic swiotlb by default for CVMs Jeremi Piotrowski
2024-02-02  4:40     ` Vishal Annapurve
2024-01-12  5:52 ` [RFC V1 4/5] x86: CVMs: Allow allocating all DMA memory from SWIOTLB Vishal Annapurve
2024-01-31 16:17   ` Dave Hansen
2024-02-01  3:41     ` Vishal Annapurve
2024-01-12  5:52 ` [RFC V1 5/5] x86: CVMs: Ensure that memory conversions happen at 2M alignment Vishal Annapurve
2024-01-31 16:33   ` Dave Hansen
2024-02-01  3:46     ` Vishal Annapurve
2024-02-01 12:02       ` Jeremi Piotrowski
2024-02-02  5:08         ` Vishal Annapurve
2024-02-02  8:00           ` Jeremi Piotrowski
2024-02-02 16:22             ` Vishal Annapurve
2024-02-02 16:35               ` Dave Hansen
2024-02-03  5:19                 ` Vishal Annapurve
2024-01-30 16:42 ` [RFC V1 0/5] x86: CVMs: Align memory conversions to 2M granularity Vishal Annapurve
2024-01-31 16:52 ` Dave Hansen
2024-02-01  5:44   ` Vishal Annapurve

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20240112055251.36101-4-vannapurve@google.com \
    --to=vannapurve@google.com \
    --cc=ackerleytng@google.com \
    --cc=andrew.jones@linux.dev \
    --cc=bgardon@google.com \
    --cc=bp@suse.de \
    --cc=chao.p.peng@linux.intel.com \
    --cc=corbet@lwn.net \
    --cc=dave.hansen@linux.intel.com \
    --cc=dmatlack@google.com \
    --cc=erdemaktas@google.com \
    --cc=hch@lst.de \
    --cc=iommu@lists.linux.dev \
    --cc=isaku.yamahata@gmail.com \
    --cc=jxgao@google.com \
    --cc=kirill@shutemov.name \
    --cc=linux-coco@lists.linux.dev \
    --cc=linux-kernel@vger.kernel.org \
    --cc=m.szyprowski@samsung.com \
    --cc=michael.roth@amd.com \
    --cc=oupton@google.com \
    --cc=pbonzini@redhat.com \
    --cc=peterx@redhat.com \
    --cc=pgonda@google.com \
    --cc=rientjes@google.com \
    --cc=rostedt@goodmis.org \
    --cc=sagis@google.com \
    --cc=seanjc@google.com \
    --cc=thomas.lendacky@amd.com \
    --cc=vkuznets@redhat.com \
    --cc=x86@kernel.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox