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

[Daniel Vetter <daniel.vetter@ffwll.ch>]

On Mon, May 12, 2014 at 6:16 PM, Andy Lutomirski <luto@amacapital.net> wrote:
> On Mon, May 12, 2014 at 8:35 AM, Daniel Vetter <daniel.vetter@ffwll.ch> wrote:
>> On Mon, May 12, 2014 at 5:07 PM, Joerg Roedel <joro@8bytes.org> wrote:
>>> On Mon, May 12, 2014 at 12:43:09AM +0200, Daniel Vetter wrote:
>>>> So I think having some iommu storm handling (like we have for
>>>> interrupts in general and a lot of other things) would go a long way
>>>> towards the goal of enabling iommus everywhere.
>>>
>>> Right, the developer use-case needs also be taken into account. We could
>>> easily ignore a device after it did something wrong to get rid of
>>> io-page-fault or interupt storms. But we also need a way to tell the
>>> kernel to unignore the device later :)
>>
>> A disable/enable cycle of the pci bus master setting should be a good
>> enough signal? Presuming you can say for sure which devices is doing
>> the offending dma transactions ofc ... Or maybe we should just be
>> optimists and re-enable the IOMMU if _any_ child device gets
>> re-enabled (or bus master re-enabled for pci) in the hopes that the
>> developers just reloaded the driver. Worst case the storm handling
>> will kick in again shortly.
>
> Just to check: are you talking about disabling the IOMMU if there's a
> fault storm or disabling reporting of IOMMU faults?

Re-enabling of the IOMMU after it was completely shut off to isolate a
fault storm from a rouge device. Since if I as a developer still have
to reboot if I wreak havoc in my driver it's only marginally better
than a box that went down in a iommu page fault storm. But if I can
just reload the driver (with the bug fixed) and get back a working
device because the IOMMU was re-enabling then that would help. Not
sure yet how feasible this really is.
-Daniel
-- 
Daniel Vetter
Software Engineer, Intel Corporation
+41 (0) 79 365 57 48 - http://blog.ffwll.ch