[Ksummit-discuss] [CORE TOPIC] Device error handling / reporting / isolation

[Will Deacon]

Hi David,

On Thu, May 08, 2014 at 01:37:03PM +0100, David Woodhouse wrote:
> I'd like to have a discussion about handling device errors.
> 
> IOMMUs are becoming more common, and we've seen some failure modes where
> we just end up with an endless stream of fault reports from a given
> device, and the kernel can do nothing else.
> 
> We may have various options for shutting it up — a PCI function level
> reset, power cycling the offending device, or maybe just configuring the
> IOMMU to *ignore* further errors from it, which would at least let the
> system get on with doing something useful (and if we do, when do we
> re-enable reporting?).

There's also the fun of non-PCI devices, where even if you can kill the
offending device, there's not a specified way to ensure that it not longer
has transactions in flight. Also, the fault reports have to go somewhere,
so queues can fill up etc. etc.

> But I absolutely don't want us to be implementing policies like that in
> an individual IOMMU driver; this needs to be handled by generic device
> code. Once upon a time I might have said PCI code, but this is actually
> relevant for non-PCI devices too.
> 
> I want the IOMMU to report errors, and let the system do the appropriate
> thing. Which requires some discussion about what the "appropriate thing"
> can be in various circumstances, and indeed what options are available
> to us on various platforms.
> 
> Participants would be those working with IOMMUs on various platforms,
> including Jörg Rödel, myself, and hopefully someone with a fairly
> intimate knowledge of EEH as used on POWER systems.

I'd certainly be interested in this from the ARM side (I'm involved in the
architecture of our next SMMU and we've discussed this a lot internally).

Will