linux-kernel - Re: [RFC V1 4/5] x86: CVMs: Allow allocating all DMA memory from SWIOTLB

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <db477cef-f63b-4950-82b0-275bd10dbe5c@intel.com>
Date: Wed, 31 Jan 2024 08:17:15 -0800
From: Dave Hansen <dave.hansen@...el.com>
To: Vishal Annapurve <vannapurve@...gle.com>, x86@...nel.org,
 linux-kernel@...r.kernel.org
Cc: pbonzini@...hat.com, rientjes@...gle.com, bgardon@...gle.com,
 seanjc@...gle.com, erdemaktas@...gle.com, ackerleytng@...gle.com,
 jxgao@...gle.com, sagis@...gle.com, oupton@...gle.com, peterx@...hat.com,
 vkuznets@...hat.com, dmatlack@...gle.com, pgonda@...gle.com,
 michael.roth@....com, kirill@...temov.name, thomas.lendacky@....com,
 dave.hansen@...ux.intel.com, linux-coco@...ts.linux.dev,
 chao.p.peng@...ux.intel.com, isaku.yamahata@...il.com,
 andrew.jones@...ux.dev, corbet@....net, hch@....de,
 m.szyprowski@...sung.com, bp@...e.de, rostedt@...dmis.org,
 iommu@...ts.linux.dev
Subject: Re: [RFC V1 4/5] x86: CVMs: Allow allocating all DMA memory from
 SWIOTLB

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"?