From: Jason Gunthorpe <jgg@nvidia.com>
To: Dmitry Baryshkov <dmitry.baryshkov@linaro.org>
Cc: iommu@lists.linux.dev, joro@8bytes.org,
linux-arm-kernel@lists.infradead.org, nicolinc@nvidia.com,
robin.murphy@arm.com, will@kernel.org,
linux-arm-msm@vger.kernel.org
Subject: Re: [PATCH v2 5/5] iommu/arm-smmu: Convert to domain_alloc_paging()
Date: Mon, 12 Feb 2024 20:19:34 -0400 [thread overview]
Message-ID: <20240213001934.GF4048826@nvidia.com> (raw)
In-Reply-To: <CAA8EJpqdc3nQmTaWYY4VDE7ChV0NjMgBK7Q0rDRTyKZoWtbreA@mail.gmail.com>
On Tue, Feb 13, 2024 at 01:18:24AM +0200, Dmitry Baryshkov wrote:
> > > For some reason this patch breaks booting of the APQ8096 Dragonboard820c
> > > (qcom/apq8096-db820c.dts). Dispbling display subsystem (mdss) and venus
> > > devices makes the board boot in most of the cases. Most frequently the
> > > last parts of the log loog in a following way:
> >
> > It is surprising we tested this patch on some tegra systems with this
> > iommu and didn't hit anything..
> >
> > The only real functional thing this changes is to move the domain
> > initialization up in time, potentially a lot in time in some
> > cases. That function does alot of things including touching HW so
> > possibly there is some surprising interaction with something else.
> >
> > So, I would expect this to not WARN_ON and to make it work the same as
> > before the patch:
> >
> > --- a/drivers/iommu/arm/arm-smmu/arm-smmu.c
> > +++ b/drivers/iommu/arm/arm-smmu/arm-smmu.c
> > @@ -875,7 +875,9 @@ static struct iommu_domain *arm_smmu_domain_alloc_paging(struct device *dev)
> > mutex_init(&smmu_domain->init_mutex);
> > spin_lock_init(&smmu_domain->cb_lock);
> >
> > - if (dev) {
> > + WARN_ON(using_legacy_binding);
> > +
> > +/* if (dev) {
> > struct arm_smmu_master_cfg *cfg = dev_iommu_priv_get(dev);
> >
> > if (arm_smmu_init_domain_context(smmu_domain, cfg->smmu, dev)) {
> > @@ -883,7 +885,7 @@ static struct iommu_domain *arm_smmu_domain_alloc_paging(struct device *dev)
> > return NULL;
> > }
> > }
> > -
> > +*/
> > return &smmu_domain->domain;
> > }
>
> With the full device tree, this crashed during the IOMMU probe, no warnings:
The above reverts nearly all the functional elements of the patch you
said caused the problem, are you certain of your bisection?
> > And then we may get a clue from the backtraces it generates. I only
> > saw one iommu group reported in your log so I'd expect one trace?
>
> With the full device tree, same result:
This adds basically an unconditional WARN_ON on all the probe paths,
and nothing printed? That is even more surprising.
Those two together suggest that arm_smmu_domain_alloc_paging() isn't
even being called. But the caller is:
if (alloc_type == IOMMU_DOMAIN_IDENTITY && ops->identity_domain)
return ops->identity_domain;
else if (alloc_type == IOMMU_DOMAIN_BLOCKED && ops->blocked_domain)
return ops->blocked_domain;
else if (type & __IOMMU_DOMAIN_PAGING && ops->domain_alloc_paging)
domain = ops->domain_alloc_paging(dev);
else if (ops->domain_alloc)
domain = ops->domain_alloc(alloc_type);
else
return ERR_PTR(-EOPNOTSUPP);
Which, suggest that alloc_type is somehow garbage for your system? I
don't see how that can happen, but this patch will also cause a
garbage type to be rejected by the core code.
Does this reveal anything for you?
@@ -2118,6 +2118,7 @@ static struct iommu_domain *__iommu_domain_alloc(const struct iommu_ops *ops,
struct iommu_domain *domain;
unsigned int alloc_type = type & IOMMU_DOMAIN_ALLOC_FLAGS;
+ WARN(true, " __iommu_domain_alloc %u %u", alloc_type, type);
if (alloc_type == IOMMU_DOMAIN_IDENTITY && ops->identity_domain)
return ops->identity_domain;
else if (alloc_type == IOMMU_DOMAIN_BLOCKED && ops->blocked_domain)
@@ -2126,8 +2127,10 @@ static struct iommu_domain *__iommu_domain_alloc(const struct iommu_ops *ops,
domain = ops->domain_alloc_paging(dev);
else if (ops->domain_alloc)
domain = ops->domain_alloc(alloc_type);
- else
+ else {
+ printk("Returning failure from __iommu_domain_alloc()\n");
return ERR_PTR(-EOPNOTSUPP);
+ }
/*
* Many domain_alloc ops now return ERR_PTR, make things easier for the
It must print, something is wrong with the debugging process if this
doesn't generate back traces :\
Jason
WARNING: multiple messages have this Message-ID (diff)
From: Jason Gunthorpe <jgg@nvidia.com>
To: Dmitry Baryshkov <dmitry.baryshkov@linaro.org>
Cc: iommu@lists.linux.dev, joro@8bytes.org,
linux-arm-kernel@lists.infradead.org, nicolinc@nvidia.com,
robin.murphy@arm.com, will@kernel.org,
linux-arm-msm@vger.kernel.org
Subject: Re: [PATCH v2 5/5] iommu/arm-smmu: Convert to domain_alloc_paging()
Date: Mon, 12 Feb 2024 20:19:34 -0400 [thread overview]
Message-ID: <20240213001934.GF4048826@nvidia.com> (raw)
In-Reply-To: <CAA8EJpqdc3nQmTaWYY4VDE7ChV0NjMgBK7Q0rDRTyKZoWtbreA@mail.gmail.com>
On Tue, Feb 13, 2024 at 01:18:24AM +0200, Dmitry Baryshkov wrote:
> > > For some reason this patch breaks booting of the APQ8096 Dragonboard820c
> > > (qcom/apq8096-db820c.dts). Dispbling display subsystem (mdss) and venus
> > > devices makes the board boot in most of the cases. Most frequently the
> > > last parts of the log loog in a following way:
> >
> > It is surprising we tested this patch on some tegra systems with this
> > iommu and didn't hit anything..
> >
> > The only real functional thing this changes is to move the domain
> > initialization up in time, potentially a lot in time in some
> > cases. That function does alot of things including touching HW so
> > possibly there is some surprising interaction with something else.
> >
> > So, I would expect this to not WARN_ON and to make it work the same as
> > before the patch:
> >
> > --- a/drivers/iommu/arm/arm-smmu/arm-smmu.c
> > +++ b/drivers/iommu/arm/arm-smmu/arm-smmu.c
> > @@ -875,7 +875,9 @@ static struct iommu_domain *arm_smmu_domain_alloc_paging(struct device *dev)
> > mutex_init(&smmu_domain->init_mutex);
> > spin_lock_init(&smmu_domain->cb_lock);
> >
> > - if (dev) {
> > + WARN_ON(using_legacy_binding);
> > +
> > +/* if (dev) {
> > struct arm_smmu_master_cfg *cfg = dev_iommu_priv_get(dev);
> >
> > if (arm_smmu_init_domain_context(smmu_domain, cfg->smmu, dev)) {
> > @@ -883,7 +885,7 @@ static struct iommu_domain *arm_smmu_domain_alloc_paging(struct device *dev)
> > return NULL;
> > }
> > }
> > -
> > +*/
> > return &smmu_domain->domain;
> > }
>
> With the full device tree, this crashed during the IOMMU probe, no warnings:
The above reverts nearly all the functional elements of the patch you
said caused the problem, are you certain of your bisection?
> > And then we may get a clue from the backtraces it generates. I only
> > saw one iommu group reported in your log so I'd expect one trace?
>
> With the full device tree, same result:
This adds basically an unconditional WARN_ON on all the probe paths,
and nothing printed? That is even more surprising.
Those two together suggest that arm_smmu_domain_alloc_paging() isn't
even being called. But the caller is:
if (alloc_type == IOMMU_DOMAIN_IDENTITY && ops->identity_domain)
return ops->identity_domain;
else if (alloc_type == IOMMU_DOMAIN_BLOCKED && ops->blocked_domain)
return ops->blocked_domain;
else if (type & __IOMMU_DOMAIN_PAGING && ops->domain_alloc_paging)
domain = ops->domain_alloc_paging(dev);
else if (ops->domain_alloc)
domain = ops->domain_alloc(alloc_type);
else
return ERR_PTR(-EOPNOTSUPP);
Which, suggest that alloc_type is somehow garbage for your system? I
don't see how that can happen, but this patch will also cause a
garbage type to be rejected by the core code.
Does this reveal anything for you?
@@ -2118,6 +2118,7 @@ static struct iommu_domain *__iommu_domain_alloc(const struct iommu_ops *ops,
struct iommu_domain *domain;
unsigned int alloc_type = type & IOMMU_DOMAIN_ALLOC_FLAGS;
+ WARN(true, " __iommu_domain_alloc %u %u", alloc_type, type);
if (alloc_type == IOMMU_DOMAIN_IDENTITY && ops->identity_domain)
return ops->identity_domain;
else if (alloc_type == IOMMU_DOMAIN_BLOCKED && ops->blocked_domain)
@@ -2126,8 +2127,10 @@ static struct iommu_domain *__iommu_domain_alloc(const struct iommu_ops *ops,
domain = ops->domain_alloc_paging(dev);
else if (ops->domain_alloc)
domain = ops->domain_alloc(alloc_type);
- else
+ else {
+ printk("Returning failure from __iommu_domain_alloc()\n");
return ERR_PTR(-EOPNOTSUPP);
+ }
/*
* Many domain_alloc ops now return ERR_PTR, make things easier for the
It must print, something is wrong with the debugging process if this
doesn't generate back traces :\
Jason
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
next prev parent reply other threads:[~2024-02-13 0:19 UTC|newest]
Thread overview: 50+ messages / expand[flat|nested] mbox.gz Atom feed top
2023-10-17 18:11 [PATCH v2 0/5] Convert SMMU to domain_alloc_paging() Jason Gunthorpe
2023-10-17 18:11 ` Jason Gunthorpe
2023-10-17 18:11 ` [PATCH v2 1/5] iommu/arm-smmu: Reorganize arm_smmu_domain_add_master() Jason Gunthorpe
2023-10-17 18:11 ` Jason Gunthorpe
2023-10-17 18:11 ` [PATCH v2 2/5] iommu/arm-smmu: Convert to a global static identity domain Jason Gunthorpe
2023-10-17 18:11 ` Jason Gunthorpe
2023-12-12 13:27 ` Will Deacon
2023-12-12 13:27 ` Will Deacon
2023-12-12 14:15 ` Jason Gunthorpe
2023-12-12 14:15 ` Jason Gunthorpe
2023-12-13 13:26 ` Will Deacon
2023-12-13 13:26 ` Will Deacon
2023-12-13 13:32 ` Jason Gunthorpe
2023-12-13 13:32 ` Jason Gunthorpe
2023-10-17 18:11 ` [PATCH v2 3/5] iommu/arm-smmu: Implement IOMMU_DOMAIN_BLOCKED Jason Gunthorpe
2023-10-17 18:11 ` Jason Gunthorpe
2023-10-17 18:11 ` [PATCH v2 4/5] iommu/arm-smmu: Pass arm_smmu_domain to internal functions Jason Gunthorpe
2023-10-17 18:11 ` Jason Gunthorpe
2023-10-17 18:11 ` [PATCH v2 5/5] iommu/arm-smmu: Convert to domain_alloc_paging() Jason Gunthorpe
2023-10-17 18:11 ` Jason Gunthorpe
2023-12-12 13:26 ` Will Deacon
2023-12-12 13:26 ` Will Deacon
2023-12-12 14:03 ` Jason Gunthorpe
2023-12-12 14:03 ` Jason Gunthorpe
2023-12-12 14:10 ` Will Deacon
2023-12-12 14:10 ` Will Deacon
2023-12-13 13:27 ` Will Deacon
2023-12-13 13:27 ` Will Deacon
2023-12-13 13:32 ` Jason Gunthorpe
2023-12-13 13:32 ` Jason Gunthorpe
2024-02-09 20:05 ` Dmitry Baryshkov
2024-02-09 20:05 ` Dmitry Baryshkov
2024-02-09 22:23 ` Jason Gunthorpe
2024-02-09 22:23 ` Jason Gunthorpe
2024-02-12 23:18 ` Dmitry Baryshkov
2024-02-12 23:18 ` Dmitry Baryshkov
2024-02-13 0:19 ` Jason Gunthorpe [this message]
2024-02-13 0:19 ` Jason Gunthorpe
2024-02-13 7:51 ` Dmitry Baryshkov
2024-02-13 7:51 ` Dmitry Baryshkov
2024-02-13 10:20 ` Robin Murphy
2024-02-13 10:20 ` Robin Murphy
2024-02-13 10:55 ` Dmitry Baryshkov
2024-02-13 10:55 ` Dmitry Baryshkov
2024-02-13 11:16 ` Will Deacon
2024-02-13 11:16 ` Will Deacon
2024-02-13 11:54 ` Jason Gunthorpe
2024-02-13 11:54 ` Jason Gunthorpe
2023-12-13 17:25 ` [PATCH v2 0/5] Convert SMMU " Will Deacon
2023-12-13 17:25 ` 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=20240213001934.GF4048826@nvidia.com \
--to=jgg@nvidia.com \
--cc=dmitry.baryshkov@linaro.org \
--cc=iommu@lists.linux.dev \
--cc=joro@8bytes.org \
--cc=linux-arm-kernel@lists.infradead.org \
--cc=linux-arm-msm@vger.kernel.org \
--cc=nicolinc@nvidia.com \
--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.