[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
|
Lists.xenproject.org is hosted with RackSpace, monitoring our |