s390: Select SWIOTLB_DYNAMIC and DMA_COHERENT_POOL

SWIOTLB_DYNAMIC allows the SWIOTLB to grow on demand when the initial
bounce-buffer area is exhausted, instead of relying only on the pool
reserved at boot. This improves behavior under sustained I/O pressure.

In testing, exhaustion of the initial SWIOTLB area was observed under
real workloads such as large file transfers and package installation
workloads, where continued availability of bounce buffering was needed
to avoid guest-visible I/O stalls or failures.

When the current SWIOTLB capacity is exhausted, the dynamic expansion
path schedules asynchronous pool growth and then attempts immediate
non-blocking allocation of transient bounce-buffer memory.

In that path, the current implementation uses the generic DMA coherent
atomic pool for transient bounce-buffer allocations. Selecting
DMA_COHERENT_POOL together with SWIOTLB_DYNAMIC on s390 makes that
atomic fallback path available.

The coherent atomic pool is a generic DMA facility. By default, its size
is 128 KiB per 1 GiB of memory, with a minimum default size of 128 KiB,
and it can be adjusted with the coherent_pool= kernel parameter. The pool
itself can be exhausted, so this improves behavior under pressure, but
does not guarantee that DMA mappings will always succeed.

Select both options from s390 Kconfig so this support is available by
default on s390 systems.

Signed-off-by: Jaehoon Kim <jhkim@linux.ibm.com>
Acked-by: Niklas Schnelle <schnelle@linux.ibm.com>
Reviewed-by: Halil Pasic <pasic@linux.ibm.com>
Tested-by: Joshua Daley <jdaley@linux.ibm.com>
Signed-off-by: Vasily Gorbik <gor@linux.ibm.com>

arch/s390/Kconfig

@@ -278,6 +278,8 @@ config S390
 	select PCI_QUIRKS		if PCI
 	select SPARSE_IRQ
 	select SWIOTLB
+	select SWIOTLB_DYNAMIC
+	select DMA_COHERENT_POOL
 	select SYSCTL_EXCEPTION_TRACE
 	select SYSTEM_DATA_VERIFICATION if KEXEC_SIG
 	select THREAD_INFO_IN_TASK