linux-stable.git/arch/x86/kernel/cpu/Makefile, branch v5.2

x86: intel_epb: Do not build when CONFIG_PM is unset

2019-05-30T08:58:36+00:00

Commit 9ed0985332a6 ("x86: intel_epb: Take CONFIG_PM into account")
prevented the majority of the Performance and Energy Bias Hint (EPB)
handling code from being built when CONFIG_PM is unset to fix a
regression introduced by commit b9c273babce7 ("PM / arch: x86:
MSR_IA32_ENERGY_PERF_BIAS sysfs interface").

In hindsight, however, it would be better to skip all of the EPB
handling code for CONFIG_PM unset as there really is no reason for
it to be there in that case.  Namely, if the EPB is not touched
by the kernel at all with CONFIG_PM unset, there is no need to
worry about modifying the EPB inadvertently on CPU online and since
the system will not suspend or hibernate then, there is no need to
worry about possible modifications of the EPB by the platform
firmware during system-wide PM transitions.

For this reason, revert the changes made by commit 9ed0985332a6
and only allow intel_epb.o to be built when CONFIG_PM is set.

Note that this changes the behavior of the kernels built with
CONFIG_PM unset as they will not modify the EPB on boot if it is
zero initially any more, so it is not a fix strictly speaking, but
users building their kernels with CONFIG_PM unset really should not
expect them to take energy efficiency into account.  Moreover, if
CONFIG_PM is unset for performance reasons, leaving EPB as set
initially by the platform firmware will actually be consistent
with the user's expectations.

Signed-off-by: Rafael J. Wysocki 
Acked-by: Ingo Molnar

PM / arch: x86: Rework the MSR_IA32_ENERGY_PERF_BIAS handling

2019-04-07T20:33:19+00:00

The current handling of MSR_IA32_ENERGY_PERF_BIAS in the kernel is
problematic, because it may cause changes made by user space to that
MSR (with the help of the x86_energy_perf_policy tool, for example)
to be lost every time a CPU goes offline and then back online as well
as during system-wide power management transitions into sleep states
and back into the working state.

The first problem is that if the current EPB value for a CPU going
online is 0 ('performance'), the kernel will change it to 6 ('normal')
regardless of whether or not this is the first bring-up of that CPU.
That also happens during system-wide resume from sleep states
(including, but not limited to, hibernation).  However, the EPB may
have been adjusted by user space this way and the kernel should not
blindly override that setting.

The second problem is that if the platform firmware resets the EPB
values for any CPUs during system-wide resume from a sleep state,
the kernel will not restore their previous EPB values that may
have been set by user space before the preceding system-wide
suspend transition.  Again, that behavior may at least be confusing
from the user space perspective.

In order to address these issues, rework the handling of
MSR_IA32_ENERGY_PERF_BIAS so that the EPB value is saved on CPU
offline and restored on CPU online as well as (for the boot CPU)
during the syscore stages of system-wide suspend and resume
transitions, respectively.

However, retain the policy by which the EPB is set to 6 ('normal')
on the first bring-up of each CPU if its initial value is 0, based
on the observation that 0 may mean 'not initialized' just as well as
'performance' in that case.

While at it, move the MSR_IA32_ENERGY_PERF_BIAS handling code into
a separate file and document it in Documentation/admin-guide.

Fixes: abe48b108247 (x86, intel, power: Initialize MSR_IA32_ENERGY_PERF_BIAS)
Fixes: b51ef52df71c (x86/cpu: Restore MSR_IA32_ENERGY_PERF_BIAS after resume)
Reported-by: Thomas Renninger 
Signed-off-by: Rafael J. Wysocki 
Reviewed-by: Hannes Reinecke 
Acked-by: Borislav Petkov 
Acked-by: Thomas Gleixner

x86/resctrl: Avoid confusion over the new X86_RESCTRL config

2019-02-02T09:34:52+00:00

"Resource Control" is a very broad term for this CPU feature, and a term
that is also associated with containers, cgroups etc. This can easily
cause confusion.

Make the user prompt more specific. Match the config symbol name.

 [ bp: In the future, the corresponding ARM arch-specific code will be
   under ARM_CPU_RESCTRL and the arch-agnostic bits will be carved out
   under the CPU_RESCTRL umbrella symbol. ]

Signed-off-by: Johannes Weiner 
Signed-off-by: Borislav Petkov 
Cc: Babu Moger 
Cc: Fenghua Yu 
Cc: "H. Peter Anvin" 
Cc: Ingo Molnar 
Cc: James Morse 
Cc: Jonathan Corbet 
Cc: "Kirill A. Shutemov" 
Cc: linux-doc@vger.kernel.org
Cc: Peter Zijlstra 
Cc: Pu Wen 
Cc: Reinette Chatre 
Cc: Thomas Gleixner 
Cc: Tony Luck 
Cc: x86-ml 
Link: https://lkml.kernel.org/r/20190130195621.GA30653@cmpxchg.org

x86/cache: Rename config option to CONFIG_X86_RESCTRL

2019-01-09T09:29:03+00:00

CONFIG_RESCTRL is too generic. The final goal is to have a generic
option called like this which is selected by the arch-specific ones
CONFIG_X86_RESCTRL and CONFIG_ARM64_RESCTRL. The generic one will
cover the resctrl filesystem and other generic and shared bits of
functionality.

Signed-off-by: Borislav Petkov 
Suggested-by: Ingo Molnar 
Requested-by: Linus Torvalds 
Cc: Babu Moger 
Cc: Fenghua Yu 
Cc: James Morse 
Cc: Reinette Chatre 
Cc: Tony Luck 
Cc: x86@kernel.org
Link: http://lkml.kernel.org/r/20190108171401.GC12235@zn.tnic

Merge branch 'ras-core-for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/tip/tip

2018-12-26T21:03:47+00:00

Pull x86 RAS updates from Borislav Petkov:
 "This time around we have a subsystem reorganization to offer, with the
  new directory being

    arch/x86/kernel/cpu/mce/

  and all compilation units' names streamlined under it"

* 'ras-core-for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/tip/tip:
  x86/mce: Restore MCE injector's module name
  x86/mce: Unify pr_* prefix
  x86/mce: Streamline MCE subsystem's naming

x86/mce: Streamline MCE subsystem's naming

2018-12-05T17:00:29+00:00

Rename the containing folder to "mce" which is the most widespread name.
Drop the "mce[-_]" filename prefix of some compilation units (while
others don't have it).

This unifies the file naming in the MCE subsystem:

mce/
|-- amd.c
|-- apei.c
|-- core.c
|-- dev-mcelog.c
|-- genpool.c
|-- inject.c
|-- intel.c
|-- internal.h
|-- Makefile
|-- p5.c
|-- severity.c
|-- therm_throt.c
|-- threshold.c
`-- winchip.c

No functional changes.

Signed-off-by: Borislav Petkov 
Reviewed-by: Ingo Molnar 
Acked-by: Tony Luck 
Link: https://lkml.kernel.org/r/20181205141323.14995-1-bp@alien8.de

x86/resctrl: Rename the config option INTEL_RDT to RESCTRL

2018-11-22T19:16:19+00:00

The resource control feature is supported by both Intel and AMD. So,
rename CONFIG_INTEL_RDT to the vendor-neutral CONFIG_RESCTRL.

Now CONFIG_RESCTRL will be used for both Intel and AMD to enable
Resource Control support. Update the texts in config and condition
accordingly.

 [ bp: Simplify Kconfig text. ]

Signed-off-by: Babu Moger 
Signed-off-by: Borislav Petkov 
Cc: Andrew Morton 
Cc: Andy Lutomirski 
Cc: Arnd Bergmann 
Cc: Brijesh Singh 
Cc: "Chang S. Bae" 
Cc: David Miller 
Cc: David Woodhouse 
Cc: Dmitry Safonov 
Cc: Fenghua Yu 
Cc: Greg Kroah-Hartman 
Cc: "H. Peter Anvin" 
Cc: Ingo Molnar 
Cc: Jann Horn 
Cc: Joerg Roedel 
Cc: Jonathan Corbet 
Cc: Josh Poimboeuf 
Cc: Kate Stewart 
Cc: "Kirill A. Shutemov" 
Cc: 
Cc: Mauro Carvalho Chehab 
Cc: Paolo Bonzini 
Cc: Peter Zijlstra 
Cc: Philippe Ombredanne 
Cc: Pu Wen 
Cc: 
Cc: "Rafael J. Wysocki" 
Cc: Reinette Chatre 
Cc: Rian Hunter 
Cc: Sherry Hurwitz 
Cc: Suravee Suthikulpanit 
Cc: Thomas Gleixner 
Cc: Thomas Lendacky 
Cc: Tony Luck 
Cc: Vitaly Kuznetsov 
Cc: 
Link: https://lkml.kernel.org/r/20181121202811.4492-9-babu.moger@amd.com

x86/resctrl: Rename and move rdt files to a separate directory

2018-11-22T19:16:18+00:00

New generation of AMD processors add support for RDT (or QOS) features.
Together, these features will be called RESCTRL. With more than one
vendors supporting these features, it seems more appropriate to rename
these files.

Create a new directory with the name 'resctrl' and move all the
intel_rdt files to the new directory. This way all the resctrl related
code resides inside one directory.

 [ bp: Add SPDX identifier to the Makefile ]

Suggested-by: Borislav Petkov 
Signed-off-by: Babu Moger 
Signed-off-by: Borislav Petkov 
Cc: Andrew Morton 
Cc: Andy Lutomirski 
Cc: Arnd Bergmann 
Cc: Brijesh Singh 
Cc: "Chang S. Bae" 
Cc: David Miller 
Cc: David Woodhouse 
Cc: Dmitry Safonov 
Cc: Fenghua Yu 
Cc: Greg Kroah-Hartman 
Cc: "H. Peter Anvin" 
Cc: Ingo Molnar 
Cc: Jann Horn 
Cc: Joerg Roedel 
Cc: Jonathan Corbet 
Cc: Josh Poimboeuf 
Cc: Kate Stewart 
Cc: "Kirill A. Shutemov" 
Cc: 
Cc: Mauro Carvalho Chehab 
Cc: Paolo Bonzini 
Cc: Peter Zijlstra 
Cc: Philippe Ombredanne 
Cc: Pu Wen 
Cc: 
Cc: "Rafael J. Wysocki" 
Cc: Reinette Chatre 
Cc: Rian Hunter 
Cc: Sherry Hurwitz 
Cc: Suravee Suthikulpanit 
Cc: Thomas Gleixner 
Cc: Thomas Lendacky 
Cc: Tony Luck 
Cc: Vitaly Kuznetsov 
Cc: 
Link: https://lkml.kernel.org/r/20181121202811.4492-2-babu.moger@amd.com

x86/cpu: Create Hygon Dhyana architecture support file

2018-09-27T14:14:05+00:00

Add x86 architecture support for a new processor: Hygon Dhyana Family
18h. Carve out initialization code needed by Dhyana into a separate
compilation unit.

To identify Hygon Dhyana CPU, add a new vendor type X86_VENDOR_HYGON.

Since Dhyana uses AMD functionality to a large degree, select
CPU_SUP_AMD which provides that functionality.

 [ bp: drop explicit license statement as it has an SPDX tag already. ]

Signed-off-by: Pu Wen 
Reviewed-by: Borislav Petkov 
Signed-off-by: Borislav Petkov 
Cc: tglx@linutronix.de
Cc: mingo@redhat.com
Cc: hpa@zytor.com
Cc: x86@kernel.org
Cc: thomas.lendacky@amd.com
Link: https://lkml.kernel.org/r/1a882065223bacbde5726f3beaa70cebd8dcd814.1537533369.git.puwen@hygon.cn

x86/intel_rdt: Create debugfs files for pseudo-locking testing

2018-06-23T11:03:51+00:00

There is no simple yes/no test to determine if pseudo-locking was
successful. In order to test pseudo-locking we expose a debugfs file for
each pseudo-locked region that will record the latency of reading the
pseudo-locked memory at a stride of 32 bytes (hardcoded). These numbers
will give us an idea of locking was successful or not since they will
reflect cache hits and cache misses (hardware prefetching is disabled
during the test).

The new debugfs file "pseudo_lock_measure" will, when the
pseudo_lock_mem_latency tracepoint is enabled, record the latency of
accessing each cache line twice.

Kernel tracepoints offer us histograms (when CONFIG_HIST_TRIGGERS is
enabled) that is a simple way to visualize the memory access latency
and immediately see any cache misses. For example, the hist trigger
below before trigger of the measurement will display the memory access
latency and instances at each latency:
echo 'hist:keys=latency' > /sys/kernel/debug/tracing/events/resctrl/\
                           pseudo_lock_mem_latency/trigger
echo 1 > /sys/kernel/debug/tracing/events/resctrl/pseudo_lock_mem_latency/enable
echo 1 > /sys/kernel/debug/resctrl//pseudo_lock_measure
echo 0 > /sys/kernel/debug/tracing/events/resctrl/pseudo_lock_mem_latency/enable
cat /sys/kernel/debug/tracing/events/resctrl/pseudo_lock_mem_latency/hist

Signed-off-by: Reinette Chatre 
Signed-off-by: Thomas Gleixner 
Cc: fenghua.yu@intel.com
Cc: tony.luck@intel.com
Cc: vikas.shivappa@linux.intel.com
Cc: gavin.hindman@intel.com
Cc: jithu.joseph@intel.com
Cc: dave.hansen@intel.com
Cc: hpa@zytor.com
Link: https://lkml.kernel.org/r/6b2ea76181099d1b79ccfa7d3be24497ab2d1a45.1529706536.git.reinette.chatre@intel.com