Yang, Sheng wrote:
We only have three pci interrupts at this point (though this could be
easily extended); if you start the guest with a non-trivial number of
devices, you will have shared guest interrupts.
(of course, when I pointed this out during review, people said it could
be done later, then forgot all about it)
.....
I think it's a performance issue, not break it? How about do it like Xen side?
Try best to avoid the share, extended the pci interrupts, improve hash
algorithm. Is there anything else we can do?
Two separate issues:
1. only three guest pci interrupts
That's a performance issue, not correctness. can be fixed by using gsi
16-23 in APIC mode, and by adding another IOAPIC (so we can use gsi
16-47). Anthony Xu posted some patches for this, not sure where this
stands, but it was the right approach.
2. shared guest pci interrupts
That's a correctness issue. No matter how many interrupts we have, we
may have sharing issues. Of course with only three the issue is very
pressing since we will get sharing with just a few devices. Currently
if two assigned devices share a guest interrupts, or if an emulated
device shares an interrupt with an assigned device, things will break.
They need to be fixed independently.
--
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
