<feed xmlns='http://www.w3.org/2005/Atom'>
<title>linux.git/tools/power/cpupower/utils, branch v5.5</title>
<subtitle>Linux kernel source tree</subtitle>
<link rel='alternate' type='text/html' href='https://git.tavy.me/linux.git/'/>
<entry>
<title>cpupower: mperf_monitor: Update cpupower to use the RDPRU instruction</title>
<updated>2019-11-06T00:22:56+00:00</updated>
<author>
<name>Janakarajan Natarajan</name>
<email>Janakarajan.Natarajan@amd.com</email>
</author>
<published>2019-11-05T17:16:55+00:00</published>
<link rel='alternate' type='text/html' href='https://git.tavy.me/linux.git/commit/?id=6af2ed53f0402c09b36d2b38698e18a25ca732a7'/>
<id>6af2ed53f0402c09b36d2b38698e18a25ca732a7</id>
<content type='text'>
AMD Zen 2 introduces the RDPRU instruction which can be used to access some
processor registers which are typically only accessible in privilege level
0. ECX specifies the register to read and EDX:EAX will contain the value read.

ECX: 0 - Register MPERF
     1 - Register APERF

This has the added advantage of not having to use the msr module, since the
userspace to kernel transitions which occur during each read_msr() might
cause APERF and MPERF to go out of sync.

Signed-off-by: Janakarajan Natarajan &lt;Janakarajan.Natarajan@amd.com&gt;
Acked-by: Thomas Renninger &lt;trenn@suse.de&gt;
Signed-off-by: Shuah Khan &lt;skhan@linuxfoundation.org&gt;
</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
AMD Zen 2 introduces the RDPRU instruction which can be used to access some
processor registers which are typically only accessible in privilege level
0. ECX specifies the register to read and EDX:EAX will contain the value read.

ECX: 0 - Register MPERF
     1 - Register APERF

This has the added advantage of not having to use the msr module, since the
userspace to kernel transitions which occur during each read_msr() might
cause APERF and MPERF to go out of sync.

Signed-off-by: Janakarajan Natarajan &lt;Janakarajan.Natarajan@amd.com&gt;
Acked-by: Thomas Renninger &lt;trenn@suse.de&gt;
Signed-off-by: Shuah Khan &lt;skhan@linuxfoundation.org&gt;
</pre>
</div>
</content>
</entry>
<entry>
<title>cpupower: mperf_monitor: Introduce per_cpu_schedule flag</title>
<updated>2019-11-06T00:22:46+00:00</updated>
<author>
<name>Janakarajan Natarajan</name>
<email>Janakarajan.Natarajan@amd.com</email>
</author>
<published>2019-11-05T17:16:54+00:00</published>
<link rel='alternate' type='text/html' href='https://git.tavy.me/linux.git/commit/?id=7adafe541fe5e015261a92d39db8b163db477337'/>
<id>7adafe541fe5e015261a92d39db8b163db477337</id>
<content type='text'>
The per_cpu_schedule flag is used to move the cpupower process to the cpu
on which we are looking to read the APERF/MPERF registers.

This prevents IPIs from being generated by read_msr()s as we are already
on the cpu of interest.

Ex: If cpupower is running on CPU 0 and we execute

    read_msr(20, MSR_APERF, val) then,
    read_msr(20, MSR_MPERF, val)

    the msr module will generate an IPI from CPU 0 to CPU 20 to query
    for the MSR_APERF and then the MSR_MPERF in separate IPIs.

This delay, caused by IPI latency, between reading the APERF and MPERF
registers may cause both of them to go out of sync.

The use of the per_cpu_schedule flag reduces the probability of this
from happening. It comes at the cost of a negligible increase in cpu
consumption caused by the migration of cpupower across each of the
cpus of the system.

Signed-off-by: Janakarajan Natarajan &lt;Janakarajan.Natarajan@amd.com&gt;
Acked-by: Thomas Renninger &lt;trenn@suse.de&gt;
Signed-off-by: Shuah Khan &lt;skhan@linuxfoundation.org&gt;
</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
The per_cpu_schedule flag is used to move the cpupower process to the cpu
on which we are looking to read the APERF/MPERF registers.

This prevents IPIs from being generated by read_msr()s as we are already
on the cpu of interest.

