RE: [Xen-devel] [PATCH] 1/2: cpufreq/PowerNow! in Xen: Time and platform
>From: Keir Fraser [mailto:Keir.Fraser@xxxxxxxxxxxx]
>Sent: 2007年9月1日 23:27
>On 1/9/07 15:18, "Tian, Kevin" <kevin.tian@xxxxxxxxx> wrote:
>> Yes, ACPI defines standard method _CST to export C-state
>> 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
>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
Event notification is OK, but the problem is how to retrieve the information
from user space. Firstly user application should be allowed to map ACPI
related memory area (interface exists today). Then that user application
may setup ACPI namespace and retrieve C-state information. However
whether it can work depends on low level implementations. For example,
one implementation can be:
- AC power change (Let's still take this example though the
relationship is clear yet. :-P)
- SCI is triggered with a GPE xxx
- Related _Lxxx method firstly set a local flag from '0' to '1' and
notify Processor node
- OSPM then re-evaluates _CST method
- _CST method may be defined as something like:
If local_flag equals to 0
In this case, the local flag change happens on the stack of dom0's kernel
(local variables in ACPI are not allocated in global ACPI data area). Then
even when user application receives the notification, it still observes
_CST1 instead of _CST2. To make it work, we have to emulate a similar
flow to force local variable on stack of user application changed properly.
However that flow is implementation specific and some hardware bits may
be touched in the middle which means more emulation to underlying
Maybe I'm too nervous and actual implementation may be very simple.
But ACPI does allow above condition.
>This would work fine unless the \_GPE.xxx methods redefined the _CST
>objects, causing userspace's value for the object (taken from static
>of DSDT/SSDT) to be out of date. That seems not very likely though, to
>the least; I'm just thinking through the scope here for 'self-modifying'
But that's possible, right? Just like one change you did before, to
'self-modifying' processor information from guest BIOS. If the
dynamically changed _CST requirement does exist, it's easy to provide
two versions of _CST and then copy one to some address dynamically.
I do see one implementation to specify _CST address in some reserved
region, instead of including in ACPI table explicitly. I think that gives
room for variable _CST implementation.
Xen-devel mailing list