All of lore.kernel.org
 help / color / mirror / Atom feed
From: Joerg Roedel <joro-zLv9SwRftAIdnm+yROfE0A@public.gmane.org>
To: Will Deacon <will.deacon-5wv7dgnIgG8@public.gmane.org>
Cc: "iommu-cunTk1MwBs9QetFLy7KEm3xJsTq8ys+cHZ5vskTnxNA@public.gmane.org"
	<iommu-cunTk1MwBs9QetFLy7KEm3xJsTq8ys+cHZ5vskTnxNA@public.gmane.org>,
	"linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r@public.gmane.org"
	<linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r@public.gmane.org>
Subject: Re: [PATCH 2/3] iommu/arm-smmu: Add initial driver support for ARM SMMUv3 devices
Date: Tue, 2 Jun 2015 09:39:56 +0200	[thread overview]
Message-ID: <20150602073956.GG20384@8bytes.org> (raw)
In-Reply-To: <20150601094014.GC1641-5wv7dgnIgG8@public.gmane.org>

Hi Will,

On Mon, Jun 01, 2015 at 10:40:14AM +0100, Will Deacon wrote:
> I like this proposal. The only remaining part is that the pgsize bitmap
> inherited by the domain can only truly be finalised once the page table
> is allocated, which in turn can only happen once we've identified the
> IOMMU instance.

We know the IOMMU instance for domains allocted with
iommu_domain_alloc_for_group because every group is behind a single
IOMMU instance. So the page-table can be allocated at domain creation
time and mappings can be created before the group itself is attached.

> In the case of iommu_domain_alloc_for_group, that's nice and
> straightforward (i.e. as part of the call) but for the default
> iommu_domain_alloc() case, we'd have to continue postponing things to
> ->attach time before we could provide a reliable pgsize_bitmap. This is
> to handle the case where an SMMU may be able to support only a subset of
> the pgsize_bitmap on a per-domain basis.

I don't think we need to postpone anything. Domains returned by
iommu_domain_alloc() need to work for all groups. If there are multiple
IOMMUs in the system with different capabilities/page-table formats the
IOMMU core needs to build multiple page-tables for that domain.

VFIO already does that as a workaround of how things are done currently,
but I really think this should be done in the IOMMU core code.

> In which situation do you think the merged pgsize_bitmap would get used?
> The only place I can think of is if we're trying to call iommu_map on a
> domain with no devices attached. However, if that domain was created
> using iommu_domain_alloc() then the pgsize_bitmap is the least of our
> worries -- we don't even know the page table format!

The first usecase for the merged pgsize_bitmap that comes to mind is to
determine the minimum page-size that can be used for a domain. In the
SMMUv3 case when there are IOMMUs with different minium page-sizes in one
system, this would be the biggest minimum page-size of all IOMMUs.

Probably there are other uses for that bitmap that show up at
implementation time.


	Joerg

WARNING: multiple messages have this Message-ID (diff)
From: joro@8bytes.org (Joerg Roedel)
To: linux-arm-kernel@lists.infradead.org
Subject: [PATCH 2/3] iommu/arm-smmu: Add initial driver support for ARM SMMUv3 devices
Date: Tue, 2 Jun 2015 09:39:56 +0200	[thread overview]
Message-ID: <20150602073956.GG20384@8bytes.org> (raw)
In-Reply-To: <20150601094014.GC1641@arm.com>

Hi Will,

On Mon, Jun 01, 2015 at 10:40:14AM +0100, Will Deacon wrote:
> I like this proposal. The only remaining part is that the pgsize bitmap
> inherited by the domain can only truly be finalised once the page table
> is allocated, which in turn can only happen once we've identified the
> IOMMU instance.

We know the IOMMU instance for domains allocted with
iommu_domain_alloc_for_group because every group is behind a single
IOMMU instance. So the page-table can be allocated at domain creation
time and mappings can be created before the group itself is attached.

> In the case of iommu_domain_alloc_for_group, that's nice and
> straightforward (i.e. as part of the call) but for the default
> iommu_domain_alloc() case, we'd have to continue postponing things to
> ->attach time before we could provide a reliable pgsize_bitmap. This is
> to handle the case where an SMMU may be able to support only a subset of
> the pgsize_bitmap on a per-domain basis.

I don't think we need to postpone anything. Domains returned by
iommu_domain_alloc() need to work for all groups. If there are multiple
IOMMUs in the system with different capabilities/page-table formats the
IOMMU core needs to build multiple page-tables for that domain.

VFIO already does that as a workaround of how things are done currently,
but I really think this should be done in the IOMMU core code.

> In which situation do you think the merged pgsize_bitmap would get used?
> The only place I can think of is if we're trying to call iommu_map on a
> domain with no devices attached. However, if that domain was created
> using iommu_domain_alloc() then the pgsize_bitmap is the least of our
> worries -- we don't even know the page table format!

The first usecase for the merged pgsize_bitmap that comes to mind is to
determine the minimum page-size that can be used for a domain. In the
SMMUv3 case when there are IOMMUs with different minium page-sizes in one
system, this would be the biggest minimum page-size of all IOMMUs.

