All of lore.kernel.org
 help / color / mirror / Atom feed
From: Thierry Reding <thierry.reding@gmail.com>
To: Rob Herring <robh@kernel.org>
Cc: Joerg Roedel <joro@8bytes.org>,
	Frank Rowand <frowand.list@gmail.com>,
	Will Deacon <will@kernel.org>,
	Robin Murphy <robin.murphy@arm.com>,
	iommu@lists.linux-foundation.org, devicetree@vger.kernel.org,
	linux-kernel@vger.kernel.org
Subject: Re: [PATCH v2 1/4] dt-bindings: reserved-memory: Document "active" property
Date: Thu, 24 Sep 2020 13:27:25 +0200	[thread overview]
Message-ID: <20200924112725.GA2486709@ulmo> (raw)
In-Reply-To: <20200915123648.GA3496938@ulmo>

[-- Attachment #1: Type: text/plain, Size: 2374 bytes --]

On Tue, Sep 15, 2020 at 02:36:48PM +0200, Thierry Reding wrote:
> On Mon, Sep 14, 2020 at 04:08:29PM -0600, Rob Herring wrote:
> > On Fri, Sep 04, 2020 at 02:59:57PM +0200, Thierry Reding wrote:
> > > From: Thierry Reding <treding@nvidia.com>
> > > 
> > > Reserved memory regions can be marked as "active" if hardware is
> > > expected to access the regions during boot and before the operating
> > > system can take control. One example where this is useful is for the
> > > operating system to infer whether the region needs to be identity-
> > > mapped through an IOMMU.
> > 
> > I like simple solutions, but this hardly seems adequate to solve the 
> > problem of passing IOMMU setup from bootloader/firmware to the OS. Like 
> > what is the IOVA that's supposed to be used if identity mapping is not 
> > used?
> 
> The assumption here is that if the region is not active there is no need
> for the IOVA to be specified because the kernel will allocate memory and
> assign any IOVA of its choosing.
> 
> Also, note that this is not meant as a way of passing IOMMU setup from
> the bootloader or firmware to the OS. The purpose of this is to specify
> that some region of memory is actively being accessed during boot. The
> particular case that I'm looking at is where the bootloader set up a
> splash screen and keeps it on during boot. The bootloader has not set up
> an IOMMU mapping and the identity mapping serves as a way of keeping the
> accesses by the display hardware working during the transitional period
> after the IOMMU translations have been enabled by the kernel but before
> the kernel display driver has had a chance to set up its own IOMMU
> mappings.
> 
> > If you know enough about the regions to assume identity mapping, then 
> > can't you know if active or not?
> 
> We could alternatively add some property that describes the region as
> requiring an identity mapping. But note that we can't make any
> assumptions here about the usage of these regions because the IOMMU
> driver simply has no way of knowing what they are being used for.
> 
> Some additional information is required in device tree for the IOMMU
> driver to be able to make that decision.

Rob, can you provide any hints on exactly how you want to move this
forward? I don't know in what direction you'd like to proceed.

Thierry

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 833 bytes --]

WARNING: multiple messages have this Message-ID (diff)
From: Thierry Reding <thierry.reding@gmail.com>
To: Rob Herring <robh@kernel.org>
Cc: devicetree@vger.kernel.org, Frank Rowand <frowand.list@gmail.com>,
	Robin Murphy <robin.murphy@arm.com>,
	linux-kernel@vger.kernel.org, iommu@lists.linux-foundation.org,
	Will Deacon <will@kernel.org>
Subject: Re: [PATCH v2 1/4] dt-bindings: reserved-memory: Document "active" property
Date: Thu, 24 Sep 2020 13:27:25 +0200	[thread overview]
Message-ID: <20200924112725.GA2486709@ulmo> (raw)
In-Reply-To: <20200915123648.GA3496938@ulmo>


