Re: [patch 2/2] x86, irq: use 0x20 for the IRQ_MOVE_CLEANUP_VECTOR instead of 0x1f

["Maciej W. Rozycki" <macro@linux-mips.org>]

On Sun, 24 Jan 2010, H. Peter Anvin wrote:

> > > So change the IRQ_MOVE_CLEANUP_VECTOR to 0x20 and  allow 0x21-0x2f to be
> > > used
> > > for device interrupts. 0x30-0x3f will be used for ISA interrupts (these
> > > also can be migrated in the context of IOAPIC and hence need to be at a
> > > higher
> > > priority level than IRQ_MOVE_CLEANUP_VECTOR).
> > 
> >   I have troubles understanding what exactly this change is needed for
> > (i.e. what's the difference between using vectors 0x20-0x2f and 0x30-0x3f
> > as ExtINT interrupts, what's the gain from relocating them? -- they are
> > transparent to the APIC, so the exact priority level used does not matter
> > at all), but since I've been cc-ed, I have one question -- have you
> > verified that with the new arrangement the mixed interrupt mode (where
> > some interrupts come via the APIC and some via the 8259A PICs) still
> > works?
> > 
> 
> The difference is relevant when they are *not* invoked as ExtInt interrupts,
> but when used as IOAPIC interrupts it matters.

 Hmm, I/O APIC interrupts coming from ISA devices used not to differ from 
ones from PCI devices and their vectors were evenly distributed across the 
whole device range (one reason for this was the (in)famous Pentium APIC 
limitation WRT multiple outstanding requests at the same priority level).  
Now what you've written suggests this has changed and now ISA devices only 
get vectors within a single priority level -- am I getting this right?

 If so, then to push my original question further: how are these vectors 
allocated -- are they identity mapped with the corresponding i8259A 
vectors?  And how does it play with the Pentium APIC limitation (that may 
actually apply to all the local APIC cores that use serial bus delivery; 
I'm not sure) I mentioned above?

  Maciej