Messages in this thread | | | From | Jianyu Zhan <> | Date | Sun, 13 Mar 2016 16:20:52 +0800 | Subject | Re: [PATCH 3/3] x86/irq: update first_system_vector only when X86_LOCAL_PIC is on |
| |
On Sun, Mar 13, 2016 at 3:55 PM, Thomas Gleixner <tglx@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
| |