Re: [Xen-devel] [PATCH 2 of 2] linux-xencommons: Load processor-passthru

["Jan Beulich" <JBeulich@xxxxxxxx>]

>>> On 05.03.12 at 03:49, Konrad Rzeszutek Wilk <konrad@xxxxxxxxxx> wrote:
>>>> Furthermore, given the purpose of the driver, I'm thinking that this
>>>> is too late in the boot process anyway, and the driver should rather
>>>> be loaded at the point where other CPUFreq drivers would normally
>>>> be by a particular distro (which would still be later than when the
> 
> In Ubuntu and Fedora they are set to:
> CONFIG_X86_POWERNOW_K8=y
> CONFIG_X86_ACPI_CPUFREQ=y
> 
> (thought previous to Fedora 16 POWERNOW_K8 was =m, per
> https://bugzilla.redhat.com/show_bug.cgi?id=739159, " powernow-k8
> transitions fail in xen dom0")
> 
> Looking at how the built is done with =y, the cpufreq drivers are loaded
> in the late_init stage and there is a strict order 
> (drivers/cpufreq/Makefile):
>   # x86 drivers.
>   # Link order matters. K8 is preferred to ACPI because of firmware
> bugs in early
>   # K8 systems. ACPI is preferred to all other hardware-specific drivers.
>   # speedstep-* is preferred over p4-clockmod.
> 
> Both of them (acpi-cpufreq.c and powernow-k8.c) have a symbol
> dependency on drivers/acpi/processor.c

But them being 'm' or 'y' shouldn't matter in the end.

>> mail, having the thing be a governor is likely the wrong choice - it ought
>> to be a driver).
>>
> 
> By driver, I think you mean either a) a new cpufreq scaling driver, or
> b) the processor-core driver.

I really meant a).

> For a), this would mean some form of unregistering the existing
> cpufreq scaling drivers.The reason

Or loading before them (and not depending on them), thus
preventing them from loading successfully.

> for that is we want to use the generic ones (acpi-cpufreq and
> powernow-k8) b/c they do all the filtering and parsing of the ACPI
> data instead of re-implementing it in our own cpufreq-xen-scaling.
> Thought one other option is to export both powernow-k8 and
> acpi-cpufreq functions that do this and use them within the
> cpufreq-xen-scaling-driver but that sounds icky.

Indeed.

> 2). Upload the power management information up to the hypervisor.

Which doesn't require cpufreq drivers at all (in non-pv-ops we simply
suppress the CPU_FREQ config option when XEN is set).

Jan


_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxx
http://lists.xen.org/xen-devel