On 10/12/2009 11:07 AM, Jan Kiszka wrote:
I'm worried about disabling irqs for non-device-assignment cases. It
would be more palatable if ioapic was completely O(1) (there are some
per-vcpu loops in there, shouldn't be too bad for 16 vcpus, but we want
to scale).
Yeah, what a pity. That's likely not solvable in a generic way, given
that the guest finally decided how many VCPUs may listen to a line.
OK, but dropping interrupt_work from the MSI path is still worthwhile,
and probably more future-proof anyway.
Yes - we can extend the irq routing table to contain this information.
It means we need to invalidate it when the guest reprograms the
interrupt controllers, but I think it should work out fine.
--
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 majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
