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?).

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.

We probably also want KVM folks to weigh in on how, if at all, they'd
want errors on assigned devices to be reported to guests.

I strongly suspect that once we start looking at it, we'll find other
triggers than "IOMMU faults" for starting to isolate and reset
misbehaving devices. Interrupt storms perhaps being one of them — we've
never been particularly robust to those, either.

-- 
David Woodhouse                            Open Source Technology Centre
David.Woodhouse@intel.com                              Intel Corporation