From: Joonwon Kang <joonwonkang@google.com>
To: robin.murphy@arm.com
Cc: baolu.lu@linux.intel.com, cychu@google.com, hhchung@google.com,
iommu@lists.linux.dev, jgg@ziepe.ca, joonwonkang@google.com,
joro@8bytes.org, jpb@kernel.org,
linux-arm-kernel@lists.infradead.org,
linux-kernel@vger.kernel.org, stimim@google.com,
will@kernel.org
Subject: Re: [QUESTION] Is the ARM SMMU v3 implementation designed to always ignore SSID when SSID_VALID == 0?
Date: Tue, 28 Apr 2026 12:51:39 +0000 [thread overview]
Message-ID: <20260428125139.1627369-1-joonwonkang@google.com> (raw)
In-Reply-To: <d860b6a9-e4a9-494f-821d-8b0a347e1591@arm.com>
> On 28/04/2026 12:14 pm, Joonwon Kang wrote:
> > Thanks for your prompt and insightful answer!
> >
> >> Hi,
> >>
> >> On Tue, Apr 28, 2026 at 07:38:59AM +0000, Joonwon Kang wrote:
> >>> Hi team,
> >>>
> >>> According to the ARM SMMU v3 spec, I believe that SSID should always be
> >>> ignored when SSID_VALID == 0 and the current ARM SMMU v3 module
> >>> implementation in the kernel seems to comply with this without exception.
> >>> For example, when handling an event from SMMU, the implementation checks
> >>> SSID_VALID(SSV) first and ignores SSID accordingly. If there is any
> >>> exception to this rule, I believe it is a bug.
> >>
> >> Indeed
> >
> > Acknowledged.
> >
> >>
> >>> Is it true for all the current and future cases? In other words, is it
> >>> **mandatory** that the ARM SMMU v3 implementation ignores SSID when
> >>> SSID_VALID == 0? or there might be some cases where the implementation
> >>> needs to refer to SSID even when SSID_VALID == 0?
> >>>
> >>> Asking this question since our HW may not be able to clear SSID when
> >>> SSID_VALID == 0 and so there might be some garbage value in SSID at some
> >>> point of time(the HW will have a correct SSID when SSID_VALID == 1,
> >>> though). If the ARM SMMU v3 implementation is to refer to that garbage
> >>> value for any reason, the result would be devastating.
> >>
> >> At least according to the architecture, SubstreamID is ignored when SSV=0.
> >> The SMMU is allowed to propagate the garbage:
> >>
> >> 7.3 Event record
> >>
> >> * SSV: The SubstreamID validity flag
> >> - 0: No SubstreamID was provided with the transaction and the SubstreamID field is UNKNOWN.
> >>
> >> But the driver will ignore it.
> >>
> >> Same for PRI queue but in that case the page request wouldn't have a PASID
> >> TLP prefix.
> >
> > Although the PRI request without PASID may cause unpleasant ATC flush with
> > SSV clear in this case, it does not lead to the implementation referring
> > to the garbage SSID. Is this understanding correct? And while this case
> > seems to be handled solely by the ARM SMMU v3 implementation, do you see
> > if there is additional care required on our device driver for this?
>
> A transaction with SSV==0 does not have a SubstreamID, therefore by
> definition there is nothing that an SMMU could validly attempt to do
> with a SubstreamID that does not exist. Sure, implementations can have
> bugs, but I'd expect any such bug in this regard should be sufficiently
> obvious that it most likely wouldn't get past architectural validation
> in the first place.
>
It makes a lot of sense.
> If you want to know the exact behaviour of Arm's implementations then
> you're best off asking Arm support, but since this piqued my curiosity
> too, I can save you the trouble - I checked with my contacts on the
> design team, and indeed our SMMUs should ignore the SSID value entirely
> when SSV==0 and just treat it as 0 (e.g. in event records).
Thank you very much for saving me the effort and confirming this. I also
acknowledge that it will be best to ask the Arm support with regards to
the exact behavior of Arm's implementation.
Thanks,
Joonwon Kang
prev parent reply other threads:[~2026-04-28 12:51 UTC|newest]
Thread overview: 5+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-04-28 7:38 [QUESTION] Is the ARM SMMU v3 implementation designed to always ignore SSID when SSID_VALID == 0? Joonwon Kang
2026-04-28 9:05 ` Jean-Philippe Brucker
2026-04-28 11:14 ` Joonwon Kang
2026-04-28 12:15 ` Robin Murphy
2026-04-28 12:51 ` Joonwon Kang [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=20260428125139.1627369-1-joonwonkang@google.com \
--to=joonwonkang@google.com \
--cc=baolu.lu@linux.intel.com \
--cc=cychu@google.com \
--cc=hhchung@google.com \
--cc=iommu@lists.linux.dev \
--cc=jgg@ziepe.ca \
--cc=joro@8bytes.org \
--cc=jpb@kernel.org \
--cc=linux-arm-kernel@lists.infradead.org \
--cc=linux-kernel@vger.kernel.org \
--cc=robin.murphy@arm.com \
--cc=stimim@google.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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox