Re: [Xen-devel] cpufreq support status

["Jan Beulich" <jbeulich@xxxxxxxxxx>]

>>> Keir Fraser <Keir.Fraser@xxxxxxxxxxxx> 17.10.07 17:22 >>>
>On 17/10/07 16:11, "Jan Beulich" <jbeulich@xxxxxxxxxx> wrote:
>
>>> It's definitely k8-powernow only right now. acpi-cpufreq might work if the
>>> control register is an i/o port. It won't work if the control register is an
>>> MSR, since the MSR would not be whitelisted in the WRMSR emulation in
>>> emulate_privileged_op().
>> 
>> Does ACPI have means to specify MSRs as the access mechanism? I don't
>> recall platform specific behavior like this, I thought this was restricted to
>> the set of types named ACPI_ADR_SPACE_* in Linux' include/acpi/actypes.h
>> (and which already goes beyond what is in ACPI 3.0b).
>
>Well, kind of but not really. ACPI_ADR_SPACE_FIXED_HARDWARE is used, and
>this is a cop-out in the ACPI spec which means 'the OS needs extra info from
>the CPU vendor'. So typically for power management it means that CPUID must
>be mined to discover whether e.g., PowerNow or EnhancedSpeedStep MSRs should
>be used.

Looking into this some more, I find that ACPI_ADR_SPACE_FIXED_HARDWARE
is mostly unsupported in Linux except for C-state handling, in which case is
resolves to MWAIT.

>This effectively means that the range of possible power-management MSRs is
>very limited (since they cannot be specified dynamically in the ACPI tables)
>and Xen itself should easily be able to probe for and dynamically white-list
>available MSRs as appropriate. Probably all that needs to be added is
>support for EnhancedSpeedStep MSRs, since we already have PowerNow support.

Jan


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