linux-kernel - Re: [PATCH 17/18] media/omap3isp: Clean up IOMMU workaround

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: Windows password security audit tool. GUI, reports in PDF.

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

Message-ID: <5190a40e-ad24-d98e-3588-b95592ea2db3@arm.com>
Date:   Fri, 21 Aug 2020 00:01:38 +0100
From:   Robin Murphy <robin.murphy@....com>
To:     Sakari Ailus <sakari.ailus@....fi>
Cc:     hch@....de, joro@...tes.org, linux@...linux.org.uk,
        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,
        digetx@...il.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 17/18] media/omap3isp: Clean up IOMMU workaround

On 2020-08-20 20:55, Sakari Ailus wrote:
> On Thu, Aug 20, 2020 at 06:25:19PM +0100, Robin Murphy wrote:
>> On 2020-08-20 17:53, Sakari Ailus wrote:
>>> Hi Robin,
>>>
>>> On Thu, Aug 20, 2020 at 04:08:36PM +0100, Robin Murphy wrote:
>>>> Now that arch/arm is wired up for default domains and iommu-dma, devices
>>>> behind IOMMUs will get mappings set up automatically as appropriate, so
>>>> there is no need for drivers to do so manually.
>>>>
>>>> Signed-off-by: Robin Murphy <robin.murphy@....com>
>>>
>>> Thanks for the patch.
>>
>> Many thanks for testing so quickly!
>>
>>> I haven't looked at the details but it seems that this causes the buffer
>>> memory allocation to be physically contiguous, which causes a failure to
>>> allocate video buffers of entirely normal size. I guess that was not
>>> intentional?
>>
>> Hmm, it looks like the device ends up with the wrong DMA ops, which implies
>> something didn't go as expected with the earlier IOMMU setup and default
>> domain creation. Chances are that either I missed some subtlety in the
>> omap_iommu change, or I've fundamentally misjudged how the ISP probing works
>> and it never actually goes down the of_iommu_configure() path in the first
>> place. Do you get any messages from the IOMMU layer earlier on during boot?
> 
> I do get these:
> 
> [    2.934936] iommu: Default domain type: Translated
> [    2.940917] omap-iommu 480bd400.mmu: 480bd400.mmu registered
> [    2.946899] platform 480bc000.isp: Adding to iommu group 0
> 

So that much looks OK, if there are no obvious errors. Unfortunately 
there's no easy way to tell exactly what of_iommu_configure() is doing 
(beyond enabling a couple of vague debug messages). The first thing I'll 
do tomorrow is double-check whether it's really working on my boards 
here, or whether I was just getting lucky with CMA... (I assume you 
don't have CMA enabled if you're ending up in remap_allocator_alloc())

Robin.