Hi, Mark,

Some comments here:

a) Current approach is simple to let Dom0 conduct frequency change. That should be OK in the start, but at the same time we should also consider the on-demand governor within Xen itself. Xen can always get first-hand data about domain status, while dom0 (either user-level or in-kernel) can't achieve in time. Fine- grained frequency change is more likely to be achieved within Xen directly.

b) Did you miss some part of patch? I didn't see place within Xen to handle new platform hypercall. Also please don't mix Linux and Xen change altogether in one patch.

c) I took a look at your previous version. It seemed that you need do some change to Xen's calibration code. The calibration happens once per second on local processor. Say [start,end] of calibration period is [t0, t2], and frequency change happens at [t1] and Xen is notified with that event at [t1']. Here we get several problematic window: t1 < t < t1': dom0 still uses old scale while TSC frequency already changes t1' < t < t2: dom0 uses right scale matching TSC change t2: Xen runs its calibration timer while this period is with mixed frequency and Xen will get a new frequency [new'] something between [old, new]. Such mismatch may make dom0 misinterpret elapsed TSC offset. So I think one thing you can try is to stop calibration timer at t1', change scale, and then restart calibration timer again. But the mismatch between [t1, t1'] is difficult to be solved unless in-xen governor is used. :-)

d) How about adding a 'cpufreq' boot option? Once it's on, dom0_vcpus_pin is forced to on too. Or else it really doesn't make sense to let dom0 conduct frequency change.

Thanks, Kevin

From: Mark Langsdorf