linux-kernel - Re: [PATCH v2] iommu: add support for drivers that manage iommu explicitly

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: <20190723153822.gm4ossn43nvqbyak@willie-the-truck>
Date:   Tue, 23 Jul 2019 16:38:23 +0100
From:   Will Deacon <will@...nel.org>
To:     Rob Clark <robdclark@...il.com>
Cc:     Joerg Roedel <joro@...tes.org>,
        "list@....net:IOMMU DRIVERS <iommu@...ts.linux-foundation.org>, Joerg
        Roedel <joro@...tes.org>," <iommu@...ts.linux-foundation.org>,
        linux-arm-msm <linux-arm-msm@...r.kernel.org>,
        aarch64-laptops@...ts.linaro.org,
        Rob Clark <robdclark@...omium.org>,
        Robin Murphy <robin.murphy@....com>,
        Greg Kroah-Hartman <gregkh@...uxfoundation.org>,
        "Rafael J. Wysocki" <rafael.j.wysocki@...el.com>,
        Rasmus Villemoes <linux@...musvillemoes.dk>,
        Andy Shevchenko <andy.shevchenko@...il.com>,
        Andrew Morton <akpm@...ux-foundation.org>,
        Heikki Krogerus <heikki.krogerus@...ux.intel.com>,
        Bartosz Golaszewski <brgl@...ev.pl>,
        Sudeep Holla <sudeep.holla@....com>,
        Joe Perches <joe@...ches.com>,
        "moderated list:ARM/FREESCALE IMX / MXC ARM ARCHITECTURE" 
        <linux-arm-kernel@...ts.infradead.org>,
        Linux Kernel Mailing List <linux-kernel@...r.kernel.org>,
        Bjorn Andersson <bjorn.andersson@...aro.org>
Subject: Re: [PATCH v2] iommu: add support for drivers that manage iommu
 explicitly

On Mon, Jul 22, 2019 at 09:23:48AM -0700, Rob Clark wrote:
> On Mon, Jul 22, 2019 at 8:48 AM Joerg Roedel <joro@...tes.org> wrote:
> >
> > On Mon, Jul 22, 2019 at 08:41:34AM -0700, Rob Clark wrote:
> > > It is set by the driver:
> > >
> > > https://patchwork.freedesktop.org/patch/315291/
> > >
> > > (This doesn't really belong in devicetree, since it isn't a
> > > description of the hardware, so the driver is really the only place to
> > > set this.. which is fine because it is about a detail of how the
> > > driver works.)
> >
> > It is more a detail about how the firmware works. IIUC the problem is
> > that the firmware initializes the context mappings for the GPU and the
> > OS doesn't know anything about that and just overwrites them, causing
> > the firmware GPU driver to fail badly.
> >
> > So I think it is the task of the firmware to tell the OS not to touch
> > the devices mappings until the OS device driver takes over. On x86 there
> > is something similar with the RMRR/unity-map tables from the firmware.
> >
> 
> Bjorn had a patchset[1] to inherit the config from firmware/bootloader
> when arm-smmu is probed which handles that part of the problem.  My
> patch is intended to be used on top of his patchset.  This seems to me
> like the best solution, if we don't have control over the firmware.

Hmm, but the feedback from Robin on the thread you cite was that this should
be generalised to look more like RMRR, so there seems to be a clear message
here.

Will