Probably there are other uses for that bitmap that show up at
implementation time.


	Joerg

  parent reply	other threads:[~2015-06-02  7:39 UTC|newest]

Thread overview: 40+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2015-05-08 18:00 [PATCH 0/3] iommu/arm-smmu: Add driver for ARM SMMUv3 devices Will Deacon
2015-05-08 18:00 ` Will Deacon
     [not found] ` <1431108046-9675-1-git-send-email-will.deacon-5wv7dgnIgG8@public.gmane.org>
2015-05-08 18:00   ` [PATCH 1/3] Documentation: dt-bindings: Add device-tree binding for ARM SMMUv3 IOMMU Will Deacon
2015-05-08 18:00     ` Will Deacon
2015-05-08 18:00   ` [PATCH 2/3] iommu/arm-smmu: Add initial driver support for ARM SMMUv3 devices Will Deacon
2015-05-08 18:00     ` Will Deacon
     [not found]     ` <1431108046-9675-3-git-send-email-will.deacon-5wv7dgnIgG8@public.gmane.org>
2015-05-12  7:40       ` leizhen
2015-05-12  7:40         ` leizhen
     [not found]         ` <5551AE56.6050906-hv44wF8Li93QT0dZR+AlfA@public.gmane.org>
2015-05-12 16:55           ` Will Deacon
2015-05-12 16:55             ` Will Deacon
     [not found]             ` <20150512165500.GE2062-5wv7dgnIgG8@public.gmane.org>
2015-05-13  8:33               ` leizhen
2015-05-13  8:33                 ` leizhen
     [not found]                 ` <55530C4F.5000605-hv44wF8Li93QT0dZR+AlfA@public.gmane.org>
2015-05-21 11:25                   ` Will Deacon
2015-05-21 11:25                     ` Will Deacon
     [not found]                     ` <20150521112555.GH21920-5wv7dgnIgG8@public.gmane.org>
2015-05-25  2:07                       ` leizhen
2015-05-25  2:07                         ` leizhen
     [not found]                         ` <556283D5.4030901-hv44wF8Li93QT0dZR+AlfA@public.gmane.org>
2015-05-26 16:12                           ` Will Deacon
2015-05-26 16:12                             ` Will Deacon
     [not found]                             ` <20150526161245.GR1565-5wv7dgnIgG8@public.gmane.org>
2015-05-27  9:12                               ` leizhen
2015-05-27  9:12                                 ` leizhen
2015-05-19 15:24       ` Joerg Roedel
2015-05-19 15:24         ` Joerg Roedel
     [not found]         ` <20150519152435.GL20611-zLv9SwRftAIdnm+yROfE0A@public.gmane.org>
2015-05-20 17:09           ` Will Deacon
2015-05-20 17:09             ` Will Deacon
     [not found]             ` <20150520170926.GI11498-5wv7dgnIgG8@public.gmane.org>
2015-05-29  6:43               ` Joerg Roedel
2015-05-29  6:43                 ` Joerg Roedel
     [not found]                 ` <20150529064337.GN20611-zLv9SwRftAIdnm+yROfE0A@public.gmane.org>
2015-05-29 11:35                   ` Robin Murphy
2015-05-29 11:35                     ` Robin Murphy
     [not found]                     ` <55684F1C.3050702-5wv7dgnIgG8@public.gmane.org>
2015-05-29 14:40                       ` Joerg Roedel
2015-05-29 14:40                         ` Joerg Roedel
     [not found]                         ` <20150529144043.GA20384-zLv9SwRftAIdnm+yROfE0A@public.gmane.org>
2015-06-01  9:40                           ` Will Deacon
2015-06-01  9:40                             ` Will Deacon
     [not found]                             ` <20150601094014.GC1641-5wv7dgnIgG8@public.gmane.org>
2015-06-02  7:39                               ` Joerg Roedel [this message]
2015-06-02  7:39                                 ` Joerg Roedel
     [not found]                                 ` <20150602073956.GG20384-zLv9SwRftAIdnm+yROfE0A@public.gmane.org>
2015-06-02  9:47                                   ` Will Deacon
2015-06-02  9:47                                     ` Will Deacon
     [not found]                                     ` <20150602094746.GC22569-5wv7dgnIgG8@public.gmane.org>
2015-06-02 18:43                                       ` Joerg Roedel
2015-06-02 18:43                                         ` Joerg Roedel
2015-05-08 18:00   ` [PATCH 3/3] drivers/vfio: Allow type-1 IOMMU instantiation on top of an ARM SMMUv3 Will Deacon
2015-05-08 18:00     ` Will Deacon

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=20150602073956.GG20384@8bytes.org \
    --to=joro-zlv9swrftaidnm+yrofe0a@public.gmane.org \
    --cc=iommu-cunTk1MwBs9QetFLy7KEm3xJsTq8ys+cHZ5vskTnxNA@public.gmane.org \
    --cc=linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r@public.gmane.org \
    --cc=will.deacon-5wv7dgnIgG8@public.gmane.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.