Re: [RFC PATCH 1/2] swiotlb: Split up single swiotlb lock

From: Robin Murphy <robin.murphy@arm.com>
To: Christoph Hellwig <hch@infradead.org>
Cc: Tianyu Lan <ltykernel@gmail.com>,
	m.szyprowski@samsung.com, michael.h.kelley@microsoft.com,
	kys@microsoft.com, parri.andrea@gmail.com,
	thomas.lendacky@amd.com, wei.liu@kernel.org,
	Andi Kleen <ak@linux.intel.com>,
	Tianyu Lan <Tianyu.Lan@microsoft.com>,
	linux-hyperv@vger.kernel.org, konrad.wilk@oracle.com,
	linux-kernel@vger.kernel.org, kirill.shutemov@intel.com,
	iommu@lists.linux-foundation.org, andi.kleen@intel.com,
	brijesh.singh@amd.com, vkuznets@redhat.com, hch@lst.de
Subject: Re: [RFC PATCH 1/2] swiotlb: Split up single swiotlb lock
Date: Thu, 28 Apr 2022 15:56:24 +0100	[thread overview]
Message-ID: <f0ab2aa5-ca23-fa40-6147-43fc1f385bc8@arm.com> (raw)
In-Reply-To: <YmqonHKBT8ftYHgY@infradead.org>

On 2022-04-28 15:45, Christoph Hellwig wrote:
> On Thu, Apr 28, 2022 at 03:44:36PM +0100, Robin Murphy wrote:
>> Rather than introduce this extra level of allocator complexity, how about
>> just dividing up the initial SWIOTLB allocation into multiple io_tlb_mem
>> instances?
> 
> Yeah.  We're almost done removing all knowledge of swiotlb from drivers,
> so the very last thing I want is an interface that allows a driver to
> allocate a per-device buffer.

FWIW I'd already started thinking about having a distinct io_tlb_mem for 
non-coherent devices where vaddr is made non-cacheable to avoid the 
hassle of keeping the arch_dma_sync_* calls lined up, so I'm certainly 
in favour of bringing in a bit more flexibility at this level :)

Robin.