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 <[email protected]> > > > > 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
