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.
--
To unsubscribe from this list: send the line "unsubscribe kvm" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
