RE: [(repost) git Patch 1/1] avoid IRQ0 ioapic pin collision

["Brown, Len" <len.brown@intel.com>]

>>>> We should never have had a problem with un-connected 
>interrupt lines
>>>> consuming vectors, as the vectors are handed out at run-time
>>>> only when interrupts are requested by drivers.
>>>
>>>Incorrect.  By being requested by drivers I assume you mean by
>>>request_irq.  assign_irq_vector is called long before request_irq
>>>and in fact there is currently not a call from request_irq to
>>>assign_irq_vector.  Look where assign_irq_vector is called in 
>>io_apic.c
>
>Hmmm, on Natalie's ping, I looked at this again.
>
>setup_IO_APIC_irqs() actually consumes only 16 vectors.
>This is because it only sets up the IRQs for pins
>found with find_irq_entry(), which searches mp_irqs[]
>which at this point contains only the legacy identify mappings.

I should clarify, since Natalie pointed out that some systems
run in MPS mode...

If the system is booted with "acpi=off", then mp_irqs[] includes
everything advertised by the MPS tables, and so setup_IO_APIC_irqs()
does hand out vectors to un-occupied IOAPIC RTEs.  However, if the
MPS tables are accurate enough to skip RTEs that are not used
on that machine, then it hands out vectors for RTEs which
_could_ have devices on them.

On the ES7000 there are potentially lots of IOAPICS with pins
that can't possibly be used.
If only low-numbered RTEs were used on these IOAPICs,
then it would be simple to put in a hook to pretend the
upper entries do not exist, and compress the GSI name space.
But apparently they use some high numbered RTEs, so
we go ahead and allocate the full size of the IOAPIC
in what becomes a very sparse and > NR_IRQS GSI name space.

Of course if one is going to compress this name space,
it would be possible to put a platform dependent hook in
where a GSI is translated into an apic:pin pair...
This would be much cleaner than the current compression...

>The PNP code then takes a swing at things, and it registers
>a handful of gsi's, but they are all duplicates of the legacy
>mappings already set-up, so no additional vectors are consumed.
>
>So on a big system, the large quantity of vectors will not be 
>consumed at
>IOAPIC initialization time, but later at device probe time.
>Not via request_irq(), but via pci_enable_device():
>
>pci_enable_device()
> pci_enable_device_bars()
>  pcibios_enable_device()
>   pcibios_enable_irq() -> acpi_pci_irq_enable()
>    acpi_register_gsi()
>     mp_register_gsi()
>      io_apic_set_pci_routing()
>       entry.vector = assign_irq_vector(irq)

I should qualify this...
If the system is booted with "acpi=off" and MPS is used,
then mp_irqs[] includes everything that is in MPS, and thus
setup_IO_APIC_irqs()
>So except for the legacy IRQs, we are already allocating the vectors
>on-demand, and that doesn't need to be fixed.
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/