Re: Remaining passthrough/VT-d tasks list

[Jan Kiszka <jan.kiszka@web.de>]

[-- Attachment #1: Type: text/plain, Size: 1818 bytes --]

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.

Transfered to the virtualization domain, you need a host driver stub for
each guest device that shares an IRQ with another host device. 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.

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.

Jan


[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 257 bytes --]