From: Robin Murphy <robin.murphy@arm.com>
To: Will Deacon <will@kernel.org>, Peter Griffin <peter.griffin@linaro.org>
Cc: "Joerg Roedel (AMD)" <joro@8bytes.org>,
Rob Herring <robh@kernel.org>,
Krzysztof Kozlowski <krzk+dt@kernel.org>,
Conor Dooley <conor+dt@kernel.org>,
Pranjal Shrivastava <praan@google.com>,
Daniel Mentz <danielmentz@google.com>,
Mostafa Saleh <smostafa@google.com>,
linux-arm-kernel@lists.infradead.org, iommu@lists.linux.dev,
devicetree@vger.kernel.org, linux-kernel@vger.kernel.org,
kernel-team@android.com, tudor.ambarus@linaro.org,
andre.draszik@linaro.org, willmcvicker@google.com,
jyescas@google.com
Subject: Re: [PATCH 0/2] Add arm-smmu-v3 support for instcfg data override feature
Date: Mon, 27 Jul 2026 11:53:37 +0100 [thread overview]
Message-ID: <0b7c0272-5506-4aee-82b3-76a78f2b39dc@arm.com> (raw)
In-Reply-To: <amYIuhYenP4-qHyV@willie-the-truck>
On 26/07/2026 2:16 pm, Will Deacon wrote:
> On Fri, Jul 24, 2026 at 01:39:41PM +0100, Peter Griffin wrote:
>> These two patches add support for a new "arm,instdata-override" DT property
>> that enables the override of the instruction/data attribute of incoming
>> traffic to Data by setting the INSTCFG override bits.
>>
>> It is intended to be specified when the smmu can't guarantee that these
>> attributes are provided correctly from the client device.
>
> This is going to need an in-tree user and a much more detailed
> description of what is being worked around before we consider this for
> inclusion.
>
> In particular, if a particular client is emitting data reads as
> instructions, then a better work around would be to avoid mapping its
> domains using IOMMU_NOEXEC. But I can't tell what's going on from the
> limited description provided here.
Unless it's also emitting the privileged bit and thus falling foul of
the implicit Unpriv-W -> Priv-XN rule, but then we also have the means
to deal with devices which actually do that themselves (hello pl330...),
so that would seemingly only leave the case of some innocent piece of
AMBA-interfaced IP which doesn't expect to need special attributes, but
the system integrator has gone out of their way to tie the AxPROT bits
to some wacky value, which I would put in "erratum workaround" territory.
Thanks,
Robin.
prev parent reply other threads:[~2026-07-27 10:53 UTC|newest]
Thread overview: 6+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-07-24 12:39 [PATCH 0/2] Add arm-smmu-v3 support for instcfg data override feature Peter Griffin
2026-07-24 12:39 ` [PATCH 1/2] dt-bindings: iommu: add arm,instdata-override property documentation Peter Griffin
2026-07-24 12:39 ` [PATCH 2/2] iommu/arm-smmu-v3: Override for Inst/Data attribute Peter Griffin
2026-07-24 18:04 ` Nicolin Chen
2026-07-26 13:16 ` [PATCH 0/2] Add arm-smmu-v3 support for instcfg data override feature Will Deacon
2026-07-27 10:53 ` Robin Murphy [this message]
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=0b7c0272-5506-4aee-82b3-76a78f2b39dc@arm.com \
--to=robin.murphy@arm.com \
--cc=andre.draszik@linaro.org \
--cc=conor+dt@kernel.org \
--cc=danielmentz@google.com \
--cc=devicetree@vger.kernel.org \
--cc=iommu@lists.linux.dev \
--cc=joro@8bytes.org \
--cc=jyescas@google.com \
--cc=kernel-team@android.com \
--cc=krzk+dt@kernel.org \
--cc=linux-arm-kernel@lists.infradead.org \
--cc=linux-kernel@vger.kernel.org \
--cc=peter.griffin@linaro.org \
--cc=praan@google.com \
--cc=robh@kernel.org \
--cc=smostafa@google.com \
--cc=tudor.ambarus@linaro.org \
--cc=will@kernel.org \
--cc=willmcvicker@google.com \
/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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox