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]
Date:   Wed, 9 Dec 2020 12:29:07 +0000
From:   Ashish Kalra <ashish.kalra@....com>
To:     Borislav Petkov <bp@...en8.de>
Cc:     konrad.wilk@...cle.com, hch@....de, tglx@...utronix.de,
        mingo@...hat.com, hpa@...or.com, x86@...nel.org, luto@...nel.org,
        peterz@...radead.org, dave.hansen@...ux-intel.com,
        iommu@...ts.linux-foundation.org, linux-kernel@...r.kernel.org,
        brijesh.singh@....com, Thomas.Lendacky@....com, Jon.Grimm@....com,
        rientjes@...gle.com
Subject: Re: [PATCH v8] swiotlb: Adjust SWIOTBL bounce buffer size for SEV
 guests.

On Wed, Dec 09, 2020 at 12:01:15PM +0100, Borislav Petkov wrote:
> > Subject: Re: [PATCH v8] swiotlb: Adjust SWIOTBL bounce buffer size for SEV guests.
> 
> Fix subject prefix to "x86, swiotlb: ... SWIOTLB ... for SEV guests
> 
> Fix typo and no fullstop at the end.
> 
> On Mon, Dec 07, 2020 at 11:10:57PM +0000, Ashish Kalra wrote:
> > From: Ashish Kalra <ashish.kalra@....com>
> > 
> > For SEV, all DMA to and from guest has to use shared (un-encrypted) pages.
> > SEV uses SWIOTLB to make this happen without requiring changes to device
> > drivers.  However, depending on workload being run, the default 64MB of
> 				 ^
> 				 the
> 
> > SWIOTLB might not be enough and SWIOTLB may run out of buffers to use
> 
> 				s/SWIOTLB/it/
> 
> > for DMA, resulting in I/O errors and/or performance degradation for
> > high I/O workloads.
> > 
> > Adjust the default size of SWIOTLB for SEV guests using a
> > percentage of the total memory available to guest for SWIOTLB buffers.
> 					     ^
> 					     the
> 
> > 
> > Using late_initcall() interface to invoke swiotlb_adjust() does not
> > work as the size adjustment needs to be done before mem_encrypt_init()
> > and reserve_crashkernel() which use the allocated SWIOTLB buffer size,
> > hence call it explicitly from setup_arch().
> 
> So setup_arch() is x86-specific and already a dumping ground for all
> kinds of init stuff.
> 
> Why don't you call swiotlb_adjust() in mem_encrypt_init() where it
> already does swiotlb stuff - swiotlb_update_mem_attributes() - and avoid
> all the arch-agnostic function glue?
> 

As i mentioned in the main comments above, this cannot be called in
mem_encrypt_init() as that breaks reserve_crashkernel() which depends on
SWIOTLB buffer size and is called before mem_encrypt_init(), therefore,
it needs to be called from setup_atch() before reserve_crashkernel(). 

> That is, unless Konrad wants to do other swiotlb adjusting on !x86 too...
> 
> > The SWIOTLB default size adjustment needs to be added as an architecture
> > specific interface/callback to allow architectures such as those supporting
> > memory encryption to adjust/expand SWIOTLB size for their use.
> 
> So are other arches wanting this or is this just an assumption? If
> latter, you can do x86 only now and let the others extend it when they
> really need it.

I believe that other memory encryption architectures such as s390 are
also looking for something similar to be available. 

Thanks,
Ashish

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