iommu/arm-smmu-v3: Arm SMMU errata bits

MMU-600 versions prior to r1p0 fail to correctly generate a WFE wakeup event when the command queue transitions fom full to non-full. We can easily work around this by simply hiding the SEV capability such that we fall back to polling for space in the queue - since MMU-600 implements MSIs we wouldn't expect to need SEV for sync completion either, so this should have little to no impact.

Signed-off-by Robin Murphy <[email protected]>

Quoted 7 lines · Robin Murphy

MMU-600 versions prior to r1p0 fail to correctly generate a WFE wakeup event when the command queue transitions fom full to non-full. We can easily work around this by simply hiding the SEV capability such that we fall back to polling for space in the queue - since MMU-600 implements MSIs we wouldn't expect to need SEV for sync completion either, so this should have little to no impact.

Quoted 1 line

Signed-off-by Robin Murphy <[email protected]>

Reviewed-by Nicolin Chen <[email protected]>

drivers/iommu/arm/arm-smmu-v3/arm-smmu-v3.c static int arm_smmu_device_reset(struct arm_smmu_device *smmu, bool bypass) · line 3441

Quoted 4 lines

drivers/iommu/arm/arm-smmu-v3/arm-smmu-v3.c +4 -0

+static void arm_smmu_device_iidr_probe(struct arm_smmu_device *smmu)
+{
+       u32 reg;
+       unsigned int implementer, productid, variant, revision;

Just for curiosity -- what's the fashion behind the coding style here? Usually I follow a longer-to-shorter style, yet perhaps I can follow this one for further SMMU patches, if it matters.

Quoted 7 lines · Robin Murphy

MMU-600 versions prior to r1p0 fail to correctly generate a WFE wakeup event when the command queue transitions fom full to non-full. We can easily work around this by simply hiding the SEV capability such that we fall back to polling for space in the queue - since MMU-600 implements MSIs we wouldn't expect to need SEV for sync completion either, so this should have little to no impact.

Quoted 1 line

Signed-off-by Robin Murphy <[email protected]>

Reviewed-by Nicolin Chen <[email protected]>

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,

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.

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 <[email protected]>

Quoted 4 lines · Robin Murphy

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.

Quoted 7 lines · Nicolin Chen

Quoted 4 lines · Robin Murphy

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,

Quoted 5 lines

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.

Quoted 8 lines · Nicolin Chen

Quoted 7 lines · Nicolin Chen

Quoted 4 lines · Robin Murphy

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,

Quoted 8 lines

Quoted 5 lines

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.

In certain cases we may want to refuse to allow nested translation even when both stages are implemented, so let's add an explicit feature for nesting support which we can control in its own right. For now this merely serves as documentation, but it means a nice convenient check will be ready and waiting for the future nesting code.

Signed-off-by Robin Murphy <[email protected]>

Both MMU-600 and MMU-700 have similar errata around TLB invalidation while both stages of translation are active, which will need some consideration once nesting support is implemented. For now, though, it's very easy to make our implicit lack of nesting support explicit for those cases, so they're less likely to be missed in future.

Signed-off-by Robin Murphy <[email protected]>

Further to the discussion on the nesting series a while back, here's a mini-series to help us start taking more of an interest in SMMU errata. Patch #1 is more about the infrastucture than that erratum itself, but since I *had* already written it up (5 years ago!) I figured why not just build on it as-is. The rest is effectively just documentation at this point, but getting us ready for all the hitherto unmet conditions that IOMMUFD nesting is going to open up.

[...]