This is an archived copy of the Xen.org mailing list, which we have preserved to ensure that existing links to archives are not broken. The live archive, which contains the latest emails, can be found at http://lists.xen.org/
Home Products Support Community News


RE: [Xen-devel] cpufreq status information

To: "Jan Beulich" <jbeulich@xxxxxxxxxx>, <xen-devel@xxxxxxxxxxxxxxxxxxx>
Subject: RE: [Xen-devel] cpufreq status information
From: "Tian, Kevin" <kevin.tian@xxxxxxxxx>
Date: Mon, 8 Sep 2008 21:22:13 +0800
Delivery-date: Mon, 08 Sep 2008 06:22:38 -0700
Envelope-to: www-data@xxxxxxxxxxxxxxxxxxx
In-reply-to: <48C540DC.76E4.0078.0@xxxxxxxxxx>
List-help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-id: Xen developer discussion <xen-devel.lists.xensource.com>
List-post: <mailto:xen-devel@lists.xensource.com>
List-subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
List-unsubscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
References: <48C540DC.76E4.0078.0@xxxxxxxxxx>
Sender: xen-devel-bounces@xxxxxxxxxxxxxxxxxxx
Thread-index: AckRtJYLcwh+x31bQjyf7OINHH7UvQAAHyqg
Thread-topic: [Xen-devel] cpufreq status information
>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

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


>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