[PATCH 3/3] powerpc/64s: cpufeatures: add initial implementation for cpufeatures

2017-04-12 Thread Nicholas Piggin
The /cpus/features dt binding describes architected CPU features along
with some compatibility, privilege, and enablement properties that allow
flexibility with discovering and enabling capabilities.

Presence of this feature implies a base level of functionality, then
additional feature nodes advertise the presence of new features.

A given feature and its setup procedure is defined once and used by all
CPUs which are compatible by that feature. Features that follow a
supported "prescription" can be enabled by a hypervisor or OS that
does not understand them natively.

One difference with features after this patch is that PPC_FEATURE2_EBB
is set independent of PMU init. EBB facility is more general than PMU,
so I think this is reasonable.

Signed-off-by: Nicholas Piggin 

---
Since last post:
- Looked at XIVE patches compatibility. There is a dependency there now
  on LPCR setup (HEIC, LPES, etc).
- Split vector-scalar feature from vector
- Get cpu_name from cputable if exists, for /proc/cpuinfo compatibility.


Testing under mambo shows a few differences with POWER8, but they all
seem to be mambo related:
- HFSCR bit 54 and 57 are now clear (mambo sets at init)
- PMAO_BUG is set. This is due to mambo setting architected POWER8 mode
  and POWER8E PVR. Current kernels lose PMAO_BUG bit.
