1. 14 10月, 2018 34 次提交
  2. 13 10月, 2018 6 次提交
    • C
      powerpc/32: Add ioremap_wt() and ioremap_coherent() · 86c391bd
      Christophe Leroy 提交于
      Other arches have ioremap_wt() to map IO areas write-through.
      Implement it on PPC as well in order to avoid drivers using
      __ioremap(_PAGE_WRITETHRU)
      
      Also implement ioremap_coherent() to avoid drivers using
      __ioremap(_PAGE_COHERENT)
      Signed-off-by: NChristophe Leroy <christophe.leroy@c-s.fr>
      Signed-off-by: NMichael Ellerman <mpe@ellerman.id.au>
      86c391bd
    • G
      powerpc/rtas: Fix a potential race between CPU-Offline & Migration · dfd718a2
      Gautham R. Shenoy 提交于
      Live Partition Migrations require all the present CPUs to execute the
      H_JOIN call, and hence rtas_ibm_suspend_me() onlines any offline CPUs
      before initiating the migration for this purpose.
      
      The commit 85a88cab
      ("powerpc/pseries: Disable CPU hotplug across migrations")
      disables any CPU-hotplug operations once all the offline CPUs are
      brought online to prevent any further state change. Once the
      CPU-Hotplug operation is disabled, the code assumes that all the CPUs
      are online.
      
      However, there is a minor window in rtas_ibm_suspend_me() between
      onlining the offline CPUs and disabling CPU-Hotplug when a concurrent
      CPU-offline operations initiated by the userspace can succeed thereby
      nullifying the the aformentioned assumption. In this unlikely case
      these offlined CPUs will not call H_JOIN, resulting in a system hang.
      
      Fix this by verifying that all the present CPUs are actually online
      after CPU-Hotplug has been disabled, failing which we restore the
      state of the offline CPUs in rtas_ibm_suspend_me() and return an
      -EBUSY.
      
      Cc: Nathan Fontenot <nfont@linux.vnet.ibm.com>
      Cc: Tyrel Datwyler <tyreld@linux.vnet.ibm.com>
      Suggested-by: NMichael Ellerman <mpe@ellerman.id.au>
      Signed-off-by: NGautham R. Shenoy <ego@linux.vnet.ibm.com>
      Reviewed-by: NNathan Fontenot <nfont@linux.vnet.ibm.com>
      Signed-off-by: NMichael Ellerman <mpe@ellerman.id.au>
      dfd718a2
    • G
      powerpc/cacheinfo: Report the correct shared_cpu_map on big-cores · 500fe5f5
      Gautham R. Shenoy 提交于
      Currently on POWER9 SMT8 cores systems, in sysfs, we report the
      shared_cache_map for L1 caches (both data and instruction) to be the
      cpu-ids of the threads in SMT8 cores. This is incorrect since on
      POWER9 SMT8 cores there are two groups of threads, each of which
      shares its own L1 cache.
      
      This patch addresses this by reporting the shared_cpu_map correctly in
      sysfs for L1 caches.
      
      Before the patch
         /sys/devices/system/cpu/cpu0/cache/index0/shared_cpu_map : 000000ff
         /sys/devices/system/cpu/cpu0/cache/index1/shared_cpu_map : 000000ff
         /sys/devices/system/cpu/cpu1/cache/index0/shared_cpu_map : 000000ff
         /sys/devices/system/cpu/cpu1/cache/index1/shared_cpu_map : 000000ff
      
      After the patch
         /sys/devices/system/cpu/cpu0/cache/index0/shared_cpu_map : 00000055
         /sys/devices/system/cpu/cpu0/cache/index1/shared_cpu_map : 00000055
         /sys/devices/system/cpu/cpu1/cache/index0/shared_cpu_map : 000000aa
         /sys/devices/system/cpu/cpu1/cache/index1/shared_cpu_map : 000000aa
      Signed-off-by: NGautham R. Shenoy <ego@linux.vnet.ibm.com>
      Signed-off-by: NMichael Ellerman <mpe@ellerman.id.au>
      500fe5f5
    • G
      powerpc: Use cpu_smallcore_sibling_mask at SMT level on bigcores · 8e8a31d7
      Gautham R. Shenoy 提交于
      POWER9 SMT8 cores consist of two groups of threads, where threads in
      each group shares L1-cache. The scheduler is not aware of this
      distinction as the current sched-domain hierarchy has all the threads
      of the core defined at the SMT domain.
      
      	SMT  [Thread siblings of the SMT8 core]
      	DIE  [CPUs in the same die]
      	NUMA [All the CPUs in the system]
      
      Due to this, we can observe run-to-run variance when we run a
      multi-threaded benchmark bound to a single core based on how the
      scheduler spreads the software threads across the two groups in the
      core.
      
      We fix this in this patch by defining each group of threads which
      share L1-cache to be the SMT level. The group of threads in the SMT8
      core is defined to be the CACHE level. The sched-domain hierarchy
      after this patch will be :
      
      	SMT	[Thread siblings in the core that share L1 cache]
      	CACHE 	[Thread siblings that are in the SMT8 core]
      	DIE  	[CPUs in the same die]
      	NUMA 	[All the CPUs in the system]
      Signed-off-by: NGautham R. Shenoy <ego@linux.vnet.ibm.com>
      Signed-off-by: NMichael Ellerman <mpe@ellerman.id.au>
      8e8a31d7
    • G
      powerpc: Detect the presence of big-cores via "ibm, thread-groups" · 425752c6
      Gautham R. Shenoy 提交于
      On IBM POWER9, the device tree exposes a property array identifed by
      "ibm,thread-groups" which will indicate which groups of threads share
      a particular set of resources.
      
      As of today we only have one form of grouping identifying the group of
      threads in the core that share the L1 cache, translation cache and
      instruction data flow.
      
      This patch adds helper functions to parse the contents of
      "ibm,thread-groups" and populate a per-cpu variable to cache
      information about siblings of each CPU that share the L1, traslation
      cache and instruction data-flow.
      
      It also defines a new global variable named "has_big_cores" which
      indicates if the cores on this configuration have multiple groups of
      threads that share L1 cache.
      
      For each online CPU, it maintains a cpu_smallcore_mask, which
      indicates the online siblings which share the L1-cache with it.
      Signed-off-by: NGautham R. Shenoy <ego@linux.vnet.ibm.com>
      Signed-off-by: NMichael Ellerman <mpe@ellerman.id.au>
      425752c6
    • M
      powerpc: Fix stackprotector detection for non-glibc toolchains · bf6cbd0c
      Michael Ellerman 提交于
      If GCC is not built with glibc support then we must explicitly tell it
      which register to use for TLS mode stack protector, otherwise it will
      error out and the cc-option check will fail.
      Signed-off-by: NMichael Ellerman <mpe@ellerman.id.au>
      bf6cbd0c