linux-kernel - Re: [patch 2/2] x86, irq: use 0x20 for the IRQ_MOVE_CLEANUP

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite for Android: free password hash cracker in your pocket

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <alpine.LFD.2.00.1001310705280.31764@eddie.linux-mips.org>
Date:	Sun, 31 Jan 2010 07:19:59 +0000 (GMT)
From:	"Maciej W. Rozycki" <macro@...ux-mips.org>
To:	"H. Peter Anvin" <hpa@...or.com>
cc:	Suresh Siddha <suresh.b.siddha@...el.com>, ebiederm@...ssion.com,
	yinghai@...nel.org, mingo@...e.hu, linux-kernel@...r.kernel.org
Subject: Re: [patch 2/2] x86, irq: use 0x20 for the IRQ_MOVE_CLEANUP_VECTOR
 instead of 0x1f

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@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/