Xen devel - Apr 2006 - cpufreq/powernow-k8 on dual-core opterons

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

> 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?
Yes, we need a hypervisor interface for extracting this topology 
information. Then we could set up the maps in our own smpboot.c.

  -- Keir


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel