MIME-Version: 1.0
In-Reply-To: <alpine.DEB.2.11.1603130847140.3657@nanos>
References: <cover.1457790776.git.nasa4836@gmail.com> <fa064e4e2fd688a42480f686825f485ade4e30ca.1457790777.git.nasa4836@gmail.com>
 <alpine.DEB.2.11.1603122104360.3657@nanos> <CAHz2CGXs3cweb9m+m5fS2ZqWkqSbp18eZtOsSAK3KQC+N7f_4A@mail.gmail.com>
 <alpine.DEB.2.11.1603130727460.3657@nanos> <CAHz2CGVZocGSuYa2xq4UeCrGg=CU29XejTfLS0KxFitAttrC4g@mail.gmail.com>
 <alpine.DEB.2.11.1603130847140.3657@nanos>
From: Jianyu Zhan <nasa4836@gmail.com>
Date: Sun, 13 Mar 2016 16:20:52 +0800
Message-ID: <CAHz2CGXUYs4aC5WKeekN3bUsr-r_nei6tLLFNSz9h2okmxAdfQ@mail.gmail.com>
Subject: Re: [PATCH 3/3] x86/irq: update first_system_vector only when
 X86_LOCAL_PIC is on
To: Thomas Gleixner <tglx@linutronix.de>
Cc: mingo@redhat.com, "H. Peter Anvin" <hpa@zytor.com>,
        Aravind.Gopalakrishnan@amd.com, brgerst@gmail.com, bp@suse.de,
        feng.wu@intel.com, jiang.liu@linux.intel.com,
        Tejun Heo <tj@kernel.org>, dvlasenk@redhat.com, penberg@cs.helsinki.fi,
        Yinghai Lu <yhlu.kernel@gmail.com>, andi@firstfloor.org,
        Andy Lutomirski <luto@kernel.org>, ajm@sgi.com,
        Yinghai Lu <yinghai@kernel.org>, Akinobu Mita <akinobu.mita@gmail.com>,
        x86@kernel.org, LKML <linux-kernel@vger.kernel.org>
Content-Type: text/plain; charset=UTF-8
Sender: linux-kernel-owner@vger.kernel.org
Content-Length: 1621
Lines: 49

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