- 08 Feb, 2021 11 commits
-
-
Oliver O'Halloran authored
Signed-off-by:
Oliver O'Halloran <oohall@gmail.com> Signed-off-by:
Michael Ellerman <mpe@ellerman.id.au> Link: https://lore.kernel.org/r/20201103043523.916109-13-oohall@gmail.com
-
Oliver O'Halloran authored
Signed-off-by:
-
Oliver O'Halloran authored
Signed-off-by:
-
Oliver O'Halloran authored
Signed-off-by:
-
Oliver O'Halloran authored
Signed-off-by:
-
Oliver O'Halloran authored
Signed-off-by:
-
Oliver O'Halloran authored
Signed-off-by:
-
Oliver O'Halloran authored
Signed-off-by:
-
Oliver O'Halloran authored
Signed-off-by:
-
Oliver O'Halloran authored
Signed-off-by:
-
Oliver O'Halloran authored
Make powernv, pseries, powermac and maple use ppc_mc.discover_phbs. These platforms need to be done together because they all depend on pci_dn's being created from the DT. The pci_dn contains a pointer to the relevant pci_controller so they need to be created after the pci_controller structures are available, but before PCI devices are scanned. Currently this ordering is provided by initcalls and the sequence is: 1. PHBs are discovered (setup_arch) (early boot, pre-initcalls) 2. pci_dn are created from the unflattended DT (core initcall) 3. PHBs are scanned pcibios_init() (subsys initcall) The new ppc_md.discover_phbs() function is also a core_initcall so we can't guarantee ordering between the creation of pci_controllers and the creation of pci_dn's which require a pci_controller. We could use the postcore, or core_sync initcall levels, but it's cleaner to just move the pci_dn setup into the per-PHB inits which occur inside of .discover_phb() for these platforms. This brings the boot-time path in line with the PHB hotplug path that is used for pseries DLPAR operations too. Signed-off-by:
-
- 02 Feb, 2021 1 commit
-
-
Oliver O'Halloran authored
On many powerpc platforms the discovery and initalisation of pci_controllers (PHBs) happens inside of setup_arch(). This is very early in boot (pre-initcalls) and means that we're initialising the PHB long before many basic kernel services (slab allocator, debugfs, a real ioremap) are available. On PowerNV this causes an additional problem since we map the PHB registers with ioremap(). As of commit d538aadc ("powerpc/ioremap: warn on early use of ioremap()") a warning is printed because we're using the "incorrect" API to setup and MMIO mapping in searly boot. The kernel does provide early_ioremap(), but that is not intended to create long-lived MMIO mappings and a seperate warning is printed by generic code if early_ioremap() mappings are "leaked." This is all fixable with dumb hacks like using early_ioremap() to setup the initial mapping then replacing it with a real ioremap later on in boot, but it does raise the question: Why the hell are we setting up the PHB's this early in boot? The old and wise claim it's due to "hysterical rasins." Aside from amused grapes there doesn't appear to be any real reason to maintain the current behaviour. Already most of the newer embedded platforms perform PHB discovery in an arch_initcall and between the end of setup_arch() and the start of initcalls none of the generic kernel code does anything PCI related. On powerpc scanning PHBs occurs in a subsys_initcall so it should be possible to move the PHB discovery to a core, postcore or arch initcall. This patch adds the ppc_md.discover_phbs hook and a core_initcall stub that calls it. The core_initcalls are the earliest to be called so this will any possibly issues with dependency between initcalls. This isn't just an academic issue either since on pseries and PowerNV EEH init occurs in an arch_initcall and depends on the pci_controllers being available, similarly the creation of pci_dns occurs at core_initcall_sync (i.e. between core and postcore initcalls). These problems need to be addressed seperately. Reported-by:
kernel test robot <lkp@intel.com> Signed-off-by:
-
- 31 Jan, 2021 23 commits
-
-
Oliver O'Halloran authored
The pnv_phb->initialized flag is an odd beast. It was added back in 2012 in commit db1266c8 ("powerpc/powernv: Skip check on PE if necessary") to allow devices to be enabled even if the device had not yet been assigned to a PE. Allowing the device to be enabled before the PE is configured may cause spurious EEH events since none of the IOMMU context has been setup. I'm not entirely sure why this was ever necessary. My best guess is that it was an workaround for a bug or some other undesireable behaviour from the PCI core. Either way, it's unnecessary now since as of commit dc3d8f85 ("powerpc/powernv/pci: Re-work bus PE configuration") we can guarantee that the PE will be configured before the PCI core will allow drivers to bind to the device. It's also worth pointing out that the ->initialized flag is only set in pnv_pci_ioda_create_dbgfs(). That function has its entire body wrapped in #ifdef CONFIG_DEBUG_FS. As a result, for kernels built without debugfs (i.e. petitboot) the other checks in pnv_pci_enable_device_hook() are bypassed entirely. Signed-off-by:
-
Christophe Leroy authored
Powerpc 8xx requires CONSOLE_POLL to get udbg_putc() and udbg_getc() in CPM uart driver. Signed-off-by:
Christophe Leroy <christophe.leroy@csgroup.eu> Signed-off-by:
-
Christophe Leroy authored
Since commit 4ad8622d ("powerpc/8xx: Implement hw_breakpoint"), 8xx has breakpoints so there is no reason to opt breakpoint logic out of xmon for the 8xx. Fixes: 4ad8622d ("powerpc/8xx: Implement hw_breakpoint") Signed-off-by:
-
Christophe Leroy authored
It is now possible to only build book3s/32 kernel for CPUs without hash table. Opt out hash related code when CONFIG_PPC_BOOK3S_604 is not selected. Signed-off-by:
-
Markus Elfring authored
A bit of information should be put into a sequence. Thus improve the execution speed for this data output by better usage of corresponding functions. This issue was detected by using the Coccinelle software. Signed-off-by:
Markus Elfring <elfring@users.sourceforge.net> Signed-off-by:
-
Markus Elfring authored
Adjust jump targets so that a bit of exception handling can be better reused at the end of this function. This issue was detected by using the Coccinelle software. Signed-off-by:
-
Markus Elfring authored
A null pointer would be passed to a call of the function “of_node_put” immediately after a call of the function “of_find_compatible_node” failed at one place. Remove this superfluous function call. This issue was detected by using the Coccinelle software. Signed-off-by:
-
Markus Elfring authored
Omit an extra message for a memory allocation failure in this function. Signed-off-by:
Nathan Lynch <nathanl@linux.ibm.com> Signed-off-by:
-
Markus Elfring authored
A null pointer would be passed to a call of the function “kfree” immediately after a call of the function “kstrdup” failed at one place. Remove this superfluous function call. This issue was detected by using the Coccinelle software. Signed-off-by:
-
Markus Elfring authored
A local variable was used only within an if branch. Thus move the definition for the variable “mm” into the corresponding code block. This issue was detected by using the Coccinelle software. Signed-off-by:
-
Qian Cai authored
It is safe to traverse mm->context.iommu_group_mem_list with either mem_list_mutex or the RCU read lock held. Silence a few RCU-list false positive warnings and fix a few missing RCU read locks. arch/powerpc/mm/book3s64/iommu_api.c:330 RCU-list traversed in non-reader section!! other info that might help us debug this: rcu_scheduler_active = 2, debug_locks = 1 2 locks held by qemu-kvm/4305: #0: c000000bc3fe4d68 (&container->lock){+.+.}-{3:3}, at: tce_iommu_ioctl.part.9+0xc7c/0x1870 [vfio_iommu_spapr_tce] #1: c000000001501910 (mem_list_mutex){+.+.}-{3:3}, at: mm_iommu_get+0x50/0x190 ==== arch/powerpc/mm/book3s64/iommu_api.c:132 RCU-list traversed in non-reader section!! other info that might help us debug this: rcu_scheduler_active = 2, debug_locks = 1 2 locks held by qemu-kvm/4305: #0: c000000bc3fe4d68 (&container->lock){+.+.}-{3:3}, at: tce_iommu_ioctl.part.9+0xc7c/0x1870 [vfio_iommu_spapr_tce] #1: c000000001501910 (mem_list_mutex){+.+.}-{3:3}, at: mm_iommu_do_alloc+0x120/0x5f0 ==== arch/powerpc/mm/book3s64/iommu_api.c:292 RCU-list traversed in non-reader section!! other info that might help us debug this: rcu_scheduler_active = 2, debug_locks = 1 2 locks held by qemu-kvm/4312: #0: c000000ecafe23c8 (&vcpu->mutex){+.+.}-{3:3}, at: kvm_vcpu_ioctl+0xdc/0x950 [kvm] #1: c000000045e6c468 (&kvm->srcu){....}-{0:0}, at: kvmppc_h_put_tce+0x88/0x340 [kvm] ==== arch/powerpc/mm/book3s64/iommu_api.c:424 RCU-list traversed in non-reader section!! other info that might help us debug this: rcu_scheduler_active = 2, debug_locks = 1 2 locks held by qemu-kvm/4312: #0: c000000ecafe23c8 (&vcpu->mutex){+.+.}-{3:3}, at: kvm_vcpu_ioctl+0xdc/0x950 [kvm] #1: c000000045e6c468 (&kvm->srcu){....}-{0:0}, at: kvmppc_h_put_tce+0x88/0x340 [kvm] Signed-off-by:Qian Cai <cai@lca.pw> Signed-off-by:
-
Qian Cai authored
It is unsafe to traverse tbl->it_group_list without the RCU read lock. WARNING: suspicious RCU usage 5.7.0-rc4-next-20200508 #1 Not tainted ----------------------------- arch/powerpc/platforms/powernv/pci-ioda-tce.c:355 RCU-list traversed in non-reader section!! other info that might help us debug this: rcu_scheduler_active = 2, debug_locks = 1 3 locks held by qemu-kvm/4305: #0: c000000bc3fe6988 (&container->group_lock){++++}-{3:3}, at: vfio_fops_unl_ioctl+0x108/0x410 [vfio] #1: c00800000fcc7400 (&vfio.iommu_drivers_lock){+.+.}-{3:3}, at: vfio_fops_unl_ioctl+0x148/0x410 [vfio] #2: c000000bc3fe4d68 (&container->lock){+.+.}-{3:3}, at: tce_iommu_attach_group+0x3c/0x4f0 [vfio_iommu_spapr_tce] stack backtrace: CPU: 4 PID: 4305 Comm: qemu-kvm Not tainted 5.7.0-rc4-next-20200508 #1 Call Trace: [c0000010f29afa60] [c0000000007154c8] dump_stack+0xfc/0x174 (unreliable) [c0000010f29afab0] [c0000000001d8ff0] lockdep_rcu_suspicious+0x140/0x164 [c0000010f29afb30] [c0000000000dae2c] pnv_pci_unlink_table_and_group+0x11c/0x200 [c0000010f29afb70] [c0000000000d4a34] pnv_pci_ioda2_unset_window+0xc4/0x190 [c0000010f29afbf0] [c0000000000d4b4c] pnv_ioda2_take_ownership+0x4c/0xd0 [c0000010f29afc30] [c00800000fd60ee0] tce_iommu_attach_group+0x2c8/0x4f0 [vfio_iommu_spapr_tce] [c0000010f29afcd0] [c00800000fcc11a0] vfio_fops_unl_ioctl+0x238/0x410 [vfio] [c0000010f29afd50] [c0000000005430a8] ksys_ioctl+0xd8/0x130 [c0000010f29afda0] [c000000000543128] sys_ioctl+0x28/0x40 [c0000010f29afdc0] [c000000000038af4] system_call_exception+0x114/0x1e0 [c0000010f29afe20] [c00000000000c8f0] system_call_common+0xf0/0x278 Signed-off-by: -
Michal Suchanek authored
./arch/powerpc/include/asm/paravirt.h:83:44: error: implicit declaration of function 'smp_processor_id'; did you mean 'raw_smp_processor_id'? smp_processor_id is defined in linux/smp.h but it is not included. The build error happens only when the patch is applied to 5.3 kernel but it only works by chance in mainline. Fixes: ca3f969d ("powerpc/paravirt: Use is_kvm_guest() in vcpu_is_preempted()") Signed-off-by:
Michal Suchanek <msuchanek@suse.de> Signed-off-by:
-
Ganesh Goudar authored
Access to per-cpu variables requires translation to be enabled on pseries machine running in hash mmu mode, Since part of MCE handler runs in realmode and part of MCE handling code is shared between ppc architectures pseries and powernv, it becomes difficult to manage these variables differently on different architectures, So have these variables in paca instead of having them as per-cpu variables to avoid complications. Signed-off-by:
Ganesh Goudar <ganeshgr@linux.ibm.com> Signed-off-by:
-
Ganesh Goudar authored
Maximum recursive depth of MCE is 4, Considering the maximum depth allowed reduce the size of event to 10 from 100. This saves us ~19kB of memory and has no fatal consequences. Signed-off-by:
-
Pingfan Liu authored
When CONFIG_IRQ_TIME_ACCOUNTING and CONFIG_VIRT_CPU_ACCOUNTING_GEN, powerpc does not enable "sched_clock_irqtime" and can not utilize irq time accounting. Like x86, powerpc does not use the sched_clock_register() interface. So it needs an dedicated call to enable_sched_clock_irqtime() to enable irq time accounting. Fixes: 518470fe ("powerpc: Add HAVE_IRQ_TIME_ACCOUNTING") Signed-off-by:
Pingfan Liu <kernelfans@gmail.com> [mpe: Add fixes tag] Signed-off-by:
-
Cédric Le Goater authored
The "ibm,arch-vec-5-platform-support" property is a list of pairs of bytes representing the options and values supported by the platform firmware. At boot time, Linux scans this list and activates the available features it recognizes : Radix and XIVE. A recent change modified the number of entries to loop on and 8 bytes, 4 pairs of { options, values } entries are always scanned. This is fine on KVM but not on PowerVM which can advertises less. As a consequence on this platform, Linux reads extra entries pointing to random data, interprets these as available features and tries to activate them, leading to a firmware crash in ibm,client-architecture-support. Fix that by using the property length of "ibm,arch-vec-5-platform-support". Fixes: ab912399 ("powerpc/prom: Remove VLA in prom_check_platform_support()") Cc: stable@vger.kernel.org # v4.20+ Signed-off-by:Cédric Le Goater <clg@kaod.org> Reviewed-by:
Fabiano Rosas <farosas@linux.ibm.com> Signed-off-by:
-
Oliver O'Halloran authored
Nothing uses it. Signed-off-by:
-
Oliver O'Halloran authored
If a PCI device's current driver implements the error handling callbacks EEH can use them to recover the device after an error occurs. For devices without the error handling callbacks we recover them by removing the device and re-scanning it so the PCI core puts the device back into a known good state. Currently there's no way for userspace to determine if the driver supports recovery or not which makes it difficult to write automated tests for EEH. This patch addressing that by adding a debugfs interface for querying if a specific device can be recovered or not. Signed-off-by:
-
Oliver O'Halloran authored
Pull the string -> pci_dev lookup stuff into a helper function. No functional change. Signed-off-by:
-
Oliver O'Halloran authored
The basic EEH test ignores VFs since we the way the eeh_dev_break debugfs interface works means that if multiple VFs are enabled we may cause errors on all them them. However, we can work around that by only enabling a single VF at a time. This patch adds some infrastructure for finding SR-IOV capable devices and enabling / disabling VFs so we can exercise the VF specific EEH recovery paths. Two new tests are added, one for testing EEH aware devices and one for EEH un-aware VFs. Signed-off-by:
-
Oliver O'Halloran authored
We want to use stdout to return lists of devices, etc so log debug / status messages to stderr rather than stdout. Signed-off-by:
-
Oliver O'Halloran authored
Hoist some of the useful test environment checking and prep code into eeh-functions.sh so they can be reused in other tests. Signed-off-by:
-
- 30 Jan, 2021 5 commits
-
-
Ananth N Mavinakayanahalli authored
We currently just percolate the return value from analyze_instr() to the caller of emulate_step(), especially if it is a -1. For one particular case (opcode = 4) for instructions that aren't currently emulated, we are returning 'should not be single-stepped' while we should have returned 0 which says 'did not emulate, may have to single-step'. Fixes: 930d6288 ("powerpc: sstep: Add support for maddhd, maddhdu, maddld instructions") Signed-off-by:
Ananth N Mavinakayanahalli <ananth@linux.ibm.com> Suggested-by:
Naveen N. Rao <naveen.n.rao@linux.vnet.ibm.com> Reviewed-by:
Sandipan Das <sandipan@linux.ibm.com> Signed-off-by:
-
Ananth N Mavinakayanahalli authored
We currently unconditionally try to emulate newer instructions on older Power versions that could cause issues. Gate it. Fixes: 350779a2 ("powerpc: Handle most loads and stores in instruction emulation code") Signed-off-by:
-
Christophe Leroy authored
STDBINUTILS is just a toggle to allow 256k page size to appear in the possible page sizes list for the 44x. Make 256k page size option appear all the time with an explicit warning about binutils, and remove this unnecessary STDBINUTILS config option. Signed-off-by:
-
Christophe Leroy authored
PPC47x_TLBE_SIZE isn't defined for 256k pages, leading to a build break if 256k pages is selected. So change the kconfig so that 256k pages can't be selected for 47x. Fixes: e7f75ad0 ("powerpc/47x: Base ppc476 support") Reported-by:
-
Christophe Leroy authored
book3s/32 kvm is designed with the assumption that an FPU is always present. Force selection of FPU support in the kernel when build KVM. Fixes: 7d68c891 ("powerpc/32s: Allow deselecting CONFIG_PPC_FPU on mpc832x") Reported-by:
-