[-- Attachment #1.1: Type: text/plain, Size: 2374 bytes --]

On Tue, Sep 15, 2020 at 02:36:48PM +0200, Thierry Reding wrote:
> On Mon, Sep 14, 2020 at 04:08:29PM -0600, Rob Herring wrote:
> > On Fri, Sep 04, 2020 at 02:59:57PM +0200, Thierry Reding wrote:
> > > From: Thierry Reding <treding@nvidia.com>
> > > 
> > > Reserved memory regions can be marked as "active" if hardware is
> > > expected to access the regions during boot and before the operating
> > > system can take control. One example where this is useful is for the
> > > operating system to infer whether the region needs to be identity-
> > > mapped through an IOMMU.
> > 
> > I like simple solutions, but this hardly seems adequate to solve the 
> > problem of passing IOMMU setup from bootloader/firmware to the OS. Like 
> > what is the IOVA that's supposed to be used if identity mapping is not 
> > used?
> 
> The assumption here is that if the region is not active there is no need
> for the IOVA to be specified because the kernel will allocate memory and
> assign any IOVA of its choosing.
> 
> Also, note that this is not meant as a way of passing IOMMU setup from
> the bootloader or firmware to the OS. The purpose of this is to specify
> that some region of memory is actively being accessed during boot. The
> particular case that I'm looking at is where the bootloader set up a
> splash screen and keeps it on during boot. The bootloader has not set up
> an IOMMU mapping and the identity mapping serves as a way of keeping the
> accesses by the display hardware working during the transitional period
> after the IOMMU translations have been enabled by the kernel but before
> the kernel display driver has had a chance to set up its own IOMMU
> mappings.
> 
> > If you know enough about the regions to assume identity mapping, then 
> > can't you know if active or not?
> 
> We could alternatively add some property that describes the region as
> requiring an identity mapping. But note that we can't make any
> assumptions here about the usage of these regions because the IOMMU
> driver simply has no way of knowing what they are being used for.
> 
> Some additional information is required in device tree for the IOMMU
> driver to be able to make that decision.

Rob, can you provide any hints on exactly how you want to move this
forward? I don't know in what direction you'd like to proceed.

Thierry

[-- Attachment #1.2: signature.asc --]
[-- Type: application/pgp-signature, Size: 833 bytes --]

[-- Attachment #2: Type: text/plain, Size: 156 bytes --]

_______________________________________________
iommu mailing list
iommu@lists.linux-foundation.org
https://lists.linuxfoundation.org/mailman/listinfo/iommu

  reply	other threads:[~2020-09-24 11:27 UTC|newest]

Thread overview: 48+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2020-09-04 12:59 [PATCH v2 1/4] dt-bindings: reserved-memory: Document "active" property Thierry Reding
2020-09-04 12:59 ` Thierry Reding
2020-09-04 12:59 ` [PATCH v2 2/4] iommu: Implement of_iommu_get_resv_regions() Thierry Reding
2020-09-04 12:59   ` Thierry Reding
2020-09-04 12:59 ` [PATCH v2 3/4] iommu: dma: Use of_iommu_get_resv_regions() Thierry Reding
2020-09-04 12:59   ` Thierry Reding
2020-09-04 13:00 ` [RFC 4/4] iommu/tegra-smmu: Add support for reserved regions Thierry Reding
2020-09-04 13:00   ` Thierry Reding
2020-09-14 22:08 ` [PATCH v2 1/4] dt-bindings: reserved-memory: Document "active" property Rob Herring
2020-09-14 22:08   ` Rob Herring
2020-09-15 12:36   ` Thierry Reding
2020-09-15 12:36     ` Thierry Reding
2020-09-24 11:27     ` Thierry Reding [this message]
2020-09-24 11:27       ` Thierry Reding
2020-11-05 16:43       ` Thierry Reding
2020-11-05 16:43         ` Thierry Reding
2020-11-05 17:47         ` Robin Murphy
2020-11-05 17:47           ` Robin Murphy
2020-11-06 15:25           ` Thierry Reding
2020-11-06 15:25             ` Thierry Reding
2020-11-10 19:33             ` Thierry Reding
2020-11-10 19:33               ` Thierry Reding
2020-12-17 15:00               ` Thierry Reding
2020-12-17 15:00                 ` Thierry Reding
2020-12-18 22:15                 ` Rob Herring
2020-12-18 22:15                   ` Rob Herring
2020-12-19  0:49                   ` Thierry Reding
2020-12-19  0:49                     ` Thierry Reding
2020-09-24 13:23 ` Dmitry Osipenko
2020-09-24 13:23   ` Dmitry Osipenko
2020-09-24 14:01   ` Thierry Reding
2020-09-24 14:01     ` Thierry Reding
2020-09-24 16:23     ` Dmitry Osipenko
2020-09-24 16:23       ` Dmitry Osipenko
2020-09-25 12:39       ` Robin Murphy
2020-09-25 12:39         ` Robin Murphy
2020-09-25 13:21         ` Dmitry Osipenko
2020-09-25 13:21           ` Dmitry Osipenko
2020-11-05 16:23           ` Thierry Reding
2020-11-05 16:23             ` Thierry Reding
2020-09-25 13:52         ` Dmitry Osipenko
2020-09-25 13:52           ` Dmitry Osipenko
2020-11-05 15:57         ` Thierry Reding
2020-11-05 15:57           ` Thierry Reding
2020-11-05 15:49       ` Thierry Reding
2020-11-05 15:49         ` Thierry Reding
2021-01-12 19:00         ` Dmitry Osipenko
2021-01-12 19:00           ` Dmitry Osipenko

Reply instructions:

You may reply publicly 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=20200924112725.GA2486709@ulmo \
    --to=thierry.reding@gmail.com \
    --cc=devicetree@vger.kernel.org \
    --cc=frowand.list@gmail.com \
    --cc=iommu@lists.linux-foundation.org \
    --cc=joro@8bytes.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=robh@kernel.org \
    --cc=robin.murphy@arm.com \
    --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
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.