On Sun, Mar 13, 2016 at 3:55 PM, Thomas Gleixner <t...@linutronix.de> 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
