RE: [Xen-devel] cpufreq status information

["Jan Beulich" <jbeulich@xxxxxxxxxx>]

>>> "Tian, Kevin" <kevin.tian@xxxxxxxxx> 08.09.08 15:22 >>>
>>From: Jan Beulich
>>Sent: 2008å9æ8æ 21:12
>>
>>Trying to understand whether CPU frequency scaling is actually 
>>working on
>>a system currently requires (afaics) source patches, as there 
>>is no way to
>>get the current state of a CPU. Even if this is intentional, 
>
>What do you mean by current state of CPU? If cpufreq is enabled,
>user should be able to retrieve statistics information by sysctl
>path.

How? I can't see where the current frequency a CPU is running at
is being exposed.

>>this doesn't seem
>>very helpful when considering to make this functionality available to
>>customers: I'm certain quite a few will ask how they can tell 
>>whether this
>>is actually working.
>>
>>Now, apart from the simple job of adding a sub-hypercall to 
>>retrieve the
>>necessary bits, I'm wondering whether this wouldn't be just one more
>>element that would much better be surfaced to the guest via the vCPU
>>info structure (or, as that's size constrained, a new construct to make
>>guest-read-only information available via a shared page). Other
>>(potential) items to make available this same way would e.g. be guest-
>>accessible last-exception-from/-to MSR values (as the values read would
>>be meaningless if read through rdmsr).
>
>Not quite understand. Cpufreq is physical cpu stuff, and do you aim
>to expose physical information through vcpu specific shared page?
>Then that would add fixed requirement on dom0 vcpu number to
>physical cpus, which is intentially avoided in current design.

The intent is to expose the frequency of the pCPU the particular vCPU
is currently running on, perhaps only in Dom0.

Jan

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