Re: FW: cpufreq info propagation

["Jan Beulich" <jbeulich@novell.com>]

>Processor freq info is contained in ACPI Px methods in AML style,
>and thus there's no way for Xen to retrieve them without dom0's help.
>However existing ACPI parse logic is only compiled when CPU_FREQ 
>is configured. It'd be mess to copy those code out of CPU_FREQ.

I understand that - an alternative idea was to enable CONFIG_CPU_FREQ
by a (conditional) #define in the relevant core ACPI files. But that
should probably be considered only if getting things to work by tweaking
the core cpufreq code turns out to be no less intrusive.

>Also enable CPU_FREQ in dom0 doesn't mean the control goes to
>dom0. Dom0 only tempts to control when cpufreq driver is loaded, 
>and by far the driver is hacked from loading when extcnl is requesting.
>This is a bit hacky, and the cleaner way should move such check
>to generic cpufreq layer since there're so many drivers.

Indeed, if that was done e.g. by making cpufreq_register_driver()
fail in this case, I would feel much safer allowing the CPU_FREQ
options again. But that would imply that all the drivers behave
properly when that registration fails, and while powernow-k8
appears to do so, acpi-cpufreq doesn't seem to - it would (in .26)
at least leak per-CPU data allocated in acpi_cpufreq_early_init().

What I'm still unclear about is the role of the kernel governors when
Xen controls cpufreq.

Jan