public inbox for linux-arm-kernel@lists.infradead.org 
 help / color / mirror / Atom feed
From: will.deacon@arm•com (Will Deacon)
To: linux-arm-kernel@lists•infradead.org
Subject: [PATCH v2 5/5] iommu: Allow default domain type to be set on the kernel command line
Date: Tue, 21 Mar 2017 18:17:29 +0000	[thread overview]
Message-ID: <20170321181729.GG30948@arm.com> (raw)
In-Reply-To: <807ecbb0-c9d7-fc0a-25d2-93b5c4374107@arm.com>

On Tue, Mar 21, 2017 at 05:46:29PM +0000, Robin Murphy wrote:
> On 21/03/17 17:21, Will Deacon wrote:
> > On Tue, Mar 21, 2017 at 04:45:27PM +0100, Joerg Roedel wrote:
> >> On Fri, Mar 10, 2017 at 08:49:36PM +0000, Will Deacon wrote:
> >>> @@ -1014,8 +1027,8 @@ struct iommu_group *iommu_group_get_for_dev(struct device *dev)
> >>>  	 * IOMMU driver.
> >>>  	 */
> >>>  	if (!group->default_domain) {
> >>> -		group->default_domain = __iommu_domain_alloc(dev->bus,
> >>> -							     IOMMU_DOMAIN_DMA);
> >>> +		group->default_domain =
> >>> +			__iommu_domain_alloc(dev->bus, iommu_def_domain_type);
> >>
> >> It would be good to have a fall-back here if we are talking to an IOMMU
> >> driver that uses default domains, but does not support identity-mapped
> >> domains (yet). Exynos and Rockchip IOMMU drivers seem to fall into this
> >> category. A dev_warn() also makes sense in case allocating a identity
> >> domain fails.
> > 
> > Sure, something like the diff below?
> > 
> > Will
> > 
> > --->8
> > 
> > 
> > diff --git a/drivers/iommu/iommu.c b/drivers/iommu/iommu.c
> > index 42a842e3f95f..f787626a745d 100644
> > --- a/drivers/iommu/iommu.c
> > +++ b/drivers/iommu/iommu.c
> > @@ -1027,10 +1027,19 @@ struct iommu_group *iommu_group_get_for_dev(struct device *dev)
> >  	 * IOMMU driver.
> >  	 */
> >  	if (!group->default_domain) {
> > -		group->default_domain =
> > -			__iommu_domain_alloc(dev->bus, iommu_def_domain_type);
> > +		struct iommu_domain *dom;
> > +
> > +		dom = __iommu_domain_alloc(dev->bus, iommu_def_domain_type);
> > +		if (!dom) {
> > +			dev_warn(dev,
> > +				 "failed to allocate default IOMMU domain of type %u; falling back to IOMMU_DOMAIN_DMA",
> > +				 iommu_def_domain_type);
> 
> Conversely, that's going to be noisy if iommu_def_domain_type was
> IOMMU_DOMAIN_DMA to begin with. I think it makes sense to warn if the
> user asked for a specific default domain type on the command line and
> that didn't work, but maybe not to bother otherwise. Plus, if they asked
> for passthrough, then not allocating a default domain at all is probably
> closer to the desired result than installing a DMA ops domain would be.

You're right -- I'll hack this about to check if the default type isn't
DOMAIN_DMA before warning about the allocation failure.

Cheers,

Will

  reply	other threads:[~2017-03-21 18:17 UTC|newest]

Thread overview: 21+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2017-03-10 20:49 [PATCH v2 0/5] Implement SMMU passthrough using the default domain Will Deacon
2017-03-10 20:49 ` [PATCH v2 1/5] iommu/arm-smmu: Restrict domain attributes to UNMANAGED domains Will Deacon
2017-03-10 20:49 ` [PATCH v2 2/5] iommu/arm-smmu: Install bypass S2CRs for IOMMU_DOMAIN_IDENTITY domains Will Deacon
2017-03-10 20:49 ` [PATCH v2 3/5] iommu/arm-smmu-v3: Make arm_smmu_install_ste_for_dev return void Will Deacon
2017-03-16 16:55   ` Nate Watterson
2017-03-10 20:49 ` [PATCH v2 4/5] iommu/arm-smmu-v3: Install bypass STEs for IOMMU_DOMAIN_IDENTITY domains Will Deacon
2017-03-16 16:24   ` Nate Watterson
2017-03-16 18:19     ` Robin Murphy
2017-03-21 17:08       ` Will Deacon
2017-03-21 17:33         ` Robin Murphy
2017-03-10 20:49 ` [PATCH v2 5/5] iommu: Allow default domain type to be set on the kernel command line Will Deacon
2017-03-21 15:45   ` Joerg Roedel
2017-03-21 17:21     ` Will Deacon
2017-03-21 17:46       ` Robin Murphy
2017-03-21 18:17         ` Will Deacon [this message]
2017-03-23 10:22           ` Sricharan R
2017-03-23 10:38           ` Sricharan R
2017-03-22 11:25       ` Joerg Roedel
2017-03-21 15:46 ` [PATCH v2 0/5] Implement SMMU passthrough using the default domain Joerg Roedel
2017-03-21 16:42   ` Will Deacon
2017-03-21 16:46     ` 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=20170321181729.GG30948@arm.com \
    --to=will.deacon@arm$(echo .)com \
    --cc=linux-arm-kernel@lists$(echo .)infradead.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox