IOMMU Archive on lore.kernel.org
 help / color / Atom feed
From: Rob Clark <robdclark@gmail.com>
To: Robin Murphy <robin.murphy@arm.com>
Cc: Heikki Krogerus <heikki.krogerus@linux.intel.com>,
	Jeffrey Hugo <jeffrey.l.hugo@gmail.com>,
	Rasmus Villemoes <linux@rasmusvillemoes.dk>,
	dri-devel <dri-devel@lists.freedesktop.org>,
	Will Deacon <will@kernel.org>,
	Thomas Gleixner <tglx@linutronix.de>,
	Rob Clark <robdclark@chromium.org>,
	Jonathan Marek <jonathan@marek.ca>,
	"Rafael J. Wysocki" <rafael.j.wysocki@intel.com>,
	Mamta Shukla <mamtashukla555@gmail.com>,
	Bartosz Golaszewski <brgl@bgdev.pl>,
	Joerg Roedel <jroedel@suse.de>, Arnd Bergmann <arnd@arndb.de>,
	Suzuki K Poulose <suzuki.poulose@arm.com>,
	linux-arm-msm <linux-arm-msm@vger.kernel.org>,
	Abhinav Kumar <abhinavk@codeaurora.org>,
	Bruce Wang <bzwang@chromium.org>,
	Alexios Zavras <alexios.zavras@intel.com>,
	Sean Paul <seanpaul@chromium.org>,
	Jeykumar Sankaran <jsanka@codeaurora.org>,
	Allison Randal <allison@lohutok.net>,
	Boris Brezillon <bbrezillon@kernel.org>,
	Greg Kroah-Hartman <gregkh@linuxfoundation.org>,
	open list <linux-kernel@vger.kernel.org>,
	"list@263.net:IOMMU DRIVERS <iommu@lists.linux-foundation.org>,
	Joerg Roedel <joro@8bytes.org>,
	" <iommu@lists.linux-foundation.org>,
	Sudeep Holla <sudeep.holla@arm.com>,
	Joe Perches <joe@perches.com>,
	Andrew Morton <akpm@linux-foundation.org>,
	"open list:DRM DRIVER FOR MSM ADRENO GPU"
	<freedreno@lists.freedesktop.org>,
	Georgi Djakov <georgi.djakov@linaro.org>,
	Sravanthi Kollukuduru <skolluku@codeaurora.org>
Subject: Re: [PATCH v3 0/2] iommu: handle drivers that manage iommu directly
Date: Tue, 10 Sep 2019 10:10:49 -0700
Message-ID: <CAF6AEGv5WtwOuUE-+koL3SxuoXxcT5n=EooD7G_4YRh34HFTwQ@mail.gmail.com> (raw)
In-Reply-To: <c43de10f-7768-592c-0fd8-6fb64b3fd43e@arm.com>

On Tue, Sep 10, 2019 at 9:34 AM Robin Murphy <robin.murphy@arm.com> wrote:
>
> On 06/09/2019 22:44, Rob Clark wrote:
> > From: Rob Clark <robdclark@chromium.org>
> >
> > One of the challenges we have to enable the aarch64 laptops upstream
> > is dealing with the fact that the bootloader enables the display and
> > takes the corresponding SMMU context-bank out of BYPASS.  Unfortunately,
> > currently, the IOMMU framework attaches a DMA (or potentially an
> > IDENTITY) domain before the driver is probed and has a chance to
> > intervene and shutdown scanout.  Which makes things go horribly wrong.
>
> Nope, things already went horribly wrong in arm_smmu_device_reset() -
> sure, sometimes for some configurations it might *seem* like they didn't
> and that you can fudge the context bank state at arm's length from core
> code later, but the truth is that impl->cfg_probe is your last chance to
> guarantee that any necessary SMMU state is preserved.

cfg_probe is where Bjorn's patch is preserving the SMMU state.  So I
think that should ensure device_reset() preserves the configuration..
or at least if something is missing, that seems fixable.

> The remainder of the problem involves reworking default domain
> allocation such that we can converge on what iommu_request_dm_for_dev()
> currently does but without the momentary attachment to a translation
> domain to cause hiccups. That's starting here:
>
> https://lore.kernel.org/linux-iommu/cover.1566353521.git.sai.praneeth.prakhya@intel.com/

I suppose if the stream-match state and bootloader chosen context bank
is preserved, then keeping it direct-mapped would avoid things
starting to fault before display driver is probed.  That plus some
solution for GPU default domain would narrow the scope of what I need
to just avoiding getting iommu dma_ops installed.

> > But in this case, drm/msm is already directly managing it's IOMMUs
> > directly, the DMA API attached iommu_domain simply gets in the way.
> > This series adds a way that a driver can indicate to drivers/iommu
> > that it does not wish to have an DMA managed iommu_domain attached.
> > This way, drm/msm can shut down scanout cleanly before attaching it's
> > own iommu_domain.
> >
> > NOTE that to get things working with arm-smmu on the aarch64 laptops,
> > you also need a patchset[1] from Bjorn Andersson to inherit SMMU config
> > at boot, when it is already enabled.
> >
> > [1] https://www.spinics.net/lists/arm-kernel/msg732246.html
> >
> > 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 am a bit curious about how windows handles this, since they must
have the same problem on these laptops.

