| Message ID | 1503890438-27840-11-git-send-email-douly.fnst@cn.fujitsu.com (mailing list archive) |
|---|---|
| State | New, archived |
| Headers | show |
On 28/08/17 05:20, Dou Liyang wrote: > XEN PV overrides smp_prepare_cpus(). xen_pv_smp_prepare_cpus() > initializes interrupts in the XEN PV specific way and does not invoke > native_smp_prepare_cpus(). As a consequence, x86_init.intr_mode_init() is > not invoked either. > > The invocation of x86_init.intr_mode_init() will be moved from > native_smp_prepare_cpus() in a follow up patch to solve <INSERT > REASON/PROBLEM>. Can you be a little bit more precise here, please? :-) > That move would cause the invocation of x86_init.intr_mode_init() for XEN > PV platforms. To prevent that, override the default x86_init. > intr_mode_init() callback with a noop(). > > [Rewrited by Thomas Gleixner <tglx@linutronix.de>] > > Signed-off-by: Dou Liyang <douly.fnst@cn.fujitsu.com> > Cc: xen-devel@lists.xenproject.org > Cc: boris.ostrovsky@oracle.com On which tree does this apply? Would be nice to get a hint against which source this can be reviewed. Juergen > --- > arch/x86/xen/enlighten_pv.c | 1 + > 1 file changed, 1 insertion(+) > > diff --git a/arch/x86/xen/enlighten_pv.c b/arch/x86/xen/enlighten_pv.c > index 811e4dd..07147dd 100644 > --- a/arch/x86/xen/enlighten_pv.c > +++ b/arch/x86/xen/enlighten_pv.c > @@ -1250,6 +1250,7 @@ asmlinkage __visible void __init xen_start_kernel(void) > x86_platform.get_nmi_reason = xen_get_nmi_reason; > > x86_init.resources.memory_setup = xen_memory_setup; > + x86_init.irqs.intr_mode_init = x86_init_noop; > x86_init.oem.arch_setup = xen_arch_setup; > x86_init.oem.banner = xen_banner; > >
On 28/08/17 06:25, Juergen Gross wrote: > On 28/08/17 05:20, Dou Liyang wrote: >> XEN PV overrides smp_prepare_cpus(). xen_pv_smp_prepare_cpus() >> initializes interrupts in the XEN PV specific way and does not invoke >> native_smp_prepare_cpus(). As a consequence, x86_init.intr_mode_init() is >> not invoked either. >> >> The invocation of x86_init.intr_mode_init() will be moved from >> native_smp_prepare_cpus() in a follow up patch to solve <INSERT >> REASON/PROBLEM>. > > Can you be a little bit more precise here, please? :-) > >> That move would cause the invocation of x86_init.intr_mode_init() for XEN >> PV platforms. To prevent that, override the default x86_init. >> intr_mode_init() callback with a noop(). >> >> [Rewrited by Thomas Gleixner <tglx@linutronix.de>] >> >> Signed-off-by: Dou Liyang <douly.fnst@cn.fujitsu.com> >> Cc: xen-devel@lists.xenproject.org >> Cc: boris.ostrovsky@oracle.com > > On which tree does this apply? Would be nice to get a hint against which > source this can be reviewed. Aah, just found the rest of the series. In case a single patch of a series isn't stand alone it would be nice to receive at least the cover letter of the series in order to know what its all about. Juergen
Hi Juergen, At 08/28/2017 12:32 PM, Juergen Gross wrote: > On 28/08/17 06:25, Juergen Gross wrote: >> On 28/08/17 05:20, Dou Liyang wrote: >>> XEN PV overrides smp_prepare_cpus(). xen_pv_smp_prepare_cpus() >>> initializes interrupts in the XEN PV specific way and does not invoke >>> native_smp_prepare_cpus(). As a consequence, x86_init.intr_mode_init() is >>> not invoked either. >>> >>> The invocation of x86_init.intr_mode_init() will be moved from >>> native_smp_prepare_cpus() in a follow up patch to solve <INSERT >>> REASON/PROBLEM>. >> >> Can you be a little bit more precise here, please? :-) >> >>> That move would cause the invocation of x86_init.intr_mode_init() for XEN >>> PV platforms. To prevent that, override the default x86_init. >>> intr_mode_init() callback with a noop(). >>> >>> [Rewrited by Thomas Gleixner <tglx@linutronix.de>] >>> >>> Signed-off-by: Dou Liyang <douly.fnst@cn.fujitsu.com> >>> Cc: xen-devel@lists.xenproject.org >>> Cc: boris.ostrovsky@oracle.com >> >> On which tree does this apply? Would be nice to get a hint against which >> source this can be reviewed. > > Aah, just found the rest of the series. In case a single patch of a > series isn't stand alone it would be nice to receive at least the cover > letter of the series in order to know what its all about. > Sorry to confuse you, It's my fault. Thank you for your reply. I understood. will CC the cover letter to linux-xen and linux-acpi. Thanks, dou. > > Juergen > > >
diff --git a/arch/x86/xen/enlighten_pv.c b/arch/x86/xen/enlighten_pv.c index 811e4dd..07147dd 100644 --- a/arch/x86/xen/enlighten_pv.c +++ b/arch/x86/xen/enlighten_pv.c @@ -1250,6 +1250,7 @@ asmlinkage __visible void __init xen_start_kernel(void) x86_platform.get_nmi_reason = xen_get_nmi_reason; x86_init.resources.memory_setup = xen_memory_setup; + x86_init.irqs.intr_mode_init = x86_init_noop; x86_init.oem.arch_setup = xen_arch_setup; x86_init.oem.banner = xen_banner;
XEN PV overrides smp_prepare_cpus(). xen_pv_smp_prepare_cpus() initializes interrupts in the XEN PV specific way and does not invoke native_smp_prepare_cpus(). As a consequence, x86_init.intr_mode_init() is not invoked either. The invocation of x86_init.intr_mode_init() will be moved from native_smp_prepare_cpus() in a follow up patch to solve <INSERT REASON/PROBLEM>. That move would cause the invocation of x86_init.intr_mode_init() for XEN PV platforms. To prevent that, override the default x86_init. intr_mode_init() callback with a noop(). [Rewrited by Thomas Gleixner <tglx@linutronix.de>] Signed-off-by: Dou Liyang <douly.fnst@cn.fujitsu.com> Cc: xen-devel@lists.xenproject.org Cc: boris.ostrovsky@oracle.com --- arch/x86/xen/enlighten_pv.c | 1 + 1 file changed, 1 insertion(+)