Re: [RFC 1/3] iommu/arm-smmu: Add support to opt-in to stalling

[Will Deacon <will.deacon@arm.com>]

On Thu, Jan 05, 2017 at 03:32:50PM +0000, Robin Murphy wrote:
> On 05/01/17 14:47, Will Deacon wrote:
> > On Thu, Jan 05, 2017 at 02:07:31PM +0000, Mark Rutland wrote:
> >> Ok. It would be good to elaborate on what "stalling is useable" means in
> >> the property description. i.e. what specificallty the implementation and
> >> integration need to ensure.
> > 
> > We can describe some of those guarantees in the property description, but
> > it's difficult to enumerate them exhaustively. For example, you wouldn't
> > want stalling to lead to data corruption, denial of service, or for the
> > thing to catch fire, but having those as explicit requirements is a bit
> > daft. It's also impossible to check that you thought of everything.
> > 
> > Aside from renaming the option, I'm really after an opinion on whether
> > it's better to have one property or combine it with the compatible
> > string, because I can see benefits of both and don't much care either
> > way.
> 
> The SMMU implementation side of the decision (i.e. independence of IRQ
> assertion vs. SS) seems like exactly the sort of stuff the compatible
> string already has covered. The integration side I'm less confident can
> be described this way at all - the "this device definitely won't go
> wrong if stalled for an indefinite length of time" is inherently a
> per-master thing, so a single property on the SMMU implying that for
> every device connected to it seems a bit optimistic, and breaks down as
> soon as you have one device in the system for which that isn't true (a
> PCI root complex, say), even if that guy's traffic never crosses paths
> with whichever few devices you actually care about using stalls with.
> 
> I think this needs to be some kind of "arm,smmu-stall-safe" property
> placed on individual master device nodes (mad idea: or even an extra
> cell of flags in the IOMMU specifier) to encapsulate both that the given
> device itself is OK with being stalled, and that it's integrated in such
> a way that its stalled transactions cannot disrupt any *other* device
> (e.g. it has a TBU all to itself). Then upon initialising a context bank
> on a suitable SMMU implementation, we set CFCFG based on whatever device
> is being attached to the corresponding domain, and refuse any subsequent
> attempts to attach a non-stallable device to a stalling domain (and
> possibly even vice-versa).

If we're going to add per-master properties, I'd *really* like them to be
independent of the IOMMU in use. That is, we should be able to re-use this
property as part of supporting SVM for platform devices in future.

But I think we agree that we need:

  1. A compatible string for the SMMU that can be used to infer the SS
     behaviour in the driver

  2. A property on the SMMU to say that it's been integrated in such a
     way that stalling is safe (doesn't deadlock)

  3. A generic master property that says that the device can DMA to
     unpinned memory

Anything else?

Will