Ex: If cpupower is running on CPU 0 and we execute

    read_msr(20, MSR_APERF, val) then,
    read_msr(20, MSR_MPERF, val)

    the msr module will generate an IPI from CPU 0 to CPU 20 to query
    for the MSR_APERF and then the MSR_MPERF in separate IPIs.

This delay, caused by IPI latency, between reading the APERF and MPERF
registers may cause both of them to go out of sync.

The use of the per_cpu_schedule flag reduces the probability of this
from happening. It comes at the cost of a negligible increase in cpu
consumption caused by the migration of cpupower across each of the
cpus of the system.

Signed-off-by: Janakarajan Natarajan &lt;Janakarajan.Natarajan@amd.com&gt;
Acked-by: Thomas Renninger &lt;trenn@suse.de&gt;
Signed-off-by: Shuah Khan &lt;skhan@linuxfoundation.org&gt;
</pre>
</div>
</content>
</entry>
<entry>
<title>cpupower: Move needs_root variable into a sub-struct</title>
<updated>2019-11-06T00:22:01+00:00</updated>
<author>
<name>Janakarajan Natarajan</name>
<email>Janakarajan.Natarajan@amd.com</email>
</author>
<published>2019-11-05T17:16:52+00:00</published>
<link rel='alternate' type='text/html' href='https://git.tavy.me/linux.git/commit/?id=d3f5d2a192a299f56579ae6e6283f9011b00208f'/>
<id>d3f5d2a192a299f56579ae6e6283f9011b00208f</id>
<content type='text'>
Move the needs_root variable into a sub-struct. This is in preparation
for adding a new flag for cpuidle_monitor.

Update all uses of the needs_root variable to reflect this change.

Signed-off-by: Janakarajan Natarajan &lt;Janakarajan.Natarajan@amd.com&gt;
Acked-by: Thomas Renninger &lt;trenn@suse.de&gt;
Signed-off-by: Shuah Khan &lt;skhan@linuxfoundation.org&gt;
</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
Move the needs_root variable into a sub-struct. This is in preparation
for adding a new flag for cpuidle_monitor.

Update all uses of the needs_root variable to reflect this change.

Signed-off-by: Janakarajan Natarajan &lt;Janakarajan.Natarajan@amd.com&gt;
Acked-by: Thomas Renninger &lt;trenn@suse.de&gt;
Signed-off-by: Shuah Khan &lt;skhan@linuxfoundation.org&gt;
</pre>
</div>
</content>
</entry>
<entry>
<title>cpupower : Handle set and info subcommands correctly</title>
<updated>2019-11-04T20:11:57+00:00</updated>
<author>
<name>Abhishek Goel</name>
<email>huntbag@linux.vnet.ibm.com</email>
</author>
<published>2019-10-17T05:56:39+00:00</published>
<link rel='alternate' type='text/html' href='https://git.tavy.me/linux.git/commit/?id=d80a4ac20800035c46a3868ad9e11ebda0049c7d'/>
<id>d80a4ac20800035c46a3868ad9e11ebda0049c7d</id>
<content type='text'>
Cpupower tool has set and info options which are being used only by
x86 machines. This patch removes support for these two subcommands
from cpupower utility for POWER. Thus, these two subcommands will now be
available only for intel.
This removes the ambiguous error message while using set option in case
of using non-intel systems.

Without this patch on a POWER system:

root@ubuntu:~# cpupower info
System does not support Intel's performance bias setting

root@ubuntu:~# cpupower set -b 10
Error setting perf-bias value on CPU

With this patch on a POWER box:

root@ubuntu:~# cpupower info
Subcommand not supported on POWER

Same result for set subcommand.
This patch does not affect results on a intel box.

Signed-off-by: Abhishek Goel &lt;huntbag@linux.vnet.ibm.com&gt;
Acked-by: Thomas Renninger &lt;trenn@suse.de&gt;
Reviewed-by: Shuah Khan &lt;skhan@linuxfoundation.org&gt;
Signed-off-by: Shuah Khan &lt;skhan@linuxfoundation.org&gt;
</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
Cpupower tool has set and info options which are being used only by
x86 machines. This patch removes support for these two subcommands
from cpupower utility for POWER. Thus, these two subcommands will now be
available only for intel.
This removes the ambiguous error message while using set option in case
of using non-intel systems.

