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

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

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

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 
then 
notify Processor node
        - OSPM then re-evaluates _CST method
        - _CST method may be defined as something like:
                If local_flag equals to 0
                        Return _CST1
                Else
                        Return _CST2

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

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

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.

Thanks,
Kevin

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