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

["Thom Linton" <thom.linton@xxxxxxxxx>]

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
Xen-devel@xxxxxxxxxxxxxxxxxxx
http://lists.xensource.com/xen-devel