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]

Date:   Mon, 24 Aug 2020 16:55:42 -0500
From:   Suman Anna <s-anna@...com>
To:     Robin Murphy <robin.murphy@....com>,
        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>, <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 8/20/20 6:01 PM, Robin Murphy wrote:
> 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?

Yeah, I don't think we go through the of_iommu_configure() path, the setup is
mostly done using .probe_device() and .attach_dev() ops. Since the MMUs are
present directly in the respective sub-systems and relies on the sub-system
clocking and power, the MMU itself is turned ON and enabled during .attach_dev().

regards
Suman

>>
>> 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.