linux-kernel - Re: [PATCH 12/18] iommu/tegra-gart: Add IOMMU_DOMAIN

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 for Android: free password hash cracker in your pocket

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <3a132bb0-f2e6-6f8d-6d0c-bc925dd23f06@arm.com>
Date:   Fri, 21 Aug 2020 01:28:49 +0100
From:   Robin Murphy <robin.murphy@....com>
To:     Dmitry Osipenko <digetx@...il.com>, hch@....de, joro@...tes.org,
        linux@...linux.org.uk
Cc:     will@...nel.org, inki.dae@...sung.com, sw0312.kim@...sung.com,
        kyungmin.park@...sung.com, m.szyprowski@...sung.com,
        agross@...nel.org, bjorn.andersson@...aro.org,
        thierry.reding@...il.com, jonathanh@...dia.com, vdumpa@...dia.com,
        matthias.bgg@...il.com, yong.wu@...iatek.com,
        geert+renesas@...der.be, magnus.damm@...il.com, t-kristo@...com,
        s-anna@...com, laurent.pinchart@...asonboard.com,
        linux-arm-kernel@...ts.infradead.org,
        iommu@...ts.linux-foundation.org,
        linux-samsung-soc@...r.kernel.org, linux-tegra@...r.kernel.org,
        linux-arm-msm@...r.kernel.org, linux-mediatek@...ts.infradead.org,
        dri-devel@...ts.freedesktop.org, linux-media@...r.kernel.org,
        linux-kernel@...r.kernel.org
Subject: Re: [PATCH 12/18] iommu/tegra-gart: Add IOMMU_DOMAIN_DMA support

On 2020-08-20 21:16, Dmitry Osipenko wrote:
> 20.08.2020 18:08, Robin Murphy пишет:
>> Now that arch/arm is wired up for default domains and iommu-dma,
>> implement the corresponding driver-side support for DMA domains.
>>
>> Signed-off-by: Robin Murphy <robin.murphy@....com>
>> ---
>>   drivers/iommu/tegra-gart.c | 17 ++++++++++++-----
>>   1 file changed, 12 insertions(+), 5 deletions(-)
>>
>> diff --git a/drivers/iommu/tegra-gart.c b/drivers/iommu/tegra-gart.c
>> index fac720273889..e081387080f6 100644
>> --- a/drivers/iommu/tegra-gart.c
>> +++ b/drivers/iommu/tegra-gart.c
>> @@ -9,6 +9,7 @@
>>   
>>   #define dev_fmt(fmt)	"gart: " fmt
>>   
>> +#include <linux/dma-iommu.h>
>>   #include <linux/io.h>
>>   #include <linux/iommu.h>
>>   #include <linux/moduleparam.h>
>> @@ -145,16 +146,22 @@ static struct iommu_domain *gart_iommu_domain_alloc(unsigned type)
>>   {
>>   	struct iommu_domain *domain;
> 
> Hello, Robin!
> 
> Tegra20 GART isn't a real IOMMU, but a small relocation aperture. We
> would only want to use it for a temporal mappings (managed by GPU
> driver) for the time while GPU hardware is busy and working with a
> sparse DMA buffers, the driver will take care of unmapping the sparse
> buffers once GPU work is finished [1]. In a case of contiguous DMA
> buffers, we want to bypass the IOMMU and use buffer's phys address
> because GART aperture is small and all buffers simply can't fit into
> GART for a complex GPU operations that involve multiple buffers [2][3].
> The upstream GPU driver still doesn't support GART, but eventually it
> needs to be changed.
> 
> [1]
> https://github.com/grate-driver/linux/blob/master/drivers/gpu/drm/tegra/gart.c#L489
> 
> [2]
> https://github.com/grate-driver/linux/blob/master/drivers/gpu/drm/tegra/gart.c#L542
> 
> [3]
> https://github.com/grate-driver/linux/blob/master/drivers/gpu/drm/tegra/uapi/patching.c#L90
> 
>> -	if (type != IOMMU_DOMAIN_UNMANAGED)
>> +	if (type != IOMMU_DOMAIN_UNMANAGED && type != IOMMU_DOMAIN_DMA)
>>   		return NULL;
> 
> Will a returned NULL tell to IOMMU core that implicit domain shouldn't
> be used? Is it possible to leave this driver as-is?

The aim of this patch was just to make the conversion without functional 
changes wherever possible, i.e. maintain an equivalent to the existing 
ARM behaviour of allocating its own implicit domains for everything. It 
doesn't represent any judgement of whether that was ever appropriate for 
this driver in the first place ;)

Hopefully my other reply already covered the degree of control drivers 
can have with proper default domains, but do shout if anything wasn't clear.

Cheers,
Robin.