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

[Yinghai Lu <yinghai@kernel.org>]

On 01/04/2010 01:33 PM, H. Peter Anvin wrote:
> On 01/04/2010 01:20 PM, Yinghai Lu wrote:
>> --- linux-2.6.orig/arch/x86/include/asm/irq_vectors.h
>> +++ linux-2.6/arch/x86/include/asm/irq_vectors.h
>> @@ -30,8 +30,17 @@
>>  /*
>>   * IDT vectors usable for external interrupt sources start
>>   * at 0x20:
>> + * hpa said we can start from 0x1f.
>> + *   0x1f is documented as reserved.  However, the ability for the APIC
>> + *   to generate vectors starting at 0x10 is documented, as is the
>> + *   ability for the CPU to receive any vector number as an interrupt.
>> + *   0x1f is used for IRQ_MOVE_CLEANUP_VECTOR since that vector needs
>> + *   an entire privilege level (16 vectors) all by itself at a higher
>> + *   priority than any actual device vector.  Thus, by placing it in the
>> + *   otherwise-unusable 0x10 privilege level, we avoid wasting a full
>> + *   16-vector block.
>>   */
>> -#define FIRST_EXTERNAL_VECTOR		0x20
>> +#define FIRST_EXTERNAL_VECTOR		0x1f
>>  
>>  #ifdef CONFIG_X86_32
>>  # define SYSCALL_VECTOR			0x80
>> @@ -41,15 +50,19 @@
>>  #endif
>>  
>>  /*
>> - * Reserve the lowest usable priority level 0x20 - 0x2f for triggering
>> + * Reserve the lowest usable priority level 0x10 - 0x1f for triggering
>>   * cleanup after irq migration.
>> + * this overlaps with the reserved range for cpu exceptions so this
>> + * will need to be changed to 0x20 - 0x2f if the last cpu exception is
>> + * ever allocated.
>>   */
>> +
>>  #define IRQ_MOVE_CLEANUP_VECTOR		FIRST_EXTERNAL_VECTOR
>>  
>>  /*
>> - * Vectors 0x30-0x3f are used for ISA interrupts.
>> + * Vectors 0x20-0x2f are used for ISA interrupts.
>>   */
>> -#define IRQ0_VECTOR			(FIRST_EXTERNAL_VECTOR + 0x10)
>> +#define IRQ0_VECTOR			(FIRST_EXTERNAL_VECTOR + 1)
>>  
>>  #define IRQ1_VECTOR			(IRQ0_VECTOR +  1)
>>  #define IRQ2_VECTOR			(IRQ0_VECTOR +  2)
>> @@ -68,6 +81,13 @@
>>  #define IRQ15_VECTOR			(IRQ0_VECTOR + 15)
>>  
> 
> I'm not sure that making IRQ_MOVE_CLEANUP_VECTOR and IRQ0_VECTOR offsets
> from FIRST_EXTERNAL_VECTOR makes sense from a readability perspective.
> These are now magic numbers, and making them offsets is only confusing,
> as it implies we could do it differently.
> 
> If nothing else, the actual logic for IRQ0_VECTOR should be:
> 
> #define IRQ0_VECTOR		((FIRST_EXTERNAL_VECTOR + 16) & ~15)
> 
> ... since that is what we actually want -- we round up to the next
> 16-vector boundary.  Both +16 and +1 misrepresent the logic.

that will be good, if later update FIRST_EXTERNAL_VECTOR...

> 
>>  /*
>> + * First APIC vector available to drivers: (vectors 0x30-0xee) we
>> + * start at 0x31 to spread out vectors evenly between priority
>> + * levels. (0x80 is the syscall vector)
>> + */
>> +#define FIRST_DEVICE_VECTOR		(IRQ15_VECTOR + 2)
>> +
> 
> We really should fix that so we can do +1 here instead of +2; that
> presumably means fixing the logic so we do something smarter than just
> jump over 0x80.

we already use used_vectors to skip 0x80. so we could change that to +1?

YH