Jeremy Fitzhardinge <jeremy@xxxxxxxx> writes:
Yes, I suppose we can statically partition the irq space. In fact the original
2.6.18-xen dom0 kernel does precisely that, but runs into limitations because of
the compile-time limit on NR_IRQS in that kernel. If we move to a purely
dynamically allocated irq space, then having a sparse allocation if irqs becomes
reasonable again, for msis and vectorless Xen interrupts.
The difference is that the xen sources are not delivered using vectors. The cpuRight. And in the physical irq event channel case, the vector space is managed
vector numbers we do hide and treat as an implementation detail. And I am totally
happy not going through the vector allocation path.
by Xen, so we need to use Xen to allocate the vector, then program that into the
appropriate place in the ioapic.
We should be able to share code with iommu for irqs handling, at first glance you
are describing a pretty similar problem. Now I don't know think the interrupt
remapping code is any kind of beauty but that seems to be roughly what you
are doing with Xen domU. I certainly think with some careful factoring
we can share the ioapic munging code. And the code to pick how we program
the ioapics.