Re: [PATCH 3/3] x86/irq: update first_system_vector only when X86_LOCAL_PIC is on

[Jianyu Zhan]

On Sun, Mar 13, 2016 at 3:55 PM, Thomas Gleixner <tglx@xxxxxxxxxxxxx> wrote:
> if LOCAL_APIC is disabled it does not use the interrupt, simply because there
> is no way to trigger it. That setup is inside #ifdef CONFIG_X86_LOCAL_APIC for
> exactly that reason.
>
> Just because IRQ_WORK has no config dependency on LOCAL APIC that does not
> mean it uses the interrupt gate unconditionally.
>

Thanks for clarification.

I think IRQ_WORK works as generic hardirq context callbacks, it should reply on
self IPI,  which is a functionality provided by LOCAL_APIC, while
legacy PIC doesn't
provide this(correct?).

If so,  it really makes sense to enable IRQ_WORK only when X86_LOCAL_APIC,
and I think we should make CONFIG_IRQ_WORK depend on this.


> The code is correct as is and there is no reason to shuffle it in circles for
> no value.

Will the below layout make sense?


*  Layout:
*  0xff, 0xfe:
*      Two highest vectors, granted for spurious vector and error vector.
*  0xfd - 0xf9:
*      CONFIG_SMP dependent vectors. On morden machines these are achieved
*      via local APIC, so these imply CONFIG_X86_LOCAL_APIC.
*
*  0xf8 - 0xf0:
*      CONFIG_X86_LOCAL_APIC dependent vectors, but these do not necessarily
*      depend on CONFIG_SMP, so are seperated from above.
*      Some are only depending on CONFIG_X86_LOCAL_APIC, but some are depending
*      on more(MCE, Virtualization, etc).
*
*     Note:  CONFIG_IRQ_WORK replies on CONFIG_X86_LOCAL_APIC(for self
IPI),  though it could
*                 be turned on  ! CONFIG_X86_LOCAL_APIC.
*  0xef:
*      Local APIC timer vector.



Regards,
Jianyu Zhan