Thanks, seems to work (still compiling).
Xen cpufreq (so I learnt) only supports AMD CPUs from Family 10 on. Which
excludes,
I guess, the majority of systems, although I have to admit that normal Xen
usage is
not like mine for a home network.
For those cases, I have understood cpufreq=dom0-kernel being the standard,
which
includes the need to have the CPU_FREQ part enabled.
I understand the problem and I am far from giving advice here, but from a user's
persepctive, it might not be necessary to implement code control of possible
misuse,
but maybe to control thru configuration what case your heading at. Or at least
a small
hint in the README would do... ;o).
I am anyhow in trouble, as pre-Fam10 AMD CPUs lacks P-State invariant TSCs,
what is
causing other trouble.
Thanks,
Carsten.
----- Originalnachricht -----
Von: "Tian, Kevin" <kevin.tian@xxxxxxxxx>
Gesendet: Mit, 14.1.2009 03:07
An: 'Carsten Schiers' <carsten@xxxxxxxxxx> ; xen-devel
<xen-devel@xxxxxxxxxxxxxxxxxxx>
Betreff: RE: [Xen-devel] Create a linux-2.6.18-xen.hg Kernel with CPU_FREQ
support
>From: Carsten Schiers
>Sent: Wednesday, January 14, 2009 5:16 AM
>
>Excuse my missing knowledge, but how do I enable CPU_FREQ support when
>building Xen
>hypervisor and especially the kernel from sources? When doing e.g. a
>
> hg clone http://xenbits.xensource.com/xen-unstable.hg
> make world
>
>the resulting kernel will now create e.g. powernow-k8.ko.
>
>When I do a
>
> make linux-2.6-xen-prep
> cd build-linux-2.6.18-xen_x86_64
> make menuconfig
>
>all CPU_FREQ options are not accessable.
>
>Thanks,
>Carsten.
>
It's intentional since Xen itself supports cpufreq now. To avoid
dependency on dom0's CONFIG_CPU_FREQ and also intrusive
checks on whether external control is enabled in every linux
cpufreq drivers, CPU_FREQ in dom0 is silented by default now.
It's not a neat approach, but makes sense since xen controlled
cpufreq is sure a better model. You can enable CPU_FREQ in
dom0 manually though, by removing below dependency.
(drivers/cpufreq/Kconfig)
config CPU_FREQ
bool "CPU Frequency scaling"
----> depends on !PROCESSOR_EXTERNAL_CONTROL
However once that dependency is removed, there's no automatic
check to avoid confliction when dom0 and xen both want to
control freq change, and then you should keep an eye yourself.
One alternative to relax this limitation, is to move external control
check up from drivers to cpufreq common layer. Just several lines
change to block dom0 cpufreq when xen controlled method is
activated, but one drawback is in architecture-neutral files. Comments?
Thanks,
Kevin
_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxxxxxxxx
http://lists.xensource.com/xen-devel
|
Home