Without this patch on a POWER system:

root@ubuntu:~# cpupower info
System does not support Intel's performance bias setting

root@ubuntu:~# cpupower set -b 10
Error setting perf-bias value on CPU

With this patch on a POWER box:

root@ubuntu:~# cpupower info
Subcommand not supported on POWER

Same result for set subcommand.
This patch does not affect results on a intel box.

Signed-off-by: Abhishek Goel &lt;huntbag@linux.vnet.ibm.com&gt;
Acked-by: Thomas Renninger &lt;trenn@suse.de&gt;
Reviewed-by: Shuah Khan &lt;skhan@linuxfoundation.org&gt;
Signed-off-by: Shuah Khan &lt;skhan@linuxfoundation.org&gt;
</pre>
</div>
</content>
</entry>
<entry>
<title>tools/power/cpupower: Fix initializer override in hsw_ext_cstates</title>
<updated>2019-10-01T23:38:12+00:00</updated>
<author>
<name>Nathan Chancellor</name>
<email>natechancellor@gmail.com</email>
</author>
<published>2019-09-27T16:26:42+00:00</published>
<link rel='alternate' type='text/html' href='https://git.tavy.me/linux.git/commit/?id=7e5705c635ecfccde559ebbbe1eaf05b5cc60529'/>
<id>7e5705c635ecfccde559ebbbe1eaf05b5cc60529</id>
<content type='text'>
When building cpupower with clang, the following warning appears:

 utils/idle_monitor/hsw_ext_idle.c:42:16: warning: initializer overrides
 prior initialization of this subobject [-Winitializer-overrides]
                 .desc                   = N_("Processor Package C2"),
                                              ^~~~~~~~~~~~~~~~~~~~~~
 ./utils/helpers/helpers.h:25:33: note: expanded from macro 'N_'
 #define N_(String) gettext_noop(String)
                                 ^~~~~~
 ./utils/helpers/helpers.h:23:30: note: expanded from macro
 'gettext_noop'
 #define gettext_noop(String) String
                              ^~~~~~
 utils/idle_monitor/hsw_ext_idle.c:41:16: note: previous initialization
 is here
                 .desc                   = N_("Processor Package C9"),
                                              ^~~~~~~~~~~~~~~~~~~~~~
 ./utils/helpers/helpers.h:25:33: note: expanded from macro 'N_'
 #define N_(String) gettext_noop(String)
                                 ^~~~~~
 ./utils/helpers/helpers.h:23:30: note: expanded from macro
 'gettext_noop'
 #define gettext_noop(String) String
                             ^~~~~~
 1 warning generated.

This appears to be a copy and paste or merge mistake because the name
and id fields both have PC9 in them, not PC2. Remove the second
assignment to fix the warning.

Fixes: 7ee767b69b68 ("cpupower: Add Haswell family 0x45 specific idle monitor to show PC8,9,10 states")
Link: https://github.com/ClangBuiltLinux/linux/issues/718
Signed-off-by: Nathan Chancellor &lt;natechancellor@gmail.com&gt;
Signed-off-by: Shuah Khan &lt;skhan@linuxfoundation.org&gt;
</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
When building cpupower with clang, the following warning appears:

 utils/idle_monitor/hsw_ext_idle.c:42:16: warning: initializer overrides
 prior initialization of this subobject [-Winitializer-overrides]
                 .desc                   = N_("Processor Package C2"),
                                              ^~~~~~~~~~~~~~~~~~~~~~
 ./utils/helpers/helpers.h:25:33: note: expanded from macro 'N_'
 #define N_(String) gettext_noop(String)
                                 ^~~~~~
 ./utils/helpers/helpers.h:23:30: note: expanded from macro
 'gettext_noop'
 #define gettext_noop(String) String
                              ^~~~~~
 utils/idle_monitor/hsw_ext_idle.c:41:16: note: previous initialization
 is here
                 .desc                   = N_("Processor Package C9"),
                                              ^~~~~~~~~~~~~~~~~~~~~~
 ./utils/helpers/helpers.h:25:33: note: expanded from macro 'N_'
 #define N_(String) gettext_noop(String)
                                 ^~~~~~
 ./utils/helpers/helpers.h:23:30: note: expanded from macro
 'gettext_noop'
 #define gettext_noop(String) String
                             ^~~~~~
 1 warning generated.