- CI_LARGE_PAGE is now set (mambo boot does not set it for some reason,
  haven't looked at why).

Under POWER9 I haven't found differences.

 .../devicetree/bindings/powerpc/cpufeatures.txt| 264 +
 arch/powerpc/Kconfig   |  16 +
 arch/powerpc/include/asm/cpu_has_feature.h |   4 +-
 arch/powerpc/include/asm/cpufeatures.h |  57 ++
 arch/powerpc/include/asm/cputable.h|   2 +
 arch/powerpc/include/asm/reg.h |   1 +
 arch/powerpc/kernel/Makefile   |   1 +
 arch/powerpc/kernel/cpufeatures.c  | 631 +
 arch/powerpc/kernel/cputable.c |  37 +-
 arch/powerpc/kernel/prom.c | 333 ++-
 arch/powerpc/kernel/setup-common.c |   2 +-
 arch/powerpc/kernel/setup_64.c |  15 +-
 12 files changed, 1346 insertions(+), 17 deletions(-)
 create mode 100644 Documentation/devicetree/bindings/powerpc/cpufeatures.txt
 create mode 100644 arch/powerpc/include/asm/cpufeatures.h
 create mode 100644 arch/powerpc/kernel/cpufeatures.c

diff --git a/Documentation/devicetree/bindings/powerpc/cpufeatures.txt 
b/Documentation/devicetree/bindings/powerpc/cpufeatures.txt
new file mode 100644
index ..325b263f4cdf
--- /dev/null
+++ b/Documentation/devicetree/bindings/powerpc/cpufeatures.txt
@@ -0,0 +1,264 @@
+powerpc cpu features binding
+
+
+The device tree describes supported CPU features as nodes containing
+compatibility and enablement information as properties.
+
+The binding specifies features common to all CPUs in the system.
+Heterogeneous CPU features are not supported at present (such could be added
+by providing nodes with additional features and linking those to particular
+CPUs).
+
+This binding is intended to provide fine grained control of CPU features at
+all levels of the stack (firmware, hypervisor, OS, userspace), with the
+ability for new CPU features to be used by some components without all
+components being upgraded (e.g., a new floating point instruction could be
+used by userspace math library without upgrading kernel and hypervisor).
+
+The binding is passed to the hypervisor by firmware. The hypervisor must
+remove any features that require hypervisor enablement but that it does not
+enable. It must remove any features that depend on removed features. It may
+pass remaining features usable to the OS and PR to guests, depending on
+configuration policy (not specified here).
+
+The modified binding is passed to the guest by hypervisor, with HV bit
+cleared from the usable-mask and the hv-support and hfscr-bit properties
+removed. The guest must similarly rmeove features that require OS enablement
+that it does not enable. The OS may pass PR usable features to userspace via
+ELF AUX vectors AT_HWCAP, AT_HWCAP2, AT_HWCAP3, etc., or use some other
+method (outside the scope of this specification).
+
+The binding will specify a "base" level of features that will be present
+when the cpu features binding exists. Additional features will be explicitly
+specified.
+
+/cpus/features node binding
+---
+
+Node: features
+
+Description: Container of CPU feature nodes.
+
+The node name must be "features" and it must be a child of the node "/cpus".
+
+The node is optional but should be provided by new firmware.
+
+Each child node of cpufeatures represents an architected CPU feature (e.g.,
+a new set of vector instructions) or an important CPU performance
+characteristic (e.g., fast unaligned memory operations). The specification
+of each 

Re: [PATCH 3/3] powerpc/64s: cpufeatures: add initial implementation for cpufeatures

2017-04-10 Thread Nicholas Piggin
On Wed,  5 Apr 2017 22:37:06 +1000
Nicholas Piggin  wrote:

> The /cpus/features dt binding describes architected CPU features along
> with some compatibility, privilege, and enablement properties that allow
> flexibility with discovering and enabling capabilities.
> 
> Presence of this feature implies a base level of functionality, then
> additional feature nodes advertise the presence of new features.
> 
> A given feature and its setup procedure is defined once and used by all
> CPUs which are compatible by that feature. Features that follow a
> supported "prescription" can be enabled by a hypervisor or OS that
> does not understand them natively.
> 
> ---
> Since last post:
> - Update to v3.0B ISA.
> - Removed PVR tests for MCE and PMU, and add specific features for those.
> - Fixed CPU state restore.
> - Changed dt bit number specification for hfscr/fscr/aux to LSB0.
> - Broke the of/fdt changes into another patch.
> - Added a proper dependency checker.
> - Resolved most of the register/feature bits differences, made a patch
>   for VRMASD.
> - Didn't think of a better name.

Here's the latest version, which has some build and config cleanups
and updated with some more optional features.

Since last post:
- Fixed 32-bit build
- Made configurable on Book3s (for now)
- Updated base set of features


---
 .../devicetree/bindings/powerpc/cpufeatures.txt| 264 +
 arch/powerpc/Kconfig   |  16 +
 arch/powerpc/include/asm/cpu_has_feature.h |   4 +-
 arch/powerpc/include/asm/cpufeatures.h |  57 ++
 arch/powerpc/include/asm/cputable.h|   1 +
 arch/powerpc/kernel/Makefile   |   1 +
 arch/powerpc/kernel/cpufeatures.c  | 625 +
 arch/powerpc/kernel/cputable.c |  14 +-
 arch/powerpc/kernel/prom.c | 307 +-
 arch/powerpc/kernel/setup-common.c |   2 +-
 arch/powerpc/kernel/setup_64.c |  15 +-
 11 files changed, 1288 insertions(+), 18 deletions(-)
 create mode 100644 Documentation/devicetree/bindings/powerpc/cpufeatures.txt
 create mode 100644 arch/powerpc/include/asm/cpufeatures.h
 create mode 100644 arch/powerpc/kernel/cpufeatures.c

diff --git a/Documentation/devicetree/bindings/powerpc/cpufeatures.txt 
b/Documentation/devicetree/bindings/powerpc/cpufeatures.txt
new file mode 100644
index ..325b263f4cdf
--- /dev/null
+++ b/Documentation/devicetree/bindings/powerpc/cpufeatures.txt
@@ -0,0 +1,264 @@
+powerpc cpu features binding
+
+
+The device tree describes supported CPU features as nodes containing
+compatibility and enablement information as properties.
+
+The binding specifies features common to all CPUs in the system.
+Heterogeneous CPU features are not supported at present (such could be added
+by providing nodes with additional features and linking those to particular
+CPUs).
+
+This binding is intended to provide fine grained control of CPU features at
+all levels of the stack (firmware, hypervisor, OS, userspace), with the
+ability for new CPU features to be used by some components without all
+components being upgraded (e.g., a new floating point instruction could be
+used by userspace math library without upgrading kernel and hypervisor).
+
+The binding is passed to the hypervisor by firmware. The hypervisor must
+remove any features that require hypervisor enablement but that it does not
+enable. It must remove any features that depend on removed features. It may
+pass remaining features usable to the OS and PR to guests, depending on
+configuration policy (not specified here).
+
+The modified binding is passed to the guest by hypervisor, with HV bit
+cleared from the usable-mask and the hv-support and hfscr-bit properties
+removed. The guest must similarly rmeove features that require OS enablement
+that it does not enable. The OS may pass PR usable features to userspace via
+ELF AUX vectors AT_HWCAP, AT_HWCAP2, AT_HWCAP3, etc., or use some other
+method (outside the scope of this specification).
+
+The binding will specify a "base" level of features that will be present
+when the cpu features binding exists. Additional features will be explicitly
+specified.
+
+/cpus/features node binding
+---
+
+Node: features
+
+Description: Container of CPU feature nodes.
+
+The node name must be "features" and it must be a child of the node "/cpus".
+
+The node is optional but should be provided by new firmware.
+
+Each child node of cpufeatures represents an architected CPU feature (e.g.,
+a new set of vector instructions) or an important CPU performance
+characteristic (e.g., fast unaligned memory operations). The specification
+of each feature (instructions, registers, exceptions, etc.) will be
+documented with device tree bindings.
+
+As a rough guide, features should be based on functional groups of changes,
+those 

Re: [PATCH 3/3] powerpc/64s: cpufeatures: add initial implementation for cpufeatures

2017-04-06 Thread kbuild test robot
Hi Nicholas,

[auto build test ERROR on powerpc/next]
[also build test ERROR on v4.11-rc5 next-20170406]
[if your patch is applied to the wrong git tree, please drop us a note to help 
improve the system]

url:
https://github.com/0day-ci/linux/commits/Nicholas-Piggin/latest-cpufeatures-patch-series/20170406-140710
base:   https://git.kernel.org/pub/scm/linux/kernel/git/powerpc/linux.git next
config: powerpc-allnoconfig (attached as .config)
compiler: powerpc-linux-gnu-gcc (Debian 6.1.1-9) 6.1.1 20160705
reproduce:
wget 
https://raw.githubusercontent.com/01org/lkp-tests/master/sbin/make.cross -O 
~/bin/make.cross
chmod +x ~/bin/make.cross
# save the attached .config to linux build tree
make.cross ARCH=powerpc 

All errors (new ones prefixed by >>):

   arch/powerpc/kernel/prom.c: In function 'early_init_dt_scan_cpufeatures':
>> arch/powerpc/kernel/prom.c:508:2: error: 'has_cpufeatures_node' undeclared 
>> (first use in this function)
 has_cpufeatures_node = 1;
 ^~~~
   arch/powerpc/kernel/prom.c:508:2: note: each undeclared identifier is 
reported only once for each function it appears in
   arch/powerpc/kernel/prom.c: In function 'early_init_dt_scan_cpus':
   arch/powerpc/kernel/prom.c:631:7: error: 'has_cpufeatures_node' undeclared 
(first use in this function)
 if (!has_cpufeatures_node) {
  ^~~~

vim +/has_cpufeatures_node +508 arch/powerpc/kernel/prom.c

   502  printk("cpu-features node has missing property 
\"isa\"\n");
   503  return 0;
   504  }
   505  
   506  isa = be32_to_cpup(prop);
   507  
 > 508  has_cpufeatures_node = 1;
   509  
   510  /* Count and allocate space for cpu features */
   511  of_scan_flat_dt_subnodes(node, count_cpufeatures_subnodes,

---
0-DAY kernel test infrastructureOpen Source Technology Center
https://lists.01.org/pipermail/kbuild-all   Intel Corporation


.config.gz
Description: application/gzip


[PATCH 3/3] powerpc/64s: cpufeatures: add initial implementation for cpufeatures

2017-04-05 Thread Nicholas Piggin
The /cpus/features dt binding describes architected CPU features along
with some compatibility, privilege, and enablement properties that allow
flexibility with discovering and enabling capabilities.

Presence of this feature implies a base level of functionality, then
additional feature nodes advertise the presence of new features.

A given feature and its setup procedure is defined once and used by all
CPUs which are compatible by that feature. Features that follow a
supported "prescription" can be enabled by a hypervisor or OS that
does not understand them natively.

---
Since last post:
- Update to v3.0B ISA.
- Removed PVR tests for MCE and PMU, and add specific features for those.
- Fixed CPU state restore.
- Changed dt bit number specification for hfscr/fscr/aux to LSB0.
- Broke the of/fdt changes into another patch.
- Added a proper dependency checker.
- Resolved most of the register/feature bits differences, made a patch
  for VRMASD.
- Didn't think of a better name.

Before/after this patch differences:

- PPC_FEATURE2_EBB is set independent of PMU init. EBB facility is
  theoretically more general than PMU, I don't think this should be
  a problem?

POWER8 (all mambo issues):
- HFSCR bit 54 and 57 are now clear (mambo sets at init)
- PMAO_BUG is set. This is due to mambo setting architected POWER8 mode
  and POWER8E PVR. Current kernels lose PMAO_BUG bit.
- CI_LARGE_PAGE is now set (mambo boot does not set).

POWER9
- Privileged Doorbell Exit Enable is set in LPCR.

---
 .../devicetree/bindings/powerpc/cpufeatures.txt| 264 +
 arch/powerpc/include/asm/cpu_has_feature.h |   4 +-
 arch/powerpc/include/asm/cpufeatures.h |  58 ++
 arch/powerpc/include/asm/cputable.h|   1 +
 arch/powerpc/kernel/Makefile   |   1 +
 arch/powerpc/kernel/cpufeatures.c  | 618 +
 arch/powerpc/kernel/cputable.c |  14 +-
 arch/powerpc/kernel/prom.c | 297 +-
 arch/powerpc/kernel/setup-common.c |   2 +-
 arch/powerpc/kernel/setup_64.c |  21 +-
 10 files changed, 1261 insertions(+), 19 deletions(-)
 create mode 100644 Documentation/devicetree/bindings/powerpc/cpufeatures.txt
 create mode 100644 arch/powerpc/include/asm/cpufeatures.h
 create mode 100644 arch/powerpc/kernel/cpufeatures.c

diff --git a/Documentation/devicetree/bindings/powerpc/cpufeatures.txt 
b/Documentation/devicetree/bindings/powerpc/cpufeatures.txt
new file mode 100644
index ..325b263f4cdf
--- /dev/null
+++ b/Documentation/devicetree/bindings/powerpc/cpufeatures.txt
@@ -0,0 +1,264 @@
+powerpc cpu features binding
+
+
+The device tree describes supported CPU features as nodes containing
+compatibility and enablement information as properties.
+
+The binding specifies features common to all CPUs in the system.
+Heterogeneous CPU features are not supported at present (such could be added
+by providing nodes with additional features and linking those to particular
+CPUs).
+
+This binding is intended to provide fine grained control of CPU features at
+all levels of the stack (firmware, hypervisor, OS, userspace), with the
+ability for new CPU features to be used by some components without all
+components being upgraded (e.g., a new floating point instruction could be
+used by userspace math library without upgrading kernel and hypervisor).
+
+The binding is passed to the hypervisor by firmware. The hypervisor must
+remove any features that require hypervisor enablement but that it does not
+enable. It must remove any features that depend on removed features. It may
+pass remaining features usable to the OS and PR to guests, depending on
+configuration policy (not specified here).
+
+The modified binding is passed to the guest by hypervisor, with HV bit
+cleared from the usable-mask and the hv-support and hfscr-bit properties
+removed. The guest must similarly rmeove features that require OS enablement
+that it does not enable. The OS may pass PR usable features to userspace via
+ELF AUX vectors AT_HWCAP, AT_HWCAP2, AT_HWCAP3, etc., or use some other
+method (outside the scope of this specification).
+
+The binding will specify a "base" level of features that will be present
+when the cpu features binding exists. Additional features will be explicitly
+specified.
+
+/cpus/features node binding
+---
+
+Node: features
+
+Description: Container of CPU feature nodes.
+
+The node name must be "features" and it must be a child of the node "/cpus".
+
+The node is optional but should be provided by new firmware.
+
+Each child node of cpufeatures represents an architected CPU feature (e.g.,
+a new set of vector instructions) or an important CPU performance
+characteristic (e.g., fast unaligned memory operations). The specification
+of each feature (instructions, registers, exceptions, etc.) will be
+documented with device