diff mbox series

[RFC,V1,3/5] x86: CVMs: Enable dynamic swiotlb by default for CVMs

Message ID 20240112055251.36101-4-vannapurve@google.com
State New
Headers
Series x86: CVMs: Align memory conversions to 2M granularity |

Commit Message

Vishal Annapurve Jan. 12, 2024, 5:52 a.m. UTC 
  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(+)

Comments

Jeremi Piotrowski Feb. 1, 2024, 12:20 p.m. UTC | #1 
On 12/01/2024 06:52, Vishal Annapurve wrote:
> 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

What this does is unconditionally enable SWIOTLB_DYNAMIC for every kernel compiled
to support memory encryption, regardless of whether it runs inside a confidential guest.
I don't think that is what you intended.

Best wishes,
Jeremi
Vishal Annapurve Feb. 2, 2024, 4:40 a.m. UTC | #2 
On Thu, Feb 1, 2024 at 5:50 PM Jeremi Piotrowski
<jpiotrowski@linux.microsoft.com> wrote:
>
> On 12/01/2024 06:52, Vishal Annapurve wrote:
> > 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
>
> What this does is unconditionally enable SWIOTLB_DYNAMIC for every kernel compiled
> to support memory encryption, regardless of whether it runs inside a confidential guest.
> I don't think that is what you intended.
>

Right, I will have to add a way to toggle this support dynamically in
addition to having the support built in, based on more discussion
around 2M allocations and dynamic scaling.

> Best wishes,
> Jeremi
>
>
diff mbox series

Patch

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