Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1423129Ab2JaPIA (ORCPT ); Wed, 31 Oct 2012 11:08:00 -0400 Received: from mga03.intel.com ([143.182.124.21]:58792 "EHLO mga03.intel.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1423111Ab2JaPHy convert rfc822-to-8bit (ORCPT ); Wed, 31 Oct 2012 11:07:54 -0400 X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="4.80,687,1344236400"; d="scan'208";a="211771856" From: "Liu, Jinsong" To: Konrad Rzeszutek Wilk CC: Konrad Rzeszutek Wilk , "linux-kernel@vger.kernel.org" , Jan Beulich , "xen-devel@lists.xen.org" Subject: RE: [Xen-devel] [PATCH 1/2] Xen acpi pad implement Thread-Topic: [Xen-devel] [PATCH 1/2] Xen acpi pad implement Thread-Index: AQHNt27gTi91BiFLfUibRvXA4zlK85fTgYow Date: Wed, 31 Oct 2012 15:07:49 +0000 Message-ID: References: <508A89CB020000780008E6ED@nat28.tlf.novell.com> <20121026201409.GF2708@phenom.dumpdata.com> <20121029123950.GK2708@phenom.dumpdata.com> <20121030133720.GA27463@phenom.dumpdata.com> <20121031135150.GA28699@phenom.dumpdata.com> In-Reply-To: <20121031135150.GA28699@phenom.dumpdata.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.239.127.40] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 8BIT MIME-Version: 1.0 Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Length: 2805 Lines: 69 Konrad Rzeszutek Wilk wrote: > On Tue, Oct 30, 2012 at 03:18:59PM +0000, Liu, Jinsong wrote: >> Konrad Rzeszutek Wilk wrote: >>>>> +config XEN_ACPI_PAD_STUB >>>>> + bool >>>>> + depends on XEN_DOM0 && X86_64 && ACPI >>>>> + default n >>>>> + >>>> >>>> This Kconfig is pointless, if CONFIG_XEN_ACPI_PAD_STUB = n, native >>>> pad would successfully registerred, and then mwait #UD (we would >>>> revert df88b2d96e36d9a9e325bfcd12eb45671cbbc937, right?). So xen >>>> stub logic should unconditionally built-in kernel. >>> >>> >>> Potentially. Keep in mind that there is no need to built this if the >>> kernel is not built with ACPI. >> >> Sure, 'obj-$(CONFIG_XEN_DOM0) +=' is enough. >> (XEN_DOM0 depends on ACPI). >> >>>>> +subsys_initcall(xen_acpi_pad_stub_init); >>>> >>>> I'm still confused. In this way there are xen-acpi-pad-stub.c and >>>> xen-acpi-pad.c, and you want to let xen-acpi-pad loaded as module, >>>> right? how can xen-acpi-pad logic work when it was insmoded? >>> >>> Via the register/unregister calls that this provides? Or does ACPI >>> bus drivers get immediately called once the call >>> acpi_bus_register_driver? >> >> But when xen stub driver registerred, real xen pad ops has not been >> hooked to stub ops. >> >>> >>> Or can one 'poke' the 'add' and 'remove' calls so that once the >>> "true" PAD driver is loaded it will restart the ops->add call? >> >> I think we'd better not to use xen pad stub approach. Technically >> it's complicated, say, how to match xen_acpi_pad driver w/ pad >> device? when and how to invoke .add method? how to avoid native pad >> loading risk? etc. I didn't find its obivous advantages, so how >> about keep simpler approach? > > OK. Lets go with that one for right now. The one thing I don't like > about it is that it is built-in. It would be so much better if it was > a module, but I am just not sure how to make that work with the > acpi_pad. Unless the mwait CPUID capability is not exported (so drop > your patch 1 that reverts a commit). Yes, but considering mwait case and its benefit to hypervisor, xen pad built-in kernel seems to be the price we have to pay. At least currently I didn't find better way. > > Perhaps there is a way to make it a module/built-in with some Kconfig > magic options? Say if ACPI_PROCESSOR_AGGREGATOR is not set, then we > can > make it a module. But if ACPI_PROCESSOR_AGGREGATOR=m|y then we do it > as built-in? Hmm, seems it's hard to express this logic in Kconfig, and that would make xen pad logic very complicated :) Thanks, Jinsong -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/