Re: [PATCH 2/4] iommu/arm-smmu-v3: Document MMU-700 erratum 2812531

[Nicolin Chen <nicolinc@nvidia.com>]

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.

> and ends with a sync. The only exception is when a batch is sufficiently
> large to need issuing across multiple command queue slots, wherein the
> earlier slots will not contain a sync and thus may in theory interleave
> with another batch being issued in parallel to create an affected
> sequence across the slot boundary.
> 
> Since MMU-700 supports range invalidate commands and thus we will prefer
> to use them (which also happens to avoid conditions for other errata),
> I'm not entirely sure it's even possible for a single high-level
> invalidate call to generate a batch of more than 63 commands, but for
> the sake of robustness and documentation, wire up an option to enforce
> that a sync is always inserted for every slot issued.

Hmm. This can happen to a user space driver that does something
insane like that. I'll need, again in the nesting patch, a line
of code to limit the number of the commands when it calls the
arm_smmu_cmdq_issue_cmdlist() for a user cache invalidation.

> The other aspect is that the relative order of DVM commands cannot be
> controlled, so DVM cannot be used. Again that is already the status quo,
> but since we have at least defined ARM_SMMU_FEAT_BTM, we can explicitly
> disable it for documentation purposes even if it's not wired up anywhere
> yet.
> 
> Signed-off-by: Robin Murphy <robin.murphy@arm.com>

Reviewed-by: Nicolin Chen <nicolinc@nvidia.com>

Thanks!