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

From: Maciej W. Rozycki
Date: Sun Jan 31 2010 - 02:20:20 EST


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
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/