RE: [Xen-devel] cpufreq status information

["Tian, Kevin" <kevin.tian@xxxxxxxxx>]

>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.

>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.

I guess I may get your intent wrong though.

Thanks,
Kevin

>
>So I'm basically considering to add a generic mechanism first, and then
>make cpufreq the first user of it. The question just is - use 
>a completely
>new (guest-ro) per-vCPU page, perhaps with chained descriptors rather
>than a fixed layout, or extend the vCPU info structure, but 
>e.g. require
>the guest to use VCPUOP_register_vcpu_info to gain access to all
>structure fields.
>
>Thanks, Jan
>

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