- 21 Dec, 2018 12 commits
-
-
Mahesh Salgaonkar authored
For fadump to work successfully there should not be any holes in reserved memory ranges where kernel has asked firmware to move the content of old kernel memory in event of crash. Now that fadump uses CMA for reserved area, this memory area is now not protected from hot-remove operations unless it is cma allocated. Hence, fadump service can fail to re-register after the hot-remove operation, if hot-removed memory belongs to fadump reserved region. To avoid this make sure that memory from fadump reserved area is not hot-removable if fadump is registered. However, if user still wants to remove that memory, he can do so by manually stopping fadump service before hot-remove operation. Signed-off-by:
Mahesh Salgaonkar <mahesh@linux.vnet.ibm.com> Signed-off-by:
Michael Ellerman <mpe@ellerman.id.au>
-
Mahesh Salgaonkar authored
fadump fails to register when there are holes in reserved memory area. This can happen if user has hot-removed a memory that falls in the fadump reserved memory area. Throw a meaningful error message to the user in such case. Signed-off-by:
-
Mahesh Salgaonkar authored
One of the primary issues with Firmware Assisted Dump (fadump) on Power is that it needs a large amount of memory to be reserved. On large systems with TeraBytes of memory, this reservation can be quite significant. In some cases, fadump fails if the memory reserved is insufficient, or if the reserved memory was DLPAR hot-removed. In the normal case, post reboot, the preserved memory is filtered to extract only relevant areas of interest using the makedumpfile tool. While the tool provides flexibility to determine what needs to be part of the dump and what memory to filter out, all supported distributions default this to "Capture only kernel data and nothing else". We take advantage of this default and the Linux kernel's Contiguous Memory Allocator (CMA) to fundamentally change the memory reservation model for fadump. Instead of setting aside a significant chunk of memory nobody can use, this patch uses CMA instead, to reserve a significant chunk of memory that the kernel is prevented from using (due to MIGRATE_CMA), but applications are free to use it. With this fadump will still be able to capture all of the kernel memory and most of the user space memory except the user pages that were present in CMA region. Essentially, on a P9 LPAR with 2 cores, 8GB RAM and current upstream: [root@zzxx-yy10 ~]# free -m total used free shared buff/cache available Mem: 7557 193 6822 12 541 6725 Swap: 4095 0 4095 With this patch: [root@zzxx-yy10 ~]# free -m total used free shared buff/cache available Mem: 8133 194 7464 12 475 7338 Swap: 4095 0 4095 Changes made here are completely transparent to how fadump has traditionally worked. Thanks to Aneesh Kumar and Anshuman Khandual for helping us understand CMA and its usage. TODO: - Handle case where CMA reservation spans nodes. Signed-off-by:Ananth N Mavinakayanahalli <ananth@linux.vnet.ibm.com> Signed-off-by:
Hari Bathini <hbathini@linux.ibm.com> Signed-off-by:
-
Mahesh Salgaonkar authored
opal_power_control_init() depends on opal message notifier to be initialized, which is done in opal_init()->opal_message_init(). But both these initialization are called through machine initcalls and it all depends on in which order they being called. So far these are called in correct order (may be we got lucky) and never saw any issue. But it is clearer to control initialization order explicitly by moving opal_power_control_init() into opal_init(). Signed-off-by:
-
Markus Elfring authored
The script "checkpatch.pl" pointed information out like the following. WARNING: void function return statements are not generally useful Thus remove such a statement in the affected functions. Signed-off-by:
Markus Elfring <elfring@users.sourceforge.net> Signed-off-by:
-
Markus Elfring authored
Omit an extra message for a memory allocation failure in these functions. This issue was detected by using the Coccinelle software. Signed-off-by:
-
Markus Elfring authored
A single character (line break) should be put into a sequence. Thus use the corresponding function "seq_putc". This issue was detected by using the Coccinelle software. Signed-off-by:
-
Markus Elfring authored
Some data were printed into a sequence by four separate function calls. Print the same data by two single function calls instead. This issue was detected by using the Coccinelle software. Signed-off-by:
-
Christophe Leroy authored
CONFIG_EARLY_DEBUG_CPM requires IMMR area TLB to be pinned otherwise it doesn't survive MMU_init, and the boot fails. Signed-off-by:
Christophe Leroy <christophe.leroy@c-s.fr> Signed-off-by:
-
Oliver O'Halloran authored
CONFIG_PCI_MSI was made mandatory by commit a311e738 ("powerpc/powernv: Make PCI non-optional") so the #ifdef checks around CONFIG_PCI_MSI here can be removed entirely. Signed-off-by:
Oliver O'Halloran <oohall@gmail.com> Reviewed-by:
Joel Stanley <joel@jms.id.au> Signed-off-by:
-
Alexandre Belloni authored
Fix a spelling mistake in a register description. Signed-off-by:
Alexandre Belloni <alexandre.belloni@bootlin.com> Signed-off-by:
-
Ravi Bangoria authored
Commit 14c63f17 ("perf: Drop sample rate when sampling is too slow") introduced a way to throttle PMU interrupts if we're spending too much time just processing those. Wire up powerpc PMI handler to use this infrastructure. We have throttling of the *rate* of interrupts, but this adds throttling based on the *time taken* to process the interrupts. Signed-off-by:
Ravi Bangoria <ravi.bangoria@linux.ibm.com> Signed-off-by:
-
- 20 Dec, 2018 28 commits
-
-
Alexey Kardashevskiy authored
The current implementation of the OPAL_PCI_EEH_FREEZE_STATUS call in skiboot's NPU driver does not touch the pci_error_type parameter so it might have garbage but the powernv code analyzes it nevertheless. This initializes pcierr and fstate to zero in all call sites. Signed-off-by:
Alexey Kardashevskiy <aik@ozlabs.ru> Reviewed-by:
Sam Bobroff <sbobroff@linux.ibm.com> Signed-off-by:
-
Alexey Kardashevskiy authored
fixup_phb() is never used, this removes it. pick_m64_pe() and reserve_m64_pe() are always defined for all powernv PHBs: they are initialized by pnv_ioda_parse_m64_window() which is called unconditionally from pnv_pci_init_ioda_phb() which initializes all known PHB types on powernv so we can open code them. Signed-off-by:
-
Alexey Kardashevskiy authored
At the moment PNV_IODA_PE_DEV is only used for NPU PEs which are not present on IODA1 machines (i.e. POWER7) so let's remove a piece of dead code. Signed-off-by:
-
Alexey Kardashevskiy authored
As a part of cleanup, the SPAPR TCE IOMMU subdriver releases preregistered memory. If there is a bug in memory release, the loop in tce_iommu_release() becomes infinite; this actually happened to me. This makes the loop finite and prints a warning on every failure to make the code more bug prone. Signed-off-by:
David Gibson <david@gibson.dropbear.id.au> Acked-by:
Alex Williamson <alex.williamson@redhat.com> Signed-off-by:
-
Alexey Kardashevskiy authored
The macro and few headers are not used so remove them. Signed-off-by:
Alistair Popple <alistair@popple.id.au> Signed-off-by:
-
Alexey Kardashevskiy authored
The powernv platform maintains 2 TCE tables for VFIO - a hardware TCE table and a table with userspace addresses; the latter is used for marking pages dirty when corresponging TCEs are unmapped from the hardware table. a68bd126 ("powerpc/powernv/ioda: Allocate indirect TCE levels on demand") enabled on-demand allocation of the hardware table, however it missed the other table so it has still been fully allocated at the boot time. This fixes the issue by allocating a single level, just like we do for the hardware table. Fixes: a68bd126 ("powerpc/powernv/ioda: Allocate indirect TCE levels on demand") Signed-off-by:
-
YueHaibing authored
Use DEFINE_DEBUGFS_ATTRIBUTE rather than DEFINE_SIMPLE_ATTRIBUTE for debugfs files. Semantic patch information: Rationale: DEFINE_SIMPLE_ATTRIBUTE + debugfs_create_file() imposes some significant overhead as compared to DEFINE_DEBUGFS_ATTRIBUTE + debugfs_create_file_unsafe(). Generated by: scripts/coccinelle/api/debugfs/debugfs_simple_attr.cocci Signed-off-by:
YueHaibing <yuehaibing@huawei.com> Acked-by:
Russell Currey <ruscur@russell.cc> Signed-off-by:
-
Diana Craciun authored
Signed-off-by:
Diana Craciun <diana.craciun@nxp.com> Signed-off-by:
-
Diana Craciun authored
Report branch predictor state flush as a mitigation for Spectre variant 2. Signed-off-by:
-
Diana Craciun authored
If the user choses not to use the mitigations, replace the code sequence with nops. Signed-off-by:
-
Diana Craciun authored
Switching from the guest to host is another place where the speculative accesses can be exploited. Flush the branch predictor when entering KVM. Signed-off-by:
-
Diana Craciun authored
In order to protect against speculation attacks on indirect branches, the branch predictor is flushed at kernel entry to protect for the following situations: - userspace process attacking another userspace process - userspace process attacking the kernel Basically when the privillege level change (i.e.the kernel is entered), the branch predictor state is flushed. Signed-off-by:
-
Diana Craciun authored
In order to protect against speculation attacks on indirect branches, the branch predictor is flushed at kernel entry to protect for the following situations: - userspace process attacking another userspace process - userspace process attacking the kernel Basically when the privillege level change (i.e. the kernel is entered), the branch predictor state is flushed. Signed-off-by:
-
Diana Craciun authored
When the command line argument is present, the Spectre variant 2 mitigations are disabled. Signed-off-by:
-
Diana Craciun authored
In order to flush the branch predictor the guest kernel performs writes to the BUCSR register which is hypervisor privilleged. However, the branch predictor is flushed at each KVM entry, so the branch predictor has been already flushed, so just return as soon as possible to guest. Signed-off-by:
-
Diana Craciun authored
Currently for CONFIG_PPC_FSL_BOOK3E the spectre_v2 file is incorrect: $ cat /sys/devices/system/cpu/vulnerabilities/spectre_v2 "Mitigation: Software count cache flush" Which is wrong. Fix it to report vulnerable for now. Fixes: ee13cb24 ("powerpc/64s: Add support for software count cache flush") Cc: stable@vger.kernel.org # v4.19+ Signed-off-by:
-
Diana Craciun authored
The BUCSR register can be used to invalidate the entries in the branch prediction mechanisms. Signed-off-by:
-
Diana Craciun authored
In order to protect against speculation attacks (Spectre variant 2) on NXP PowerPC platforms, the branch predictor should be flushed when the privillege level is changed. This patch is adding the infrastructure to fixup at runtime the code sections that are performing the branch predictor flush depending on a boot arg parameter which is added later in a separate patch. Signed-off-by:
-
Christophe Leroy authored
If the device tree doesn't reside in the memory which is declared inside it, it has to be moved as well as this memory will not be mapped by the kernel. Signed-off-by:
-
Michael Ellerman authored
Add some documentation on which CPU versions map to which ISA versions. This is all publicly available information, some of it already in the kernel source, but it's much nicer to have it all in one place. Signed-off-by: -
Michael Ellerman authored
This reverts the remains of commit b9ef7d6b ("powerpc: Update default configurations"). That commit was proceeded by a commit which added a config option to control use of BOOTX for early debug, ie. PPC_EARLY_DEBUG_BOOTX, and then the update of the defconfigs was intended to not change behaviour by then enabling the new config option. However enabling PPC_EARLY_DEBUG had other consequences, notably causing us to register the udbg console at the end of udbg_early_init(). This means on a system which doesn't have anything that BOOTX can use (most systems), we register the udbg console very early but the bootx code just throws everything away, meaning early boot messages are never printed to the console. What we want to happen is for the udbg console to only be registered later (from setup_arch()) once we've setup udbg_putc, and then all early boot messages will be replayed. Fixes: b9ef7d6b ("powerpc: Update default configurations") Reported-by:
Torsten Duwe <duwe@lst.de> Signed-off-by:
-
Arnd Bergmann authored
For this use case, completions and semaphores are equivalent, but semaphores are an awkward interface that should generally be avoided, so use the completion instead. Signed-off-by:
Arnd Bergmann <arnd@arndb.de> Signed-off-by:
-
Greg Kurz authored
The AFU irq code doesn't need to reach out to the platform. Signed-off-by:
Greg Kurz <groug@kaod.org> Acked-by:
Andrew Donnellan <andrew.donnellan@au1.ibm.com> Signed-off-by:
-
Greg Kurz authored
Implementing rollback with goto and labels is a common practice that leads to prettier and more maintainable code. FWIW, this design pattern is already being used in alloc_link() a few lines below in this file. Do the same in setup_xsl_irq(). Signed-off-by:
Frederic Barrat <fbarrat@linux.ibm.com> Acked-by:
-
Benjamin Herrenschmidt authored
The bamboo dts has a bug: it uses a non-naturally aligned range for PCI memory space. This isnt' supported by the code, thus causing PCI to break on this system. This is due to the fact that while the chip memory map has 1G reserved for PCI memory, it's only 512M aligned. The code doesn't know how to split that into 2 different PMMs and fails, so limit the region to 512M. Signed-off-by:
Benjamin Herrenschmidt <benh@kernel.crashing.org> Signed-off-by:
-
Darren Stevens authored
Add a IRQ init routine for the Nemo board which inits and attatches the i8259 found in the SB600, and a cascade routine to dispatch the interrupts. Signed-off-by:
Darren Stevens <darren@stevens-zone.net> Signed-off-by:
-
Darren Stevens authored
Add routines for Nemo specific devices to init at boot time, these being board level power-off and SB600's rtc. Also add a run time variable to prevent these being activated if we boot on a reference board. Signed-off-by:
-
Darren Stevens authored
Add a IRQ init routine for the Nemo board which inits and attatches the i8259 found in the SB600, and a cascade routine to dispatch the interrupts. Signed-off-by:
-
