linux-kernel - Re: [PATCH 0/5] iommu: Some IOVA code reorganisation

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: <20211004114418.GC27373@willie-the-truck>
Date:   Mon, 4 Oct 2021 12:44:18 +0100
From:   Will Deacon <will@...nel.org>
To:     John Garry <john.garry@...wei.com>
Cc:     joro@...tes.org, mst@...hat.com, jasowang@...hat.com,
        robin.murphy@....com, xieyongji@...edance.com,
        linux-kernel@...r.kernel.org, iommu@...ts.linux-foundation.org,
        virtualization@...ts.linux-foundation.org, linuxarm@...wei.com,
        thunder.leizhen@...wei.com, baolu.lu@...ux.intel.com
Subject: Re: [PATCH 0/5] iommu: Some IOVA code reorganisation

On Fri, Sep 24, 2021 at 06:01:52PM +0800, John Garry wrote:
> The IOVA domain structure is a bit overloaded, holding:
> - IOVA tree management
> - FQ control
> - IOVA rcache memories
> 
> Indeed only a couple of IOVA users use the rcache, and only dma-iommu.c
> uses the FQ feature.
> 
> This series separates out that structure. In addition, it moves the FQ
> code into dma-iommu.c . This is not strictly necessary, but it does make
> it easier for the FQ domain lookup the rcache domain.
> 
> The rcache code stays where it is, as it may be reworked in future, so
> there is not much point in relocating and then discarding.
> 
> This topic was initially discussed and suggested (I think) by Robin here:
> https://lore.kernel.org/linux-iommu/1d06eda1-9961-d023-f5e7-fe87e768f067@arm.com/

It would be useful to have Robin's Ack on patches 2-4. The implementation
looks straightforward to me, but the thread above isn't very clear about
what is being suggested.

To play devil's advocate: there aren't many direct users of the iovad code:
either they'll die out entirely (and everybody will use the dma-iommu code)
and it's fine having the flush queue code where it is, or we'll get more
users and the likelihood of somebody else wanting flush queues increases.

Will