Xen devel - Jan 2009 - AW: Create a linux-2.6.18-xen.hg Kernel with CPU_FREQ support

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@intel.com>
Gesendet: Mit, 14.1.2009 03:07
An: ''Carsten Schiers'' <carsten@schiers.de> ; xen-devel
<xen-devel@lists.xensource.com>
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@lists.xensource.com
http://lists.xensource.com/xen-devel

I see your concern and that''s why I''d like to ask for more
comments.
Change itself is easy anyway. Jan, how about your opinion on this
since you''re from OSV? :-) I''m inclined to vote this, as we
already
change common acpi code with external control condition which is
designed to be neutral.

Thanks,
Kevin
>From: Carsten Schiers [mailto:carsten@schiers.de] 
>Sent: Wednesday, January 14, 2009 8:03 PM
>
>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@intel.com>
>Gesendet: Mit, 14.1.2009 03:07
>An: ''Carsten Schiers'' <carsten@schiers.de> ;
xen-devel
><xen-devel@lists.xensource.com>
>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@lists.xensource.com
http://lists.xensource.com/xen-devel