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

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

>From: Keir Fraser [mailto:keir@xxxxxxxxxxxxx]
>Sent: 2007年8月30日 18:12
>
>On 30/8/07 10:45, "Tian, Kevin" <kevin.tian@xxxxxxxxx> wrote:
>
>> Sure, some experiment can be done later to compare dom0 userspace
>> and in-xen governor. Agree that in-kernel dom0 approach is not
>> charming because anyway it needs help from either user-level or xen
>> for global view.
>>
>> Actually finally we may take both. Xen takes simple heuristic policy
>> with user-level governor to adjust with more complex and flexible
>> policies based on domain behaviors. :-)
>
>There is the problem, though, that most modern CPUs will need cpufreq
>info
>to be parsed out of the ACPI DSDT. And Xen can't do that itself unaided.
>Pushing down some form of cpufreq info table to Xen *is* an option
>though,
>but we'd need more custom dom0 kernel code to do that. Or we'd need
>to do it
>from a userspace program.
>
> -- Keir

Yes, that information has to be parsed and notified to Xen. Some PV l
ogic needs to be hooked into cpufreq as you said. Userspace program 
is a good choice too, like the user level ACPI interpreter. However the 
major block is to parse dynamically changed information. For example, 
cpufreq info may change (due to some hardware events) and OSPM 
is required to re-evaluate P-state info. That re-evaluation may get 
different info after checking some hardware bits. To do it in user level, 
firstly we need emulate an event and then need virtualize those bits. 
Not very easy to track. So I more agree with you that an user-level 
stuff is the way to go, at least for the start.

Thanks,
Kevin

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