From: Nicolin Chen <nicolinc@nvidia.com>
To: Robin Murphy <robin.murphy@arm.com>
Cc: <will@kernel.org>, <joro@8bytes.org>, <iommu@lists.linux.dev>,
<linux-arm-kernel@lists.infradead.org>,
<jean-philippe@linaro.org>
Subject: Re: [PATCH 2/4] iommu/arm-smmu-v3: Document MMU-700 erratum 2812531
Date: Mon, 15 May 2023 08:44:05 -0700 [thread overview]
Message-ID: <ZGJTRc+LYFFX9Sw0@Asurada-Nvidia> (raw)
In-Reply-To: <a45be5e3-c605-f93a-f523-1bb1f6150986@arm.com>
On Fri, May 12, 2023 at 08:23:54PM +0100, Robin Murphy wrote:
> On 2023-05-10 19:31, Nicolin Chen wrote:
> > On Wed, May 10, 2023 at 11:12:05AM -0700, Nicolin Chen wrote:
> > > On Wed, May 10, 2023 at 04:38:44PM +0100, Robin Murphy wrote:
> > >
> > > > To work around MMU-700 erratum 2812531 we need to ensure that certain
> > > > sequences of commands cannot be issued without an intervening sync. In
> > > > practice this falls out of our current command-batching machinery
> > > > anyway - each batch only contains a single type of invalidation command,
> > >
> > > Hmm. This doesn't apply to the user cache invalidation solution
> > > in my v2. A user cmdq could possibly mix different commands in
> > > a single batch if the driver isn't aware of such an errata. So,
> > > I think I'd need some twist when the host has a FORCE_SYNC flag
> > > in my v3.
> >
> > Just found that you unset the NESTING feature flag in PATCH-4
> > for this errata too. So, the solution in my v2 should be safe.
>
> For the short term at least - we will still need to come up with a more
> practical active mitigation sooner rather than later, since I imagine
> people are likely to be a bit miffed if nesting support lands in distros
> but still refuses to play at all on the newest shiniest hardware.
> Unfortunately all current versions of MMU-700 are affected (hence the
> unconditional nature of this patch), and some of those are going to
> found in production SoCs.
Okay. I will try adding a WAR function following the doc:
1. A Stage 1 Invalidation that is followed by a Stage 2 invalidation
2. A Configuration Invalidation that is followed by any TLB Invalidation
3. A Leaf invalidation that is followed by a Non-leaf invalidation
We don't need anything for (1) as a user CMDQ only has stage-1
invalidations. Adding a SYNC after every CFIG_CD(_ALL) should
work for (2). Then for (3), need to check the leaf bit between
two adjacent NH_VA/NH_VAA commands.
Thanks
Nic
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
next parent reply other threads:[~2023-05-15 15:44 UTC|newest]
Thread overview: 3+ messages / expand[flat|nested] mbox.gz Atom feed top
[not found] <cover.1683731256.git.robin.murphy@arm.com>
[not found] ` <330221cdfd0003cd51b6c04e7ff3566741ad8374.1683731256.git.robin.murphy@arm.com>
[not found] ` <ZFvec0JGfbaYHie2@Asurada-Nvidia>
[not found] ` <ZFvi/WEksryM0cin@Asurada-Nvidia>
[not found] ` <a45be5e3-c605-f93a-f523-1bb1f6150986@arm.com>
2023-05-15 15:44 ` Nicolin Chen [this message]
[not found] ` <08adbe3d01024d8382a478325f73b56851f76e49.1683731256.git.robin.murphy@arm.com>
[not found] ` <ZFvXF3gKL4WHiBeZ@Asurada-Nvidia>
2023-05-18 0:53 ` [PATCH 1/4] iommu/arm-smmu-v3: Work around MMU-600 erratum 1076982 Nicolin Chen
2023-06-08 21:36 ` [PATCH 0/4] iommu/arm-smmu-v3: Arm SMMU errata bits 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=ZGJTRc+LYFFX9Sw0@Asurada-Nvidia \
--to=nicolinc@nvidia.com \
--cc=iommu@lists.linux.dev \
--cc=jean-philippe@linaro.org \
--cc=joro@8bytes.org \
--cc=linux-arm-kernel@lists.infradead.org \
--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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).