This appears to be a copy and paste or merge mistake because the name
and id fields both have PC9 in them, not PC2. Remove the second
assignment to fix the warning.

Fixes: 7ee767b69b68 ("cpupower: Add Haswell family 0x45 specific idle monitor to show PC8,9,10 states")
Link: https://github.com/ClangBuiltLinux/linux/issues/718
Signed-off-by: Nathan Chancellor &lt;natechancellor@gmail.com&gt;
Signed-off-by: Shuah Khan &lt;skhan@linuxfoundation.org&gt;
</pre>
</div>
</content>
</entry>
<entry>
<title>cpupower : frequency-set -r option misses the last cpu in related cpu list</title>
<updated>2019-06-04T15:06:50+00:00</updated>
<author>
<name>Abhishek Goel</name>
<email>huntbag@linux.vnet.ibm.com</email>
</author>
<published>2019-05-29T09:30:33+00:00</published>
<link rel='alternate' type='text/html' href='https://git.tavy.me/linux.git/commit/?id=04507c0a9385cc8280f794a36bfff567c8cc1042'/>
<id>04507c0a9385cc8280f794a36bfff567c8cc1042</id>
<content type='text'>
To set frequency on specific cpus using cpupower, following syntax can
be used :
cpupower -c #i frequency-set -f #f -r

While setting frequency using cpupower frequency-set command, if we use
'-r' option, it is expected to set frequency for all cpus related to
cpu #i. But it is observed to be missing the last cpu in related cpu
list. This patch fixes the problem.

Signed-off-by: Abhishek Goel &lt;huntbag@linux.vnet.ibm.com&gt;
Reviewed-by: Thomas Renninger &lt;trenn@suse.de&gt;
Signed-off-by: Shuah Khan &lt;skhan@linuxfoundation.org&gt;
</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
To set frequency on specific cpus using cpupower, following syntax can
be used :
cpupower -c #i frequency-set -f #f -r

While setting frequency using cpupower frequency-set command, if we use
'-r' option, it is expected to set frequency for all cpus related to
cpu #i. But it is observed to be missing the last cpu in related cpu
list. This patch fixes the problem.

Signed-off-by: Abhishek Goel &lt;huntbag@linux.vnet.ibm.com&gt;
Reviewed-by: Thomas Renninger &lt;trenn@suse.de&gt;
Signed-off-by: Shuah Khan &lt;skhan@linuxfoundation.org&gt;
</pre>
</div>
</content>
</entry>
<entry>
<title>treewide: Replace GPLv2 boilerplate/reference with SPDX - rule 166</title>
<updated>2019-05-30T18:26:39+00:00</updated>
<author>
<name>Thomas Gleixner</name>
<email>tglx@linutronix.de</email>
</author>
<published>2019-05-27T06:55:14+00:00</published>
<link rel='alternate' type='text/html' href='https://git.tavy.me/linux.git/commit/?id=4f19048fd0a0036e02443237952db5bfa5b5cdf0'/>
<id>4f19048fd0a0036e02443237952db5bfa5b5cdf0</id>
<content type='text'>
Based on 1 normalized pattern(s):

  licensed under the terms of the gnu gpl license version 2

extracted by the scancode license scanner the SPDX license identifier

  GPL-2.0-only

has been chosen to replace the boilerplate/reference in 62 file(s).

Signed-off-by: Thomas Gleixner &lt;tglx@linutronix.de&gt;
Reviewed-by: Allison Randal &lt;allison@lohutok.net&gt;
Reviewed-by: Kate Stewart &lt;kstewart@linuxfoundation.org&gt;
Reviewed-by: Richard Fontana &lt;rfontana@redhat.com&gt;
Cc: linux-spdx@vger.kernel.org
Link: https://lkml.kernel.org/r/20190527070033.929121379@linutronix.de
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@linuxfoundation.org&gt;
</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
Based on 1 normalized pattern(s):

  licensed under the terms of the gnu gpl license version 2

extracted by the scancode license scanner the SPDX license identifier

  GPL-2.0-only

has been chosen to replace the boilerplate/reference in 62 file(s).

