[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Xen-devel] [PATCH] 1/2: cpufreq/PowerNow! in Xen: Time and platform changes


  • To: "Tian, Kevin" <kevin.tian@xxxxxxxxx>, <xen-devel@xxxxxxxxxxxxxxxxxxx>
  • From: Keir Fraser <Keir.Fraser@xxxxxxxxxxxx>
  • Date: Sat, 01 Sep 2007 16:26:44 +0100
  • Delivery-date: Sat, 01 Sep 2007 08:22:49 -0700
  • List-id: Xen developer discussion <xen-devel.lists.xensource.com>
  • Thread-index: Acfqh8RwaTy8r4iaT0y7Njlwu+54dgAROIeQAAbzeNkAABsToAABWQIjAB9V6qAAErBLqwAKHGtwAAEaJJoAEo/UwAAWs08+AATSlUAAAaaT2AAAE0xAAAKCnfM=
  • Thread-topic: [Xen-devel] [PATCH] 1/2: cpufreq/PowerNow! in Xen: Time and platform changes

On 1/9/07 15:18, "Tian, Kevin" <kevin.tian@xxxxxxxxx> wrote:

> Yes, ACPI defines standard method _CST to export C-state information
> and a notification to that object is forced (as part of ACPI event like a
> GPE) at some hardware status change. Then OSPM can re-evaluate
> _CST. Such event should be rare, and thus a periodical poll is not
> necessary.

I was just wondering about doing it from dom0 userland. I've dug into it a
bit now, and it looks like the right answer is to hook into the 'acpid'
daemon. This can be configured to give notifications for power-management
changes.

This would work fine unless the \_GPE.xxx methods redefined the _CST
objects, causing userspace's value for the object (taken from static parsing
of DSDT/SSDT) to be out of date. That seems not very likely though, to say
the least; I'm just thinking through the scope here for 'self-modifying'
AML. :-)

 -- Keir



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


 


Rackspace

Lists.xenproject.org is hosted with RackSpace, monitoring our
servers 24x7x365 and backed by RackSpace's Fanatical Support®.