linux-kernel - Re: [PATCH v3 0/2] iommu: handle drivers that manage iommu directly

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] [day] [month] [year] [list]

Message-ID: <20190917133637.urqphz5drzmugern@willie-the-truck>
Date:   Tue, 17 Sep 2019 14:36:37 +0100
From:   Will Deacon <will@...nel.org>
To:     Rob Clark <robdclark@...il.com>
Cc:     Robin Murphy <robin.murphy@....com>,
        "list@....net:IOMMU DRIVERS <iommu@...ts.linux-foundation.org>, Joerg
        Roedel <joro@...tes.org>," <iommu@...ts.linux-foundation.org>,
        dri-devel <dri-devel@...ts.freedesktop.org>,
        linux-arm-msm <linux-arm-msm@...r.kernel.org>,
        Joerg Roedel <joro@...tes.org>,
        Rob Clark <robdclark@...omium.org>,
        Abhinav Kumar <abhinavk@...eaurora.org>,
        Alexios Zavras <alexios.zavras@...el.com>,
        Allison Randal <allison@...utok.net>,
        Andrew Morton <akpm@...ux-foundation.org>,
        Arnd Bergmann <arnd@...db.de>,
        Bartosz Golaszewski <brgl@...ev.pl>,
        Boris Brezillon <bbrezillon@...nel.org>,
        Bruce Wang <bzwang@...omium.org>,
        "open list:DRM DRIVER FOR MSM ADRENO GPU" 
        <freedreno@...ts.freedesktop.org>,
        Georgi Djakov <georgi.djakov@...aro.org>,
        Greg Kroah-Hartman <gregkh@...uxfoundation.org>,
        Heikki Krogerus <heikki.krogerus@...ux.intel.com>,
        Jeffrey Hugo <jeffrey.l.hugo@...il.com>,
        Jeykumar Sankaran <jsanka@...eaurora.org>,
        Joe Perches <joe@...ches.com>, Joerg Roedel <jroedel@...e.de>,
        Jonathan Marek <jonathan@...ek.ca>,
        Jordan Crouse <jcrouse@...eaurora.org>,
        open list <linux-kernel@...r.kernel.org>,
        Mamta Shukla <mamtashukla555@...il.com>,
        "Rafael J. Wysocki" <rafael.j.wysocki@...el.com>,
        Rasmus Villemoes <linux@...musvillemoes.dk>,
        Sean Paul <seanpaul@...omium.org>,
        Sravanthi Kollukuduru <skolluku@...eaurora.org>,
        Sudeep Holla <sudeep.holla@....com>,
        Suzuki K Poulose <suzuki.poulose@....com>,
        Thomas Gleixner <tglx@...utronix.de>
Subject: Re: [PATCH v3 0/2] iommu: handle drivers that manage iommu directly

On Tue, Sep 10, 2019 at 10:10:49AM -0700, Rob Clark wrote:
> On Tue, Sep 10, 2019 at 9:34 AM Robin Murphy <robin.murphy@....com> wrote:
> > On 06/09/2019 22:44, Rob Clark wrote:
> > > NOTE that in discussion of previous revisions, RMRR came up.  This is
> > > not really a replacement for RMRR (nor does RMRR really provide any
> > > more information than we already get from EFI GOP, or DT in the
> > > simplefb case).  I also don't see how RMRR could help w/ SMMU handover
> > > of CB/SMR config (Bjorn's patchset[1]) without defining new tables.
> >
> > The point of RMRR-like-things is that they identify not just the memory
> > region but also the specific device accessing them, which means the
> > IOMMU driver knows up-front which IDs etc. it must be careful not to
> > disrupt. Obviously for SMMU that *would* be some new table (designed to
> > encompass everything relevant) since literal RMRRs are specifically an
> > Intel VT-d thing.
> 
> Perhaps I'm not looking in the right place, but the extent of what I
> could find about RMRR tables was:
> 
> https://github.com/tianocore/edk2/blob/master/MdePkg/Include/IndustryStandard/DmaRemappingReportingTable.h#L122
> 
> I couldn't really see how that specifies the device.  But entirely
> possible that I'm not seeing the whole picture.

I don't think anybody was planning to implement RMRR "as-is" for arm64, so
you might be better off looking at the proposal from Thierry, although it
has some issues that are still to be resolved:

http://lkml.kernel.org/r/20190829111407.17191-1-thierry.reding@gmail.com

Will