[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

RE: [Xen-devel] [PATCH 8/9] Add cpu idle pwr mgmt to xen



On Tuesday, April 29, 2008 2:51 PM, Jan Beulich wrote:
>>>> "Wei, Gang" <gang.wei@xxxxxxxxx> 29.04.08 02:50 >>>
>> On Monday, April 28, 2008 5:38 PM, Jan Beulich wrote:
>>>>>> "Wei, Gang" <gang.wei@xxxxxxxxx> 25.04.08 07:09 >>>
>>>> Handle dom0_max_vcpus < nr_pcpu cases, e.g. UP dom0.
>>>> 
>>>> Just try to pass info about all acpi processors to xen even in such
>>>> cases. 
>>>> 
>>>> Signed-off-by: Tian Kevin <kevin.tian@xxxxxxxxx>
>>>> Signed-off-by: Wei Gang <gang.wei@xxxxxxxxx>
>>> 
>>> Are the changes done here native-compatible? They don't really look
like
>>> they are from a brief inspection... I'd be glad to read a closer
>>> explanation of what is being attempted here.
>> 
>> These changes should be native-compatible. We are attempting to make
>> ACPI info parsing work for all physical cpus even dom0 vcpu nr < phys
>> cpu nr. UP dom0 is a case requested by Keir for xen server probably
go
>> in that way. Without these changes, only BSP ACPI info can be parsed
and
>> passed to HV. Is that clear for you? Or any further comments?
> 
> I understand the intention, but I'm worried about breaking native
> kernels: If the changes you made are appropriate for native, then
> why aren't they upstream? And if they aren't or if there is any doubt,
> then they ought to at least be contained in #ifdef CONFIG_XEN blocks
> (but of course I'd much prefer not having many of these in generic
> code, and even more in ACPI CA code).

Most of these changes don't have any impact if no additional linux
kernel parameter (xen_processor_pmbits=) was added to kernel cmdline by
Xen or manually in grub.conf. Is it still necessary to add #ifdef
CONFIG_XEN even if those changes have no impact by default?

Jimmy

_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxxxxxxxx
http://lists.xensource.com/xen-devel


 


Rackspace

Lists.xenproject.org is hosted with RackSpace, monitoring our
servers 24x7x365 and backed by RackSpace's Fanatical Support®.