All of lore.kernel.org
 help / color / mirror / Atom feed
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

  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.