Re: [PATCH 3/3] x86/irq: update first_system_vector only when X86_LOCAL_PIC is on
From: Jianyu Zhan
Date: Sun Mar 13 2016 - 04:28:32 EST
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
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?
* 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.
* Local APIC timer vector.