On Tue, 26 Oct 2010, Konrad Rzeszutek Wilk wrote:
> > In that case we should use dynamic allocation for everything. Or try to
> > work out distinct irq ranges for different interrupts if you really want
> > to keep irq==gsi.
> Some little alarm bells are ringing in the back of my head about irq != gsi.
> I think the issue was the permission. When a PCI device is allocated to the
> PV guest, we do a bunch of xc_* calls to allow the domain to use the BARs
> and the IRQ. I believe when the guest boots and tries to map the
> event channel with the physical IRQ, one of the arguments is that GSI. And
> if we provide a bogus GSI, well, we won't get the INTx to the guest.
> As you mentioned, Stefano's patch add a new element to the tuple that can
> contain the GSI value. At which point we can make the guest IRQ != GSI,
> as long as we can contain the <gsi, event channel> mapping present so
> that for the hypercalls we can give it the right GSI.
> The MSI/MSI-X use a completly different mechanism that does not all
> of this complication, so we are OK with that.
> .. snip ..
> > d) dynamically allocate all irqs for all event channel types.
> <nods> Ok, you sold me on this idea.
Even though dynamic allocation might seem possible for both pirqs and
irqs, there are some severe limitations:
- Xen won't allocate pirq numbers lower than 16 (probably because it
expects pirq == gsi for the first 16 gsi), so it might run out
of pirqs if we ask Xen to always choose the pirq number for us. As a
consequence it is safer to keep using pirq == gsi, at least for the
first 16 gsis. This limitation should probably be fixed in Xen, but we
need to support older hypervisors so we cannot rely on the fix to be
- Linux expects irq == gsi, see arch/x86/kernel/acpi/boot.c:gsi_to_irq
/* Provide an identity mapping of gsi == irq
* except on truly weird platforms that have
* non isa irqs in the first 16 gsis.
Xen-devel mailing list