Thread (1 message) 1 message, 1 author, 2010-01-04

Re: Subject: [PATCH 1/2] x86: get back 15 vectors

From: Eric W. Biederman <hidden>
Date: 2010-01-04 20:08:43
Also in: lkml

Yinghai Lu [off-list ref] writes:
On 01/04/2010 11:09 AM, Eric W. Biederman wrote:
quoted
"H. Peter Anvin" [off-list ref] writes:
quoted
On 01/04/2010 08:18 AM, Eric W. Biederman wrote:
quoted
Yinghai Lu [off-list ref] writes:

This patch is wrong.
quoted
between FIRST_EXTERNAL_VECTOR (0x20) and FIRST_DEVICE_VECTOR (0x41)

for 0x20 and 0x2f, we are safe be used_vectors will prevent it to use used one.
We can not use any of 0x20 - 0x2f for ioapic irqs.  We need the entire
priority level to ensure that the irq move cleanup ipi is of a lower
priority.
Almost makes one want to abuse 0x1f for that.  Although 0x00..0x1f are
reserved for exceptions, the APICs range down to 0x10, and well, when
0x1f ends up actually getting used as an exception vector that we
support, then we can trivially change that.  In the meantime it would
actually make use of an otherwise-unusable APIC priority level.
An optimization like that (with a big fat comment) seems reasonable
to me.
so we can use [0x10, 0x1f]

sth like this?
Something.  We can not use all of 0x10 - 0x1f, it is simply
that hardware can address all of that. 0x10 is already defined
as something I forget what.   0x12 is already the MCE_VECTOR.


Since hardware has not yet defined 0x1f (and is not likely to for
a while.  We can use that).  So we wind up using hardware priority
a single ipi, and hardware exceptions.

Eric
Keyboard shortcuts
hback out one level
jnext message in thread
kprevious message in thread
ldrill in
Escclose help / fold thread tree
?toggle this help