Re: [Xen-devel] NR_PIRQS vs. NR_IRQS

[Keir Fraser <keir.fraser@xxxxxxxxxxxxx>]

PIRQs are actually a different namespace. They aren't necessarily 1:1
mapped. Hence NR_PIRQS and NR_IRQS not really same thing.

Yes, I'm sure with a bit of finessing we could have NR_IRQS != NR_VECTORS.
I'm sure there'll be some barking NUMA box down the road that will require
something like that, but thankfully not so far.

 -- Keir

On 13/11/08 16:59, "Jan Beulich" <jbeulich@xxxxxxxxxx> wrote:

> I'm having some difficulty understanding why these two need to be
> distinguished: Depending on the code location, an IRQ passed in from the
> guest may be checked against NR_PIRQS (map_domain_pirq() as called
> from PHYSDEVOP_alloc_irq_vector) or NR_IRQS (PHYSDEVOP_irq_status_query,
> PHYSDEVOP_map_pirq), despite it having the same source.
> 
> Also, tying NR_IRQS to NR_VECTORS seems bogus - even with current
> code I can't see why we shouldn't be able to support a higher NR_IRQS
> without immediately doing the more involved code changes needed to
> also grow NR_VECTORS. After all, NR_IRQS is directly tied to the number
> of IO-APIC pins we can support - in order to support a device, its
> cumulative pin number (being the irq) must be below NR_IRQS. But since
> very likely not all pins are connected to devices, NR_VECTORS is much
> less of a limiting factor.
> 
> Thanks, Jan
> 
> 
> _______________________________________________
> Xen-devel mailing list
> Xen-devel@xxxxxxxxxxxxxxxxxxx
> http://lists.xensource.com/xen-devel



_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxxxxxxxx
http://lists.xensource.com/xen-devel