Signed-off-by: Thomas Gleixner &lt;tglx@linutronix.de&gt;
Reviewed-by: Allison Randal &lt;allison@lohutok.net&gt;
Reviewed-by: Kate Stewart &lt;kstewart@linuxfoundation.org&gt;
Reviewed-by: Richard Fontana &lt;rfontana@redhat.com&gt;
Cc: linux-spdx@vger.kernel.org
Link: https://lkml.kernel.org/r/20190527070033.929121379@linutronix.de
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@linuxfoundation.org&gt;
</pre>
</div>
</content>
</entry>
<entry>
<title>tools/power/cpupower: Display boost frequency separately</title>
<updated>2019-02-13T16:26:17+00:00</updated>
<author>
<name>Abhishek Goel</name>
<email>huntbag@linux.vnet.ibm.com</email>
</author>
<published>2019-02-05T10:51:28+00:00</published>
<link rel='alternate' type='text/html' href='https://git.tavy.me/linux.git/commit/?id=ae2917093fb60bdc1ed3e5757b74801420569a9a'/>
<id>ae2917093fb60bdc1ed3e5757b74801420569a9a</id>
<content type='text'>
cpufreq driver creates sysfs file "scaling_boost_frequency" for platforms
which support boost frequency. Cpupower now prints boost frequencies
separately. For few x86 vendors who already have different way to get boost
frequency, will continue to use the existing logic. Rest of the platforms
will rely on "scaling_boost_frequency" file to display boost frequency.

Signed-off-by: Abhishek Goel &lt;huntbag@linux.vnet.ibm.com&gt;
Signed-off-by: Shuah Khan &lt;shuah@kernel.org&gt;
</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
cpufreq driver creates sysfs file "scaling_boost_frequency" for platforms
which support boost frequency. Cpupower now prints boost frequencies
separately. For few x86 vendors who already have different way to get boost
frequency, will continue to use the existing logic. Rest of the platforms
will rely on "scaling_boost_frequency" file to display boost frequency.

Signed-off-by: Abhishek Goel &lt;huntbag@linux.vnet.ibm.com&gt;
Signed-off-by: Shuah Khan &lt;shuah@kernel.org&gt;
</pre>
</div>
</content>
</entry>
<entry>
<title>Merge branch 'x86-cpu-for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/tip/tip</title>
<updated>2018-10-23T15:16:40+00:00</updated>
<author>
<name>Linus Torvalds</name>
<email>torvalds@linux-foundation.org</email>
</author>
<published>2018-10-23T15:16:40+00:00</published>
<link rel='alternate' type='text/html' href='https://git.tavy.me/linux.git/commit/?id=fec98069fb72fb656304a3e52265e0c2fc9adf87'/>
<id>fec98069fb72fb656304a3e52265e0c2fc9adf87</id>
<content type='text'>
Pull x86 cpu updates from Ingo Molnar:
 "The main changes in this cycle were:

   - Add support for the "Dhyana" x86 CPUs by Hygon: these are licensed
     based on the AMD Zen architecture, and are built and sold in China,
     for domestic datacenter use. The code is pretty close to AMD
     support, mostly with a few quirks and enumeration differences. (Pu
     Wen)

   - Enable CPUID support on Cyrix 6x86/6x86L processors"

* 'x86-cpu-for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/tip/tip:
  tools/cpupower: Add Hygon Dhyana support
  cpufreq: Add Hygon Dhyana support
  ACPI: Add Hygon Dhyana support
  x86/xen: Add Hygon Dhyana support to Xen
  x86/kvm: Add Hygon Dhyana support to KVM
  x86/mce: Add Hygon Dhyana support to the MCA infrastructure
  x86/bugs: Add Hygon Dhyana to the respective mitigation machinery
  x86/apic: Add Hygon Dhyana support
  x86/pci, x86/amd_nb: Add Hygon Dhyana support to PCI and northbridge
  x86/amd_nb: Check vendor in AMD-only functions
  x86/alternative: Init ideal_nops for Hygon Dhyana
  x86/events: Add Hygon Dhyana support to PMU infrastructure
  x86/smpboot: Do not use BSP INIT delay and MWAIT to idle on Dhyana
  x86/cpu/mtrr: Support TOP_MEM2 and get MTRR number
  x86/cpu: Get cache info and setup cache cpumap for Hygon Dhyana
  x86/cpu: Create Hygon Dhyana architecture support file
  x86/CPU: Change query logic so CPUID is enabled before testing
  x86/CPU: Use correct macros for Cyrix calls
