Ben-Ami Yassour wrote:
+
+/* FIXME: Implement the OR logic needed to make shared interrupts
on + * this line behave properly + */

Isn't this a showstopper?  There is no easy way for a user to avoid
sharing, especially as we have only three pci irqs at present.
What do you mean by only 3 (for passthrough we use whatever interrupt
the host is using for that device)?


There are two issue:
- shared host interrupts
- shared guest interrupts

For shared host interrupts, I don't think there's a cost-effective solution, especially as hosts are transitioning to MSI. But the problem the comment describes is shared guest interrupts, where the assigned device's interrupt is shared with another device (assigned or virtual).

And currently we only have three shareable interrupts: 5, 10, and 11.

See qemu's pci_set_irq() for the logic used to share interrupts.
Currently it's not easy to avoid sharing. I think we can support MSI for
assgined device to solve sharing problem.
MSI is definitely the right direction, but we also need to support
the OR logic for guests that do not support MSI.


The main problems that I am ware of with shared interrupt are as
follows:

1. Protection
A bad guest can keep the interrupt line up, and if its shared then it
interferes with other devices that might not be assigned to this guest.

2. Performance
The current implementation disables the irq when the interrupt is
received on the host and re-enables it when the guest acks the interrupt
on the virtual ioapic.

Clearly its not nice to do that when other devices uses the same irq...

When removing the enable-disable of the irq, it causes serious
performance degradation.
The throughput goes down from 700 to 400 Mb/sec.
The number of interrupts per second on the host (from the NIC) is 130000
(compared to 22200 before).


These are all shared host interrupt problems.

Regardless, I think that the right way to go would be to merge the
current code (with the non-shared interrupt limitation) and then
continue to work on additional features like shared interrupts support. Do you agree?

The current code will be incredibly easy to break; all you need is more than three pci devices. I think the sharing code can be easily added (as a separate patch); all that's needed is to make sure the API is good.

--
error compiling committee.c: too many arguments to function

--
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

Reply via email to