1. 28 Aug, 2020 4 commits
  2. 21 Aug, 2020 9 commits
  3. 20 Aug, 2020 9 commits
  4. 19 Aug, 2020 1 commit
    • Arvind Sankar's avatar
      x86/boot/compressed: Use builtin mem functions for decompressor · 394b19d6
      Arvind Sankar authored
      Since commits
      
        c041b5ad ("x86, boot: Create a separate string.h file to provide standard string functions")
        fb4cac57
      
       ("x86, boot: Move memcmp() into string.h and string.c")
      
      the decompressor stub has been using the compiler's builtin memcpy,
      memset and memcmp functions, _except_ where it would likely have the
      largest impact, in the decompression code itself.
      
      Remove the #undef's of memcpy and memset in misc.c so that the
      decompressor code also uses the compiler builtins.
      
      The rationale given in the comment doesn't really apply: just because
      some functions use the out-of-line version is no reason to not use the
      builtin version in the rest.
      
      Replace the comment with an explanation of why memzero and memmove are
      being #define'd.
      
      Drop the suggestion to #undef in boot/string.h as well: the out-of-line
      versions are not really optimized versions, they're generic code that's
      good enough for the preboot environment. The compiler will likely
      generate better code for constant-size memcpy/memset/memcmp if it is
      allowed to.
      
      Most decompressors' performance is unchanged, with the exception of LZ4
      and 64-bit ZSTD.
      
      	Before	After ARCH
      LZ4	  73ms	 10ms   32
      LZ4	 120ms	 10ms	64
      ZSTD	  90ms	 74ms	64
      
      Measurements on QEMU on 2.2GHz Broadwell Xeon, using defconfig kernels.
      
      Decompressor code size has small differences, with the largest being
      that 64-bit ZSTD decreases just over 2k. The largest code size increase
      was on 64-bit XZ, of about 400 bytes.
      Signed-off-by: default avatarArvind Sankar <nivedita@alum.mit.edu>
      Suggested-by: default avatarNick Terrell <nickrterrell@gmail.com>
      Tested-by: default avatarNick Terrell <nickrterrell@gmail.com>
      Acked-by: default avatarKees Cook <keescook@chromium.org>
      Signed-off-by: default avatarLinus Torvalds <torvalds@linux-foundation.org>
      394b19d6
  5. 18 Aug, 2020 3 commits
    • Michael Roth's avatar
      powerpc/pseries/hotplug-cpu: wait indefinitely for vCPU death · 801980f6
      Michael Roth authored
      For a power9 KVM guest with XIVE enabled, running a test loop
      where we hotplug 384 vcpus and then unplug them, the following traces
      can be seen (generally within a few loops) either from the unplugged
      vcpu:
      
        cpu 65 (hwid 65) Ready to die...
        Querying DEAD? cpu 66 (66) shows 2
        list_del corruption. next->prev should be c00a000002470208, but was c00a000002470048
        ------------[ cut here ]------------
        kernel BUG at lib/list_debug.c:56!
        Oops: Exception in kernel mode, sig: 5 [#1]
        LE SMP NR_CPUS=2048 NUMA pSeries
        Modules linked in: fuse nft_fib_inet nft_fib_ipv4 nft_fib_ipv6 ...
        CPU: 66 PID: 0 Comm: swapper/66 Kdump: loaded Not tainted 4.18.0-221.el8.ppc64le #1
        NIP:  c0000000007ab50c LR: c0000000007ab508 CTR: 00000000000003ac
        REGS: c0000009e5a17840 TRAP: 0700   Not tainted  (4.18.0-221.el8.ppc64le)
        MSR:  800000000282b033 <SF,VEC,VSX,EE,FP,ME,IR,DR,RI,LE>  CR: 28000842  XER: 20040000
        ...
        NIP __list_del_entry_valid+0xac/0x100
        LR  __list_del_entry_valid+0xa8/0x100
        Call Trace:
          __list_del_entry_valid+0xa8/0x100 (unreliable)
          free_pcppages_bulk+0x1f8/0x940
          free_unref_page+0xd0/0x100
          xive_spapr_cleanup_queue+0x148/0x1b0
          xive_teardown_cpu+0x1bc/0x240
          pseries_mach_cpu_die+0x78/0x2f0
          cpu_die+0x48/0x70
          arch_cpu_idle_dead+0x20/0x40
          do_idle+0x2f4/0x4c0
          cpu_startup_entry+0x38/0x40
          start_secondary+0x7bc/0x8f0
          start_secondary_prolog+0x10/0x14
      
      or on the worker thread handling the unplug:
      
        pseries-hotplug-cpu: Attempting to remove CPU <NULL>, drc index: 1000013a
        Querying DEAD? cpu 314 (314) shows 2
        BUG: Bad page state in process kworker/u768:3  pfn:95de1
        cpu 314 (hwid 314) Ready to die...
        page:c00a000002577840 refcount:0 mapcount:-128 mapping:0000000000000000 index:0x0
        flags: 0x5ffffc00000000()
        raw: 005ffffc00000000 5deadbeef0000100 5deadbeef0000200 0000000000000000
        raw: 0000000000000000 0000000000000000 00000000ffffff7f 0000000000000000
        page dumped because: nonzero mapcount
        Modules linked in: kvm xt_CHECKSUM ipt_MASQUERADE xt_conntrack ...
        CPU: 0 PID: 548 Comm: kworker/u768:3 Kdump: loaded Not tainted 4.18.0-224.el8.bz1856588.ppc64le #1
        Workqueue: pseries hotplug workque pseries_hp_work_fn
        Call Trace:
          dump_stack+0xb0/0xf4 (unreliable)
          bad_page+0x12c/0x1b0
          free_pcppages_bulk+0x5bc/0x940
          page_alloc_cpu_dead+0x118/0x120
          cpuhp_invoke_callback.constprop.5+0xb8/0x760
          _cpu_down+0x188/0x340
          cpu_down+0x5c/0xa0
          cpu_subsys_offline+0x24/0x40
          device_offline+0xf0/0x130
          dlpar_offline_cpu+0x1c4/0x2a0
          dlpar_cpu_remove+0xb8/0x190
          dlpar_cpu_remove_by_index+0x12c/0x150
          dlpar_cpu+0x94/0x800
          pseries_hp_work_fn+0x128/0x1e0
          process_one_work+0x304/0x5d0
          worker_thread+0xcc/0x7a0
          kthread+0x1ac/0x1c0
          ret_from_kernel_thread+0x5c/0x80
      
      The latter trace is due to the following sequence:
      
        page_alloc_cpu_dead
          drain_pages
            drain_pages_zone
              free_pcppages_bulk
      
      where drain_pages() in this case is called under the assumption that
      the unplugged cpu is no longer executing. To ensure that is the case,
      and early call is made to __cpu_die()->pseries_cpu_die(), which runs a
      loop that waits for the cpu to reach a halted state by polling its
      status via query-cpu-stopped-state RTAS calls. It only polls for 25
      iterations before giving up, however, and in the trace above this
      results in the following being printed only .1 seconds after the
      hotplug worker thread begins processing the unplug request:
      
        pseries-hotplug-cpu: Attempting to remove CPU <NULL>, drc index: 1000013a
        Querying DEAD? cpu 314 (314) shows 2
      
      At that point the worker thread assumes the unplugged CPU is in some
      unknown/dead state and procedes with the cleanup, causing the race
      with the XIVE cleanup code executed by the unplugged CPU.
      
      Fix this by waiting indefinitely, but also making an effort to avoid
      spurious lockup messages by allowing for rescheduling after polling
      the CPU status and printing a warning if we wait for longer than 120s.
      
      Fixes: eac1e731
      
       ("powerpc/xive: guest exploitation of the XIVE interrupt controller")
      Suggested-by: default avatarMichael Ellerman <mpe@ellerman.id.au>
      Signed-off-by: default avatarMichael Roth <mdroth@linux.vnet.ibm.com>
      Tested-by: default avatarGreg Kurz <groug@kaod.org>
      Reviewed-by: default avatarThiago Jung Bauermann <bauerman@linux.ibm.com>
      Reviewed-by: default avatarGreg Kurz <groug@kaod.org>
      [mpe: Trim oopses in change log slightly for readability]
      Signed-off-by: default avatarMichael Ellerman <mpe@ellerman.id.au>
      Link: https://lore.kernel.org/r/20200811161544.10513-1-mdroth@linux.vnet.ibm.com
      801980f6
    • Christophe Leroy's avatar
      powerpc/32s: Fix is_module_segment() when MODULES_VADDR is defined · 7bee31ad
      Christophe Leroy authored
      When MODULES_VADDR is defined, is_module_segment() shall check the
      address against it instead of checking agains VMALLOC_START.
      
      Fixes: 6ca05532
      
       ("powerpc/32s: Use dedicated segment for modules with STRICT_KERNEL_RWX")
      Signed-off-by: default avatarChristophe Leroy <christophe.leroy@csgroup.eu>
      Signed-off-by: default avatarMichael Ellerman <mpe@ellerman.id.au>
      Link: https://lore.kernel.org/r/07884ed033c31e074747b7eb8eaa329d15db07ec.1596641219.git.christophe.leroy@csgroup.eu
      7bee31ad
    • Christophe Leroy's avatar
      powerpc/kasan: Fix KASAN_SHADOW_START on BOOK3S_32 · 48d2f040
      Christophe Leroy authored
      On BOOK3S_32, when we have modules and strict kernel RWX, modules
      are not in vmalloc space but in a dedicated segment that is
      below PAGE_OFFSET.
      
      So KASAN_SHADOW_START must take it into account.
      
      MODULES_VADDR can't be used because it is not defined yet
      in kasan.h
      
      Fixes: 6ca05532
      
       ("powerpc/32s: Use dedicated segment for modules with STRICT_KERNEL_RWX")
      Signed-off-by: default avatarChristophe Leroy <christophe.leroy@csgroup.eu>
      Signed-off-by: default avatarMichael Ellerman <mpe@ellerman.id.au>
      Link: https://lore.kernel.org/r/6eddca2d5611fd57312a88eae31278c87a8fc99d.1596641224.git.christophe.leroy@csgroup.eu
      48d2f040
  6. 17 Aug, 2020 14 commits
    • Jim Mattson's avatar
      kvm: x86: Toggling CR4.PKE does not load PDPTEs in PAE mode · cb957adb
      Jim Mattson authored
      See the SDM, volume 3, section 4.4.1:
      
      If PAE paging would be in use following an execution of MOV to CR0 or
      MOV to CR4 (see Section 4.1.1) and the instruction is modifying any of
      CR0.CD, CR0.NW, CR0.PG, CR4.PAE, CR4.PGE, CR4.PSE, or CR4.SMEP; then
      the PDPTEs are loaded from the address in CR3.
      
      Fixes: b9baba86
      
       ("KVM, pkeys: expose CPUID/CR4 to guest")
      Cc: Huaitong Han <huaitong.han@intel.com>
      Signed-off-by: default avatarJim Mattson <jmattson@google.com>
      Reviewed-by: default avatarPeter Shier <pshier@google.com>
      Reviewed-by: default avatarOliver Upton <oupton@google.com>
      Message-Id: <20200817181655.3716509-1-jmattson@google.com>
      Signed-off-by: default avatarPaolo Bonzini <pbonzini@redhat.com>
      cb957adb
    • Jim Mattson's avatar
      kvm: x86: Toggling CR4.SMAP does not load PDPTEs in PAE mode · 427890af
      Jim Mattson authored
      See the SDM, volume 3, section 4.4.1:
      
      If PAE paging would be in use following an execution of MOV to CR0 or
      MOV to CR4 (see Section 4.1.1) and the instruction is modifying any of
      CR0.CD, CR0.NW, CR0.PG, CR4.PAE, CR4.PGE, CR4.PSE, or CR4.SMEP; then
      the PDPTEs are loaded from the address in CR3.
      
      Fixes: 0be0226f
      
       ("KVM: MMU: fix SMAP virtualization")
      Cc: Xiao Guangrong <guangrong.xiao@linux.intel.com>
      Signed-off-by: default avatarJim Mattson <jmattson@google.com>
      Reviewed-by: default avatarPeter Shier <pshier@google.com>
      Reviewed-by: default avatarOliver Upton <oupton@google.com>
      Message-Id: <20200817181655.3716509-2-jmattson@google.com>
      Signed-off-by: default avatarPaolo Bonzini <pbonzini@redhat.com>
      427890af
    • Paolo Bonzini's avatar
      KVM: x86: fix access code passed to gva_to_gpa · 19cf4b7e
      Paolo Bonzini authored
      
      
      The PK bit of the error code is computed dynamically in permission_fault
      and therefore need not be passed to gva_to_gpa: only the access bits
      (fetch, user, write) need to be passed down.
      
      Not doing so causes a splat in the pku test:
      
         WARNING: CPU: 25 PID: 5465 at arch/x86/kvm/mmu.h:197 paging64_walk_addr_generic+0x594/0x750 [kvm]
         Hardware name: Intel Corporation WilsonCity/WilsonCity, BIOS WLYDCRB1.SYS.0014.D62.2001092233 01/09/2020
         RIP: 0010:paging64_walk_addr_generic+0x594/0x750 [kvm]
         Code: <0f> 0b e9 db fe ff ff 44 8b 43 04 4c 89 6c 24 30 8b 13 41 39 d0 89
         RSP: 0018:ff53778fc623fb60 EFLAGS: 00010202
         RAX: 0000000000000001 RBX: ff53778fc623fbf0 RCX: 0000000000000007
         RDX: 0000000000000001 RSI: 0000000000000002 RDI: ff4501efba818000
         RBP: 0000000000000020 R08: 0000000000000005 R09: 00000000004000e7
         R10: 0000000000000001 R11: 0000000000000000 R12: 0000000000000007
         R13: ff4501efba818388 R14: 10000000004000e7 R15: 0000000000000000
         FS:  00007f2dcf31a700(0000) GS:ff4501f1c8040000(0000) knlGS:0000000000000000
         CS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033
         CR2: 0000000000000000 CR3: 0000001dea475005 CR4: 0000000000763ee0
         DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000
         DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400
         PKRU: 55555554
         Call Trace:
          paging64_gva_to_gpa+0x3f/0xb0 [kvm]
          kvm_fixup_and_inject_pf_error+0x48/0xa0 [kvm]
          handle_exception_nmi+0x4fc/0x5b0 [kvm_intel]
          kvm_arch_vcpu_ioctl_run+0x911/0x1c10 [kvm]
          kvm_vcpu_ioctl+0x23e/0x5d0 [kvm]
          ksys_ioctl+0x92/0xb0
          __x64_sys_ioctl+0x16/0x20
          do_syscall_64+0x3e/0xb0
          entry_SYSCALL_64_after_hwframe+0x44/0xa9
         ---[ end trace d17eb998aee991da ]---
      Reported-by: default avatarSean Christopherson <sean.j.christopherson@intel.com>
      Fixes: 89786147
      
       ("KVM: x86: Add helper functions for illegal GPA checking and page fault injection")
      Signed-off-by: default avatarPaolo Bonzini <pbonzini@redhat.com>
      19cf4b7e
    • Jessica Clarke's avatar
      arch/ia64: Restore arch-specific pgd_offset_k implementation · bd05220c
      Jessica Clarke authored
      IA-64 is special and treats pgd_offset_k() differently to pgd_offset(),
      using different formulae to calculate the indices into the kernel and user
      PGDs.  The index into the user PGDs takes into account the region number,
      but the index into the kernel (init_mm) PGD always assumes a predefined
      kernel region number. Commit 974b9b2c ("mm: consolidate pte_index() and
      pte_offset_*() definitions") made IA-64 use a generic pgd_offset_k() which
      incorrectly used pgd_index() for kernel page tables.  As a result, the
      index into the kernel PGD was going out of bounds and the kernel hung
      during early boot.
      
      Allow overrides of pgd_offset_k() and override it on IA-64 with the old
      implementation that will correctly index the kernel PGD.
      
      Fixes: 974b9b2c
      
       ("mm: consolidate pte_index() and pte_offset_*() definitions")
      Reported-by: default avatarJohn Paul Adrian Glaubitz <glaubitz@physik.fu-berlin.de>
      Signed-off-by: default avatarJessica Clarke <jrtc27@jrtc27.com>
      Tested-by: default avatarJohn Paul Adrian Glaubitz <glaubitz@physik.fu-berlin.de>
      Acked-by: default avatarTony Luck <tony.luck@intel.com>
      Signed-off-by: default avatarMike Rapoport <rppt@linux.ibm.com>
      bd05220c
    • Christophe Leroy's avatar
      powerpc/fixmap: Fix the size of the early debug area · fdc6edbb
      Christophe Leroy authored
      Commit ("03fd42d4 powerpc/fixmap: Fix FIX_EARLY_DEBUG_BASE when
      page size is 256k") reworked the setup of the early debug area and
      mistakenly replaced 128 * 1024 by SZ_128.
      
      Change to SZ_128K to restore the original 128 kbytes size of the area.
      
      Fixes: 03fd42d4
      
       ("powerpc/fixmap: Fix FIX_EARLY_DEBUG_BASE when page size is 256k")
      Signed-off-by: default avatarChristophe Leroy <christophe.leroy@csgroup.eu>
      Signed-off-by: default avatarMichael Ellerman <mpe@ellerman.id.au>
      Link: https://lore.kernel.org/r/996184974d674ff984643778cf1cdd7fe58cc065.1597644194.git.christophe.leroy@csgroup.eu
      fdc6edbb
    • Aneesh Kumar K.V's avatar
      powerpc/pkeys: Fix build error with PPC_MEM_KEYS disabled · 1e4e4bca
      Aneesh Kumar K.V authored
      IS_ENABLED() instead of #ifdef still requires variable declaration.
      In this specific case, default_uamor is declared in asm/pkeys.h which
      is only included if PPC_MEM_KEYS is enabled.
      
      arch/powerpc/mm/book3s64/hash_utils.c: In function ‘hash__early_init_mmu_secondary’:
      arch/powerpc/mm/book3s64/hash_utils.c:1119:21: error: ‘default_uamor’ undeclared (first use in this function)
       1119 |   mtspr(SPRN_UAMOR, default_uamor);
            |                     ^~~~~~~~~~~~~
      
      Fixes: 6553fb79
      
       ("powerpc/pkeys: Fix boot failures with Nemo board (A-EON AmigaOne X1000)")
      Signed-off-by: default avatarAneesh Kumar K.V <aneesh.kumar@linux.ibm.com>
      Signed-off-by: default avatarMichael Ellerman <mpe@ellerman.id.au>
      Link: https://lore.kernel.org/r/20200817103301.158836-1-aneesh.kumar@linux.ibm.com
      1e4e4bca
    • Niklas Schnelle's avatar
      s390/pci: fix PF/VF linking on hot plug · b97bf44f
      Niklas Schnelle authored
      Currently there are four places in which a PCI function is scanned
      and made available to drivers:
       1. In pci_scan_root_bus() as part of the initial zbus
          creation.
       2. In zpci_bus_add_devices() when registering
          a device in configured state on a zbus that has already been
          scanned.
       3. When a function is already known to zPCI (in reserved/standby state)
          and configuration is triggered through firmware by PEC 0x301.
       4. When a device is already known to zPCI (in standby/reserved state)
          and configuration is triggered from within Linux using
          enable_slot().
      
      The PF/VF linking step and setting of pdev->is_virtfn introduced with
      commit e5794cf1 ("s390/pci: create links between PFs and VFs") was
      only triggered for the second case, which is where VFs created through
      sriov_numvfs usually land. However unlike some other platforms but like
      POWER VFs can be individually enabled/disabled through
      /sys/bus/pci/slots.
      
      Fix this by doing VF setup as part of pcibios_bus_add_device() which is
      called in all of the above cases.
      
      Finally to remove the PF/VF links call the common code
      pci_iov_remove_virtfn() function to remove linked VFs.
      This takes care of the necessary sysfs cleanup.
      
      Fixes: e5794cf1 ("s390/pci: create links between PFs and VFs")
      Cc: <stable@vger.kernel.org> # 5.8: 2f0230b2
      
      : s390/pci: re-introduce zpci_remove_device()
      Cc: <stable@vger.kernel.org> # 5.8
      Acked-by: default avatarPierre Morel <pmorel@linux.ibm.com>
      Signed-off-by: default avatarNiklas Schnelle <schnelle@linux.ibm.com>
      Signed-off-by: default avatarHeiko Carstens <hca@linux.ibm.com>
      b97bf44f
    • Niklas Schnelle's avatar
      s390/pci: re-introduce zpci_remove_device() · 2f0230b2
      Niklas Schnelle authored
      
      
      For fixing the PF to VF link removal we need to perform some action on
      every removal of a zdev from the common PCI subsystem.
      So in preparation re-introduce zpci_remove_device() and use that instead
      of directly calling the common code functions. This  was actually still
      declared from earlier code but no longer implemented.
      Reviewed-by: default avatarPierre Morel <pmorel@linux.ibm.com>
      Signed-off-by: default avatarNiklas Schnelle <schnelle@linux.ibm.com>
      Signed-off-by: default avatarHeiko Carstens <hca@linux.ibm.com>
      2f0230b2
    • Niklas Schnelle's avatar
      s390/pci: fix zpci_bus_link_virtfn() · 3cddb79a
      Niklas Schnelle authored
      We were missing the pci_dev_put() for candidate PFs.  Furhtermore in
      discussion with upstream it turns out that somewhat counterintuitively
      some common code, in particular the vfio-pci driver, assumes that
      pdev->is_virtfn always implies that pdev->physfn is set, i.e. that VFs
      are always linked.
      While POWER does seem to set pdev->is_virtfn even for unlinked functions
      (see comments in arch/powerpc/kernel/eeh.c:eeh_debugfs_break_device())
      for now just be safe and only set pdev->is_virtfn on linking.
      Also make sure that we only search for parent PFs if the zbus is
      multifunction and we thus know the devfn values supplied by firmware
      come from the RID.
      
      Fixes: e5794cf1
      
       ("s390/pci: create links between PFs and VFs")
      Cc: <stable@vger.kernel.org> # 5.8
      Reviewed-by: default avatarPierre Morel <pmorel@linux.ibm.com>
      Signed-off-by: default avatarNiklas Schnelle <schnelle@linux.ibm.com>
      Signed-off-by: default avatarHeiko Carstens <hca@linux.ibm.com>
      3cddb79a
    • Heiko Carstens's avatar
      s390/ptrace: fix storage key handling · fd78c594
      Heiko Carstens authored
      The key member of the runtime instrumentation control block contains
      only the access key, not the complete storage key. Therefore the value
      must be shifted by four bits. Since existing user space does not
      necessarily query and set the access key correctly, just ignore the
      user space provided key and use the correct one.
      Note: this is only relevant for debugging purposes in case somebody
      compiles a kernel with a default storage access key set to a value not
      equal to zero.
      
      Fixes: 262832bc
      
       ("s390/ptrace: add runtime instrumention register get/set")
      Reported-by: default avatarClaudio Imbrenda <imbrenda@linux.ibm.com>
      Signed-off-by: default avatarHeiko Carstens <hca@linux.ibm.com>
      fd78c594
    • Heiko Carstens's avatar
      s390/runtime_instrumentation: fix storage key handling · 9eaba29c
      Heiko Carstens authored
      The key member of the runtime instrumentation control block contains
      only the access key, not the complete storage key. Therefore the value
      must be shifted by four bits.
      Note: this is only relevant for debugging purposes in case somebody
      compiles a kernel with a default storage access key set to a value not
      equal to zero.
      
      Fixes: e4b8b3f3
      
       ("s390: add support for runtime instrumentation")
      Reported-by: default avatarClaudio Imbrenda <imbrenda@linux.ibm.com>
      Signed-off-by: default avatarHeiko Carstens <hca@linux.ibm.com>
      9eaba29c
    • Niklas Schnelle's avatar
      s390/pci: ignore stale configuration request event · b76fee1b
      Niklas Schnelle authored
      A configuration request event may be stale, that is the event
      may reference a zdev which was already configured.
      This can happen when a hotplug happens during boot such that
      the device is discovered and configured in the initial clp_list_pci(),
      then after initialization we enable events and process
      the original configuration request which additionally still contains
      the old disabled function handle leading to a failure during device
      enablement and subsequent I/O lockout.
      
      Fix this by restoring the check that the device to be configured is in
      standby which was removed in commit f606b3ef ("s390/pci: adapt events
      for zbus").
      
      This check does not need serialization as we only enable the events after
      zPCI has fully initialized, which includes the initial clp_list_pci(),
      rescan only does updates and events are serialized with respect to each
      other.
      
      Fixes: f606b3ef
      
       ("s390/pci: adapt events for zbus")
      Cc: <stable@vger.kernel.org> # 5.8
      Reported-by: default avatarShalini Chellathurai Saroja <shalini@linux.ibm.com>
      Tested-by: default avatarShalini Chellathurai Saroja <shalini@linux.ibm.com>
      Acked-by: default avatarPierre Morel <pmorel@linux.ibm.com>
      Signed-off-by: default avatarNiklas Schnelle <schnelle@linux.ibm.com>
      Signed-off-by: default avatarHeiko Carstens <hca@linux.ibm.com>
      b76fee1b
    • Madhavan Srinivasan's avatar
      powerpc/kernel: Cleanup machine check function declarations · 388692e9
      Madhavan Srinivasan authored
      __machine_check_early_realmode_p*() are currently declared as extern
      in cputable.c and because of this when compiled with "C=1" (which
      enables semantic checker) produces these warnings.
      
          CHECK   arch/powerpc/kernel/mce_power.c
        arch/powerpc/kernel/mce_power.c:709:6: warning: symbol '__machine_check_early_realmode_p7' was not declared. Should it be static?
        arch/powerpc/kernel/mce_power.c:717:6: warning: symbol '__machine_check_early_realmode_p8' was not declared. Should it be static?
        arch/powerpc/kernel/mce_power.c:722:6: warning: symbol '__machine_check_early_realmode_p9' was not declared. Should it be static?
        arch/powerpc/kernel/mce_power.c:740:6: warning: symbol '__machine_check_early_realmode_p10' was not declared. Should it be static?
      
      Patch here moves the declaration to asm/mce.h and includes the same in
      cputable.c
      
      Fixes: ae744f34 ("powerpc/book3s: Flush SLB/TLBs if we get SLB/TLB machine check errors on power8")
      Fixes: 7b9f71f9
      
       ("powerpc/64s: POWER9 machine check handler")
      Signed-off-by: default avatarMadhavan Srinivasan <maddy@linux.ibm.com>
      Signed-off-by: default avatarMichael Ellerman <mpe@ellerman.id.au>
      Link: https://lore.kernel.org/r/20200817005618.3305028-1-maddy@linux.ibm.com
      388692e9
    • Madhavan Srinivasan's avatar
      powerpc: Add POWER10 raw mode cputable entry · 327da008
      Madhavan Srinivasan authored
      Add a raw mode cputable entry for POWER10. Copies most of the fields
      from commit a3ea40d5 ("powerpc: Add POWER10 architected mode")
      except for oprofile_cpu_type, machine_check_early, pvr_mask and
      pvr_mask fields. On bare metal systems we use DT CPU features, which
      doesn't need a cputable entry. But in VMs we still rely on the raw
      cputable entry to set the correct values for the PMU related fields.
      
      Fixes: a3ea40d5
      
       ("powerpc: Add POWER10 architected mode")
      Signed-off-by: default avatarMadhavan Srinivasan <maddy@linux.ibm.com>
      [mpe: Reorder vs cleanup patch and add Fixes tag]
      Signed-off-by: default avatarMichael Ellerman <mpe@ellerman.id.au>
      Link: https://lore.kernel.org/r/20200817005618.3305028-2-maddy@linux.ibm.com
      327da008