Re: Remaining passthrough/VT-d tasks list

[Avi Kivity <avi@redhat.com>]

Jan Kiszka wrote:
> Avi Kivity wrote:
>   
>> Yang, Sheng wrote:
>>     
>>> After check host shared interrupts situation, I got a question here:
>>>
>>> If I understand correctly, current solution don't block host shared
>>> irq, just come with the performance pentry. The penalty come with host
>>> disabled irq line for a period. We have to wait guest to write EOI.
>>> But I fail to see the correctness problem here (except a lot of
>>> spurious interrupt in the guest).
>>>
>>> I've checked mail, but can't find clue about that. Can you explain the
>>> situation?
>>>
>>>   
>>>       
>> If the guest fails to disable interrupts on a device that shares an
>> interrupt line with the host, the host will experience an interrupt
>> flood.  Eventually the host will disable the host device as well.
>>
>>     
>
> It's the same issue we have since ages in the real-time domain: You
> cannot safely share IRQs between devices that are handled partly by
> RT-safe and partly by RT-unsafe drivers. The only sane solution is to
> write an RT-safe stub that is able to detect if an IRQ was triggered by
> the non-RT device, satisfy the IRQ source (disable further IRQ
> generation in the device), and forward the event to the non-RT driver
> part for handling the rest later.
>
>   

Yes indeed -- exactly the same problem.

> Transfered to the virtualization domain, you need a host driver stub for
> each guest device that shares an IRQ with another host device.

That will requires some communication between the guest driver and the 
host stub.

>  Maybe
> there is some generic hardware support for this in recent PCI or in
> VT-d, dunno. But that would simplify the stub development and
> maintenance significantly.
>
>   

Using MSI works around the issue nicely, since interrupts are no longer 
shared.  I imagine SR-IOV also fixes the issue.

> BTW, uio's IRQ handling pattern is also related to this issue: A small,
> device-specific IRQ receiver is written as a kernel driver while the
> major driver code sits in user space and can handle the IRQ later -
> without disturbing other devices sharing IRQs with the uio device.
>   

This is yet another manifestation of the same issue.  Those who 
understand computing are doomed to keep reinventing the wheel, badly.

-- 
I have a truly marvellous patch that fixes the bug which this
signature is too narrow to contain.