Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1752648AbdGCHR7 (ORCPT ); Mon, 3 Jul 2017 03:17:59 -0400 Received: from cn.fujitsu.com ([59.151.112.132]:29860 "EHLO heian.cn.fujitsu.com" rhost-flags-OK-FAIL-OK-FAIL) by vger.kernel.org with ESMTP id S1752279AbdGCHR6 (ORCPT ); Mon, 3 Jul 2017 03:17:58 -0400 X-IronPort-AV: E=Sophos;i="5.22,518,1449504000"; d="scan'208";a="20773165" Subject: Re: [PATCH v5 10/12] x86/xen: Bypass intr mode setup in enlighten_pv system To: Thomas Gleixner References: <2545ef73fde4e3cf65080b056669dadd3578ff8a.1498795030.git.douly.fnst@cn.fujitsu.com> CC: , , , , , , , , , From: Dou Liyang Message-ID: <6590f710-28cf-05eb-06cf-a2e10f641870@cn.fujitsu.com> Date: Mon, 3 Jul 2017 15:17:53 +0800 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:45.0) Gecko/20100101 Thunderbird/45.4.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset="windows-1252"; format=flowed Content-Transfer-Encoding: 7bit X-Originating-IP: [10.167.226.106] X-yoursite-MailScanner-ID: DF3B646B53E2.ADBD1 X-yoursite-MailScanner: Found to be clean X-yoursite-MailScanner-From: douly.fnst@cn.fujitsu.com Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Length: 2065 Lines: 63 Hi Thomas, At 07/03/2017 02:56 PM, Thomas Gleixner wrote: > On Mon, 3 Jul 2017, Dou Liyang wrote: >> At 07/03/2017 03:18 AM, Thomas Gleixner wrote: >>> On Fri, 30 Jun 2017, Dou Liyang wrote: >>> >>>> xen_smp_ops overwrites smp_prepare_cpus to xen_pv_smp_prepare_cpus >>>> which initializes interrupt itself. >>>> >>>> Touching the intr_mode_init causes unexpected results on the system. >>>> >>>> Bypass it in enlighten_pv system. >>> >>> So that's the wrong patch order then. You broke XEN at some point with your >>> changes. You need to prevent that breakage upfront not after the fact. >> >> Yes, I have considered to prevent that breakage in the patchset. >> >> Actually, Until the 11th patch, we put the intr_mode_init ahead of >> time, which will break XEN. >> >> Before the 11th patch, we just unify the code and do the preparation, >> Kernel will do the intr_mode_init like before, which will have no >> influence on XEN. >> >> So we put the patch here before 11th patch. > > Ok. That's good, but please explain it in the changelog. I had the > impression that this is fixing breakage you introduced earlier, but now > with your explanation it makes sense. So the patch order is correct. > > Something like this wants to be in the changelog: > > 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 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(). Thank you very much for writing the changelog again. This is really the true purpose which I couldn't explain clearly. I am testing my V6 patchset, will send it out soon. Thanks, dou. > > Thanks, > > tglx > > >