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
signature.asc
Description: OpenPGP digital signature
