Messages in this thread | ![/](/images/icornerl.gif) | | From | Vishal Annapurve <> | Date | Thu, 1 Feb 2024 09:11:11 +0530 | Subject | Re: [RFC V1 4/5] x86: CVMs: Allow allocating all DMA memory from SWIOTLB |
| |
On Wed, Jan 31, 2024 at 9:47 PM Dave Hansen <dave.hansen@intel.com> wrote: > > On 1/11/24 21:52, Vishal Annapurve wrote: > > --- a/arch/x86/mm/mem_encrypt.c > > +++ b/arch/x86/mm/mem_encrypt.c > > @@ -112,10 +112,14 @@ void __init mem_encrypt_setup_arch(void) > > * The percentage of guest memory used here for SWIOTLB buffers > > * is more of an approximation of the static adjustment which > > * 64MB for <1G, and ~128M to 256M for 1G-to-4G, i.e., the 6% > > + * > > + * Extra 2% is added to accommodate the requirement of DMA allocations > > + * done using dma_alloc_* APIs. > > */ > > - size = total_mem * 6 / 100; > > - size = clamp_val(size, IO_TLB_DEFAULT_SIZE, SZ_1G); > > + size = total_mem * 8 / 100; > > + size = clamp_val(size, IO_TLB_DEFAULT_SIZE, (SZ_1G + SZ_256M)); > > swiotlb_adjust_size(size); > > + swiotlb_adjust_alignment(SZ_2M); > > FWIW, this appears superficially to just be fiddling with random > numbers. The changelog basically says: "did stuff". > > What *are* "the requirement of DMA allocations done using dma_alloc_* APIs"?
dma_alloc_* invocations depend on the devices used and may change with time, so it's difficult to calculate the memory required for such allocations.
Though one could note following points about memory allocations done using dma_alloc_* APIs: 1) They generally happen during early setup of device drivers. 2) They should be relatively smaller in size compared to runtime memory allocation done by dma_map_* APIs.
This change increases the SWIOTLB memory area by 30% based on the above observations. Strategy here would be to take a safe enough heuristic and let dynamic SWIOTLB allocations to handle any spillover.
| ![\](/images/icornerr.gif) |