This is an archived copy of the Xen.org mailing list, which we have preserved to ensure that existing links to archives are not broken. The live archive, which contains the latest emails, can be found at http://lists.xen.org/
Home Products Support Community News


[Xen-devel] cpufreq/powernow-k8 on dual-core opterons

To: xen-devel@xxxxxxxxxxxxxxxxxxx
Subject: [Xen-devel] cpufreq/powernow-k8 on dual-core opterons
From: "Thom Linton" <thom.linton@xxxxxxxxx>
Date: Thu, 20 Apr 2006 13:35:07 -0400
Delivery-date: Thu, 20 Apr 2006 10:35:31 -0700
Domainkey-signature: a=rsa-sha1; q=dns; c=nofws; s=beta; d=gmail.com; h=received:message-id:date:from:to:subject:mime-version:content-type; b=c92yD0miuAQkbrpuhxhyzP7JPYtHzlRJlnGmjnXpM4h4GMElHHXfpcZSQyE1LgN7AbQdrAHqJls/gBeroA5izgSYIy6GTFdCjfZUoPHb4Y4hghYGAVvbGj/jKoRVeHL69xczgXSXLIV2O7qbtVL8HhqKuuPhhG5bgayOzWkyf70=
Envelope-to: www-data@xxxxxxxxxxxxxxxxxx
List-help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-id: Xen developer discussion <xen-devel.lists.xensource.com>
List-post: <mailto:xen-devel@lists.xensource.com>
List-subscribe: <http://lists.xensource.com/cgi-bin/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
List-unsubscribe: <http://lists.xensource.com/cgi-bin/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
Sender: xen-devel-bounces@xxxxxxxxxxxxxxxxxxx
I've been fiddling with cpufreq and the powernow-k8 driver to allow for fid/vid scaling in testing for a while, and had developed rdmsr(...) wrmsr(...) wrappers much like those that have been mentioned before on the list.

To get the sysfs entries correct ( e.g. given die0 contains {core0,core1} cpu1 links to cpu0, affected_cpus fields, etc.), I've had to hack the powernow driver to make a call during init to setup cpu_core_map. I've been pulling my hair out trying to discover where exactly it is init'd in the vanilla kernel that isn't executed on xen bootup. With a properly setup (via my hack) cpu_core_map, behaviour is correct, affected_cpus is filled appropriately, and cpufreq will scale the cores together.

I'd like to be able to patch for the general case - in the absense of my hack, though cpu_core_map still exists (the symbols being exported in smpboot.c, it is only marked for it's own core (i.e., Xen believes that a single die, dual core, opteron represents two distinct cpus). Proper initialization of cpu_core_map seems to depend on phys_proc_id and cpu_core_id which also appear to not be filled properly.

I'm working with arch i386 and I reason that init_amd (which will setup these maps) isn't being called; I've double checked to make sure that X86_HT was defined - any thoughts or pointers?

- Thom Linton
Xen-devel mailing list
<Prev in Thread] Current Thread [Next in Thread>