From mboxrd@z Thu Jan 1 00:00:00 1970 From: "Liu, Jinsong" Subject: RE: [Xen-devel] [PATCH 1/2] RFC: Prepare PAD for native and xen platform Date: Mon, 26 Mar 2012 07:21:22 +0000 Message-ID: References: <4F46530B020000780007F751@nat28.tlf.novell.com> <20120226173458.GB18098@phenom.dumpdata.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 8BIT Return-path: Received: from mga14.intel.com ([143.182.124.37]:51900 "EHLO mga14.intel.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751274Ab2CZHV0 convert rfc822-to-8bit (ORCPT ); Mon, 26 Mar 2012 03:21:26 -0400 In-Reply-To: Content-Language: en-US Sender: linux-acpi-owner@vger.kernel.org List-Id: linux-acpi@vger.kernel.org To: Konrad Rzeszutek Wilk Cc: "Brown, Len" , "xen-devel@lists.xensource.com" , "linux-kernel@vger.kernel.org" , "linux-acpi@vger.kernel.org" , "keir.xen@gmail.com" , Jan Beulich , "Li, Shaohua" , "lenb@kernel.org" , "Liu, Jinsong" Liu, Jinsong wrote: > Liu, Jinsong wrote: >> Konrad Rzeszutek Wilk wrote: >>> On Sun, Feb 26, 2012 at 08:25:41AM +0000, Liu, Jinsong wrote: >>>> Liu, Jinsong wrote: >>>>> Jan Beulich wrote: >>>>>>>>> "Liu, Jinsong" 02/23/12 2:29 PM >>> >>>>>>> --- a/drivers/acpi/Kconfig >>>>>>> +++ b/drivers/acpi/Kconfig >>>>>>> @@ -213,10 +213,11 @@ config ACPI_HOTPLUG_CPU >>>>>>> default y >>>>>> > >>>>>>> config ACPI_PROCESSOR_AGGREGATOR >>>>>>> - tristate "Processor Aggregator" >>>>>>> + bool "Processor Aggregator" >>>>>> >>>>>> There must be ways to address whatever strange problem you see >>>>>> without making this piece of code non-modular. >>>>>> >>>>> >>>>> Yes, another approach is x86_init approach, defining acpi_pad_ops >>>>> at x86_init.c and overwritten when xen_start_kernel. This patch is >>>>> just a RFC patch, to evaluate which approch is more reasonable :-) >>>>> >>>> >>>> Have a more think about it, x86_init approach still need to disable >>>> acpi_pad module. Seems we have to set acpi_pad as bool, as long as >>>> it need to hook to native acpi_pad fucs/variables. >>> >>> What about the other approach I suggested where there are some >>> function overrides in osl.c? Something similar to >>> https://lkml.org/lkml/2012/1/17/401, specifically >>> https://lkml.org/lkml/2012/1/17/403 - that way you are not turning >>> the modules into being built in, but intead have the function table >>> already in the kernel (as some form of EXPORT_SYMBOL_GPL or a >>> registration function). >>> >> >> Thanks for the example (it's good itself :-), but per my >> understanding they are different cases. >> >> In the osl example case, tboot_late_init call >> acpi_os_set_prepare_sleep to register func, so it works no matter >> tboot.c built as y/n/m (through currently it's bool). >> >> However, in our case, we just cannot do so. We need >> 1. predefine a hook to native acpi pad funcs, take effect when >> static compile stage; >> 2. when xen init, redirect the hook to xen acpi pad funcs, take >> effect at running time; (The point is, we cannot do init twice for >> native and xen acpi pad, so we have to statically predefine a hook >> to native acpi_pad) >> >> For the reason above, I think we have to remove acpi_pad module, as >> long as we need to hook to native acpi_pad funcs. Thoughts? >> > > Compare approaches: > > 1. xen overwritten approach (patches V2, x86_init, osl approach) > Pros: > a little simpler code > Cons: > 1). specific to xen, cannot extend to other virt platform; > 2). need to change natvie acpi_pad as modular; > > 2. paravirt interface approach (original patches V1) > Pros: > 1). standard hypervisor-agnostic interface (USENIX conference > 2006), can easily hook to Xen/lguest/... on demand; 2). arch > independent; 3). no need to change native acpi_pad as > non-modular; Cons: > a little complicated code, and code patching is some > overkilled for this case (but no harm); > > (BTW, in the future we need add more and more pv ops, like pv_pm_ops, > pv_cpu_hotplug_ops, pv_mem_hotplug_ops, etc. So how about add a > pv_misc_ops template to handle them all? seems it's a common issue). > > Your opinion? > Konrad, Comments? we need make sure which approach we choose (patches for both approaches are basically done and tested). IMO I prefer paravirt interface approach (it need slightly update for the purpose of 'not change acpi_pad as non-modular'. If choose it I will update ASAP). Thanks, Jinsong