> > This perhaps doesn't solve the more general case of bootloader enabled
> > display for drivers that actually want to use DMA API managed IOMMU.
> > But it does also happen to avoid a related problem with GPU, caused by
> > the DMA domain claiming the context bank that the GPU firmware expects
> > to use.
>
> Careful bringing that up again, or I really will rework the context bank
> allocator to avoid this default domain problem entirely... ;)

That doesn't seem like a bad outcome ;-)

BR,
-R

> Robin.
>
> >  And it avoids spurious TLB invalidation coming from the unused
> > DMA domain.  So IMHO this is a useful and necessary change.
> >
> > Rob Clark (2):
> >    iommu: add support for drivers that manage iommu explicitly
> >    drm/msm: mark devices where iommu is managed by driver
> >
> >   drivers/gpu/drm/msm/adreno/adreno_device.c | 1 +
> >   drivers/gpu/drm/msm/disp/dpu1/dpu_kms.c    | 1 +
> >   drivers/gpu/drm/msm/disp/mdp5/mdp5_kms.c   | 1 +
> >   drivers/gpu/drm/msm/msm_drv.c              | 1 +
> >   drivers/iommu/iommu.c                      | 2 +-
> >   drivers/iommu/of_iommu.c                   | 3 +++
> >   include/linux/device.h                     | 3 ++-
> >   7 files changed, 10 insertions(+), 2 deletions(-)
> >
_______________________________________________
iommu mailing list
iommu@lists.linux-foundation.org
https://lists.linuxfoundation.org/mailman/listinfo/iommu

  reply index

Thread overview: 9+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2019-09-06 21:44 Rob Clark
2019-09-06 21:44 ` [PATCH v2 1/2] iommu: add support for drivers that manage iommu explicitly Rob Clark
2019-09-10  8:14   ` Joerg Roedel
2019-09-10 15:34     ` Rob Clark
2019-09-10 16:51       ` Robin Murphy
2019-09-06 21:44 ` [PATCH v2 2/2] drm/msm: mark devices where iommu is managed by driver Rob Clark
2019-09-10 16:34 ` [PATCH v3 0/2] iommu: handle drivers that manage iommu directly Robin Murphy
2019-09-10 17:10   ` Rob Clark [this message]
2019-09-17 13:36     ` Will Deacon

Reply instructions:

You may reply publically to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to='CAF6AEGv5WtwOuUE-+koL3SxuoXxcT5n=EooD7G_4YRh34HFTwQ@mail.gmail.com' \
    --to=robdclark@gmail.com \
    --cc=abhinavk@codeaurora.org \
    --cc=akpm@linux-foundation.org \
    --cc=alexios.zavras@intel.com \
    --cc=allison@lohutok.net \
    --cc=arnd@arndb.de \
    --cc=bbrezillon@kernel.org \
    --cc=brgl@bgdev.pl \
    --cc=bzwang@chromium.org \
    --cc=dri-devel@lists.freedesktop.org \
    --cc=freedreno@lists.freedesktop.org \
    --cc=georgi.djakov@linaro.org \
    --cc=gregkh@linuxfoundation.org \
    --cc=heikki.krogerus@linux.intel.com \
    --cc=iommu@lists.linux-foundation.org \
    --cc=jeffrey.l.hugo@gmail.com \
    --cc=joe@perches.com \
    --cc=jonathan@marek.ca \
    --cc=joro@8bytes.org \
    --cc=jroedel@suse.de \
    --cc=jsanka@codeaurora.org \
    --cc=linux-arm-msm@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux@rasmusvillemoes.dk \
    --cc=mamtashukla555@gmail.com \
    --cc=rafael.j.wysocki@intel.com \
    --cc=robdclark@chromium.org \
    --cc=robin.murphy@arm.com \
    --cc=seanpaul@chromium.org \
    --cc=skolluku@codeaurora.org \
    --cc=sudeep.holla@arm.com \
    --cc=suzuki.poulose@arm.com \
    --cc=tglx@linutronix.de \
    --cc=will@kernel.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link

IOMMU Archive on lore.kernel.org

Archives are clonable:
	git clone --mirror https://lore.kernel.org/linux-iommu/0 linux-iommu/git/0.git

	# If you have public-inbox 1.1+ installed, you may
	# initialize and index your mirror using the following commands:
	public-inbox-init -V2 linux-iommu linux-iommu/ https://lore.kernel.org/linux-iommu \
		iommu@lists.linux-foundation.org iommu@archiver.kernel.org
	public-inbox-index linux-iommu

Example config snippet for mirrors

Newsgroup available over NNTP:
	nntp://nntp.lore.kernel.org/org.linux-foundation.lists.iommu


AGPL code for this site: git clone https://public-inbox.org/ public-inbox