</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
Pull x86 cpu updates from Ingo Molnar:
 "The main changes in this cycle were:

   - Add support for the "Dhyana" x86 CPUs by Hygon: these are licensed
     based on the AMD Zen architecture, and are built and sold in China,
     for domestic datacenter use. The code is pretty close to AMD
     support, mostly with a few quirks and enumeration differences. (Pu
     Wen)

   - Enable CPUID support on Cyrix 6x86/6x86L processors"

* 'x86-cpu-for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/tip/tip:
  tools/cpupower: Add Hygon Dhyana support
  cpufreq: Add Hygon Dhyana support
  ACPI: Add Hygon Dhyana support
  x86/xen: Add Hygon Dhyana support to Xen
  x86/kvm: Add Hygon Dhyana support to KVM
  x86/mce: Add Hygon Dhyana support to the MCA infrastructure
  x86/bugs: Add Hygon Dhyana to the respective mitigation machinery
  x86/apic: Add Hygon Dhyana support
  x86/pci, x86/amd_nb: Add Hygon Dhyana support to PCI and northbridge
  x86/amd_nb: Check vendor in AMD-only functions
  x86/alternative: Init ideal_nops for Hygon Dhyana
  x86/events: Add Hygon Dhyana support to PMU infrastructure
  x86/smpboot: Do not use BSP INIT delay and MWAIT to idle on Dhyana
  x86/cpu/mtrr: Support TOP_MEM2 and get MTRR number
  x86/cpu: Get cache info and setup cache cpumap for Hygon Dhyana
  x86/cpu: Create Hygon Dhyana architecture support file
  x86/CPU: Change query logic so CPUID is enabled before testing
  x86/CPU: Use correct macros for Cyrix calls
</pre>
</div>
</content>
</entry>
<entry>
<title>cpupower: Fix coredump on VMWare</title>
<updated>2018-10-08T15:19:15+00:00</updated>
<author>
<name>Prarit Bhargava</name>
<email>prarit@redhat.com</email>
</author>
<published>2018-10-08T15:06:19+00:00</published>
<link rel='alternate' type='text/html' href='https://git.tavy.me/linux.git/commit/?id=f69ffc5d3db8f1f03fd6d1df5930f9a1fbd787b6'/>
<id>f69ffc5d3db8f1f03fd6d1df5930f9a1fbd787b6</id>
<content type='text'>
cpupower crashes on VMWare guests.  The guests have the AMD PStateDef MSR
(0xC0010064 + state number) set to zero.  As a result fid and did are zero
and the crash occurs because of a divide by zero (cof = fid/did).  This
can be prevented by checking the enable bit in the PStateDef MSR before
calculating cof.  By doing this the value of pstate[i] remains zero and
the value can be tested before displaying the active Pstates.

Check the enable bit in the PstateDef register for all supported families
and only print out enabled Pstates.

Signed-off-by: Prarit Bhargava &lt;prarit@redhat.com&gt;
Cc: Shuah Khan &lt;shuah@kernel.org&gt;
Cc: Stafford Horne &lt;shorne@gmail.com&gt;
Signed-off-by: Shuah Khan (Samsung OSG) &lt;shuah@kernel.org&gt;
</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
cpupower crashes on VMWare guests.  The guests have the AMD PStateDef MSR
(0xC0010064 + state number) set to zero.  As a result fid and did are zero
and the crash occurs because of a divide by zero (cof = fid/did).  This
can be prevented by checking the enable bit in the PStateDef MSR before
calculating cof.  By doing this the value of pstate[i] remains zero and
the value can be tested before displaying the active Pstates.

Check the enable bit in the PstateDef register for all supported families
and only print out enabled Pstates.

Signed-off-by: Prarit Bhargava &lt;prarit@redhat.com&gt;
Cc: Shuah Khan &lt;shuah@kernel.org&gt;
Cc: Stafford Horne &lt;shorne@gmail.com&gt;
Signed-off-by: Shuah Khan (Samsung OSG) &lt;shuah@kernel.org&gt;
</pre>
</div>
</content>
</entry>
</feed>
