Re: [PATCH] Changing the AMD IOMMU API path to work in an atomic context which is necessary for any custom drivers using the IOMMU API while holding a spinlock.

[Tom Murphy <murphyt7-/Zw1syy4LHg@public.gmane.org>]

[-- Attachment #1.1: Type: text/plain, Size: 1620 bytes --]

*resending this email without a link to the kernel source to avoid spam
detection*

The reason we want this change is so we can use iommu_group's to force our
pcie devices to have the same IOMMU mappings. For legacy reasons we require
a bunch of our pcie devices to have the same address translations.

We were going to do this by using the iommu-dma api and replacing all the
existing calls to the DMA API functions in the amd driver with their
iommu-dma equivalent like in the driver: /arch/arm64/mm/dma-mapping.c:810
in kernel v4.18.5

To do this we need the map/unmap callbacks to be spinlock-safe.

On 24 August 2018 at 16:24, Robin Murphy <robin.murphy-5wv7dgnIgG8@public.gmane.org> wrote:

> On 24/08/18 15:53, Christoph Hellwig wrote:
>
>> On Fri, Aug 24, 2018 at 02:28:49PM +0000, murphyt7-/Zw1syy4LHg@public.gmane.org wrote:
>>
>>> From: Tom Murphy <murphyt7-/Zw1syy4LHg@public.gmane.org>
>>>
>>> ---
>>>
>>> This patch allows the IOMMU API path in the AMD driver to be called from
>>> an atomic context.
>>> This is useful for anyone building a driver which needs to call the
>>> IOMMU API while holding a spinlock.
>>>
>>
>> I don't think that is a good idea.  Please point to the code in the
>> driver and we can't probably find a better solution.
>>
>
> Although IIRC the AMD driver is in fact the only one whose map/unmap
> callbacks aren't already spinlock-safe (or at least it was last time I was
> looking). Stuff like iommu-dma is already relying on this in order to
> implement streaming DMA API calls (which may be in atomic context) on top
> of the corresponding IOMMU API operations.
>
> Robin.
>

[-- Attachment #1.2: Type: text/html, Size: 2492 bytes --]

[-- Attachment #2: Type: text/plain, Size: 0 bytes --]