lkml.org 
[lkml]   [2012]   [Mar]   [26]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
From
SubjectRE: [Xen-devel] [PATCH 1/2] RFC: Prepare PAD for native and xen platform
Date
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" <jinsong.liu@intel.com> 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



\
 
 \ /
  Last update: 2012-03-26 09:23    [W:0.069 / U:0.932 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site