From: Robin Murphy <robin.murphy@arm.com>
To: "chenxiang (M)" <chenxiang66@hisilicon.com>, will@kernel.org
Cc: iommu@lists.linux-foundation.org, linux-arm-kernel@lists.infradead.org
Subject: Re: Consult on ARM SMMU debugfs
Date: Mon, 11 Jan 2021 20:01:48 +0000 [thread overview]
Message-ID: <9a23610f-e0b4-92e6-6da6-3182d481db92@arm.com> (raw)
In-Reply-To: <cd9296f1-a3ea-d8d6-0e14-2cd6f19a17da@hisilicon.com>
On 2021-01-07 02:45, chenxiang (M) wrote:
> Hi Will, Robin or other guys,
>
> When debugging SMMU/SVA issue on huawei ARM64 board, we find that it
> lacks of enough debugfs for ARM SMMU driver (such as
>
> the value of STE/CD which we need to check sometimes). Currently it
> creates top-level iommu directory in debugfs, but there is no debugfs
>
> for ARM SMMU driver specially. Do you know whether ARM have the plan to
> do that recently?
FWIW I don't think I've ever felt the need to need to inspect the Stream
Table on a live system. So far the nature of the STE code has been
simple enough that it's very hard for any given STE to be *wrong* -
either it's set up as expected and thus works fine, or it's not
initialised at all and you get C_BAD_STE, where 99% of the time you then
just cross-reference the Stream ID against the firmware and find that
the DT/IORT is wrong.
Similarly I don't think I've even even *seen* an issue that could be
attributed to a context descriptor, although I appreciate that as we
start landing more PASID and SVA support the scope for that starts to
widen considerably.
Feel free to propose a patch if you believe it would be genuinely useful
and won't just bit-rot into a maintenance burden, but it's not something
that's on our roadmap here.
Thanks,
Robin.
_______________________________________________
iommu mailing list
iommu@lists.linux-foundation.org
https://lists.linuxfoundation.org/mailman/listinfo/iommu
WARNING: multiple messages have this Message-ID (diff)
From: Robin Murphy <robin.murphy@arm.com>
To: "chenxiang (M)" <chenxiang66@hisilicon.com>, will@kernel.org
Cc: iommu@lists.linux-foundation.org,
John Garry <john.garry@huawei.com>,
linux-arm-kernel@lists.infradead.org
Subject: Re: Consult on ARM SMMU debugfs
Date: Mon, 11 Jan 2021 20:01:48 +0000 [thread overview]
Message-ID: <9a23610f-e0b4-92e6-6da6-3182d481db92@arm.com> (raw)
In-Reply-To: <cd9296f1-a3ea-d8d6-0e14-2cd6f19a17da@hisilicon.com>
On 2021-01-07 02:45, chenxiang (M) wrote:
> Hi Will, Robin or other guys,
>
> When debugging SMMU/SVA issue on huawei ARM64 board, we find that it
> lacks of enough debugfs for ARM SMMU driver (such as
>
> the value of STE/CD which we need to check sometimes). Currently it
> creates top-level iommu directory in debugfs, but there is no debugfs
>
> for ARM SMMU driver specially. Do you know whether ARM have the plan to
> do that recently?
FWIW I don't think I've ever felt the need to need to inspect the Stream
Table on a live system. So far the nature of the STE code has been
simple enough that it's very hard for any given STE to be *wrong* -
either it's set up as expected and thus works fine, or it's not
initialised at all and you get C_BAD_STE, where 99% of the time you then
just cross-reference the Stream ID against the firmware and find that
the DT/IORT is wrong.
Similarly I don't think I've even even *seen* an issue that could be
attributed to a context descriptor, although I appreciate that as we
start landing more PASID and SVA support the scope for that starts to
widen considerably.
Feel free to propose a patch if you believe it would be genuinely useful
and won't just bit-rot into a maintenance burden, but it's not something
that's on our roadmap here.
Thanks,
Robin.
_______________________________________________
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:[~2021-01-11 20:01 UTC|newest]
Thread overview: 11+ messages / expand[flat|nested] mbox.gz Atom feed top
2021-01-07 2:45 Consult on ARM SMMU debugfs chenxiang (M)
2021-01-07 2:45 ` chenxiang (M)
2021-01-11 20:01 ` Robin Murphy [this message]
2021-01-11 20:01 ` Robin Murphy
2021-01-15 11:26 ` chenxiang (M)
2021-01-15 11:26 ` chenxiang (M)
2021-01-15 15:14 ` Russell King - ARM Linux admin
2021-01-15 15:14 ` Russell King - ARM Linux admin
2021-01-15 17:17 ` Robin Murphy
2021-01-15 17:17 ` Robin Murphy
2021-02-05 16:52 ` Sai Prakash Ranjan
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=9a23610f-e0b4-92e6-6da6-3182d481db92@arm.com \
--to=robin.murphy@arm.com \
--cc=chenxiang66@hisilicon.com \
--cc=iommu@lists.linux-foundation.org \
--cc=linux-arm-kernel@lists.infradead.org \
--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.