linux-kernel - Re: [PATCH 2/2] iommu/omap: Add support to program multiple iommus

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: <d8b503a1-eaff-e4cc-215d-92520a91e205@ti.com>
Date:   Fri, 1 Sep 2017 11:21:45 -0500
From:   Suman Anna <s-anna@...com>
To:     Joerg Roedel <joro@...tes.org>
CC:     <iommu@...ts.linux-foundation.org>,
        Tony Lindgren <tony@...mide.com>,
        Tero Kristo <t-kristo@...com>,
        Laurent Pinchart <laurent.pinchart@...asonboard.com>,
        <linux-omap@...r.kernel.org>, <linux-kernel@...r.kernel.org>
Subject: Re: [PATCH 2/2] iommu/omap: Add support to program multiple iommus

Hi Joerg,

On 09/01/2017 05:01 AM, Joerg Roedel wrote:
> Hi Suman,
> 
> On Thu, Aug 31, 2017 at 08:14:02AM -0500, Suman Anna wrote:
>> The OMAP IOMMU driver has been enhanced to support allowing
>> multiple IOMMUs to be programmed by a single client user. This
>> support is being added mainly to handle the DSP subsystems on
>> the DRA7xx SoCs, which have two MMUs within the same subsystem.
>> These MMUs provide translations to a processor core port and
>> an internal EDMA port. This support allows both the MMUs to
>> be programmed together, but with each one retaining it's own
>> internal state objects. The internal EDMA is managed by the
>> software running on the DSPs, and this design provides on-par
>> functionality with previous generation OMAP DSPs where the
>> EDMA and the DSP core shared the same MMU.
> 
> I didn't get that from the review, so a question here: Do both MMUs show
> show up in sysfs, means, do you register both of them the the core code?

Yes, both MMUs are identical instances of the IP, and both are
represented as their own platform devices (unique DT nodes), and since
we created the iommu_group in probe of each device, each MMU has its own
iommu_group as well.

Here's a bit more output,

root@...7xx-evm:~# dmesg | grep mmu
[    0.519087] omap-iommu 40d01000.mmu: 40d01000.mmu registered
[    0.519580] omap-iommu 40d02000.mmu: 40d02000.mmu registered
[    0.520050] omap-iommu 58882000.mmu: 58882000.mmu registered
[    0.520495] omap-iommu 55082000.mmu: 55082000.mmu registered
[    0.521145] omap-iommu 41501000.mmu: 41501000.mmu registered
[    0.521634] omap-iommu 41502000.mmu: 41502000.mmu registered
[    0.522100] iommu: Adding device 58820000.ipu to group 2
[    0.522260] iommu: Adding device 55020000.ipu to group 3
[    0.522520] iommu: Adding device 40800000.dsp to group 0
[    0.522955] iommu: Adding device 41000000.dsp to group 4
root@...7xx-evm:~# ls -l /sys/class/iommu/
lrwxrwxrwx    1 root     root             0 Aug  8 03:59 40d01000.mmu ->
../../devices/platform/44000000.ocp/40d01000.mmu/iommu/40d01000.mmu
lrwxrwxrwx    1 root     root             0 Aug  8 03:59 40d02000.mmu ->
../../devices/platform/44000000.ocp/40d02000.mmu/iommu/40d02000.mmu
lrwxrwxrwx    1 root     root             0 Aug  8 03:59 41501000.mmu ->
../../devices/platform/44000000.ocp/41501000.mmu/iommu/41501000.mmu
lrwxrwxrwx    1 root     root             0 Aug  8 03:59 41502000.mmu ->
../../devices/platform/44000000.ocp/41502000.mmu/iommu/41502000.mmu
lrwxrwxrwx    1 root     root             0 Aug  8 03:59 55082000.mmu ->
../../devices/platform/44000000.ocp/55082000.mmu/iommu/55082000.mmu
lrwxrwxrwx    1 root     root             0 Aug  8 03:59 58882000.mmu ->
../../devices/platform/44000000.ocp/58882000.mmu/iommu/58882000.mmu

> Because I think with the solution implemented here, only a single,
> combined MMU should be visible to iommu core code and in sysfs.

So, the way I have implemented atm is to do the device linking only to
one MMU in .add_device ops, while most of the remaining ops like map,
unmap, attach_device, detach_device loop through both MMUs to do the
programming.

It's primarily a question of whether each iommu platform device need to
be represented as a unique iommu_device or not. If you still think that
both these need to be presented to iommu core as one device, I would
have to add some glue logic in probe to tie the two devices together.

regards
Suman