From: Joerg Roedel <joro-zLv9SwRftAIdnm+yROfE0A@public.gmane.org>
To: Mitchel Humpherys <mitchelh-sgV2jX0FEOL9JmXXK+q4OQ@public.gmane.org>
Cc: Will Deacon <will.deacon-5wv7dgnIgG8@public.gmane.org>,
iommu-cunTk1MwBs9QetFLy7KEm3xJsTq8ys+cHZ5vskTnxNA@public.gmane.org,
linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r@public.gmane.org,
Pratik Patel <pratikp-sgV2jX0FEOL9JmXXK+q4OQ@public.gmane.org>
Subject: Re: [PATCH 1/2] iommu: Support dynamic pgsize_bitmap
Date: Thu, 7 Apr 2016 15:24:30 +0200 [thread overview]
Message-ID: <20160407132430.GE31146@8bytes.org> (raw)
In-Reply-To: <1459890090-16040-1-git-send-email-mitchelh-sgV2jX0FEOL9JmXXK+q4OQ@public.gmane.org>
On Tue, Apr 05, 2016 at 02:01:29PM -0700, Mitchel Humpherys wrote:
> Currently we use a single pgsize_bitmap per IOMMU driver. However, some
> IOMMU drivers might service different IOMMUs with different supported
> page sizes. Some drivers might also want to restrict page sizes for
> different use cases. Support these use cases by adding a
> .get_pgsize_bitmap function to the iommu_ops which can optionally be
> used by the driver to return a domain-specific pgsize_bitmap.
No, at least not this way. I said it before and I say it again: We are
not going to lift the iommu-api requirements in this undetectable way.
The iommu-api works with domains/groups and devices. The general
expectation is that every group can be part of every domain. I know that
this is not the case already with some drivers, but I am not going to
move the code further into the wrong direction.
The way I'd like to see that solved is:
* Introduce per-group pgsize-bitmaps (group->pgsize_bmp)
* Calculate a global pgsize-bitmap from all groups
pgsize-bitmaps
* Also store a pgsize_bitmap in each domain on allocation
* Modify iommu_domain_alloc to set domain->pgsize_bmp to the
global pgsize_bitmap
* Introduce an iommu_group_alloc_domain(group) function which
allocates a new domain only for the given group. This function
sets domain->pgsize_bitmap to group->pgsize_bmp.
* Note that now you can have multiple page-tables per domain,
one page-table for each required format.
Regards,
Joerg
WARNING: multiple messages have this Message-ID (diff)
From: joro@8bytes.org (Joerg Roedel)
To: linux-arm-kernel@lists.infradead.org
Subject: [PATCH 1/2] iommu: Support dynamic pgsize_bitmap
Date: Thu, 7 Apr 2016 15:24:30 +0200 [thread overview]
Message-ID: <20160407132430.GE31146@8bytes.org> (raw)
In-Reply-To: <1459890090-16040-1-git-send-email-mitchelh@codeaurora.org>
On Tue, Apr 05, 2016 at 02:01:29PM -0700, Mitchel Humpherys wrote:
> Currently we use a single pgsize_bitmap per IOMMU driver. However, some
> IOMMU drivers might service different IOMMUs with different supported
> page sizes. Some drivers might also want to restrict page sizes for
> different use cases. Support these use cases by adding a
> .get_pgsize_bitmap function to the iommu_ops which can optionally be
> used by the driver to return a domain-specific pgsize_bitmap.
No, at least not this way. I said it before and I say it again: We are
not going to lift the iommu-api requirements in this undetectable way.
The iommu-api works with domains/groups and devices. The general
expectation is that every group can be part of every domain. I know that
this is not the case already with some drivers, but I am not going to
move the code further into the wrong direction.
The way I'd like to see that solved is:
* Introduce per-group pgsize-bitmaps (group->pgsize_bmp)
* Calculate a global pgsize-bitmap from all groups
pgsize-bitmaps
* Also store a pgsize_bitmap in each domain on allocation
* Modify iommu_domain_alloc to set domain->pgsize_bmp to the
global pgsize_bitmap
* Introduce an iommu_group_alloc_domain(group) function which
allocates a new domain only for the given group. This function
sets domain->pgsize_bitmap to group->pgsize_bmp.
* Note that now you can have multiple page-tables per domain,
one page-table for each required format.
Regards,
Joerg
next prev parent reply other threads:[~2016-04-07 13:24 UTC|newest]
Thread overview: 12+ messages / expand[flat|nested] mbox.gz Atom feed top
2016-04-05 21:01 [PATCH 1/2] iommu: Support dynamic pgsize_bitmap Mitchel Humpherys
2016-04-05 21:01 ` Mitchel Humpherys
[not found] ` <1459890090-16040-1-git-send-email-mitchelh-sgV2jX0FEOL9JmXXK+q4OQ@public.gmane.org>
2016-04-05 21:01 ` [PATCH 2/2] iommu/arm-smmu: Implement .get_pgsize_bitmap for domain Mitchel Humpherys
2016-04-05 21:01 ` Mitchel Humpherys
2016-04-06 10:47 ` [PATCH 1/2] iommu: Support dynamic pgsize_bitmap Robin Murphy
2016-04-06 10:47 ` Robin Murphy
[not found] ` <5704E937.3020602-5wv7dgnIgG8@public.gmane.org>
2016-04-07 19:29 ` Mitchel Humpherys
2016-04-07 19:29 ` Mitchel Humpherys
[not found] ` <vnkwzit5w72g.fsf-sgV2jX0FEOL9JmXXK+q4OQ@public.gmane.org>
2016-04-07 19:44 ` Mitchel Humpherys
2016-04-07 19:44 ` Mitchel Humpherys
2016-04-07 13:24 ` Joerg Roedel [this message]
2016-04-07 13:24 ` Joerg Roedel
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=20160407132430.GE31146@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=mitchelh-sgV2jX0FEOL9JmXXK+q4OQ@public.gmane.org \
--cc=pratikp-sgV2jX0FEOL9JmXXK+q4OQ@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.