summaryrefslogtreecommitdiffstats
path: root/core
Commit message (Collapse)AuthorAgeFilesLines
* ipmi: call check_timers() while waiting for synchronous messages to complete04-16-2019Cédric Le Goater2019-04-301-1/+9
| | | | | | | | | | | | | BT responses are handled using a timer doing the polling. To hope to get an answer to an IPMI synchronous message, the timer needs to run. This issue shows up very quickly under QEMU when loading the first flash resource with the IPMI HIOMAP backend. Adding a timeout would also help in reporting errors instead of looping indefinitely waiting for a response. Signed-off-by: Cédric Le Goater <clg@kaod.org>
* Mark all partitions except full PNOR and boot kernel firmware read onlyTimothy Pearson2019-04-241-0/+7
| | | | Signed-off-by: Timothy Pearson <tpearson@raptorengineering.com>
* Expose PNOR Flash partitions to host MTD driver via devicetreeTimothy Pearson2019-04-241-12/+64
| | | | Signed-off-by: Timothy Pearson <tpearson@raptorengineering.com>
* asm/head.S: set POWER9 radix HID bit at entryNicholas Piggin2019-04-172-19/+2
| | | | | | | | | | | When running in virtual memory mode, the radix MMU hid bit should not be changed, so set this in the initial boot SPR setup. As a side effect, fast reboot also has HID0:RADIX bit set by the shared spr init, so no need for an explicit call. Signed-off-by: Nicholas Piggin <npiggin@gmail.com> Signed-off-by: Stewart Smith <stewart@linux.ibm.com>
* opal/hmi: Initialize the hmi event with old value of TFMR.Mahesh Salgaonkar2019-04-171-1/+3
| | | | | | | | | | | | | | | | | | | | | | | | | Do this before we fix TFAC errors. Otherwise the event at host console shows no thread error reported in TFMR register. Without this patch the console event show TFMR with no thread error: (DEC parity error TFMR[59] injection) [ 53.737572] Severe Hypervisor Maintenance interrupt [Recovered] [ 53.737596] Error detail: Timer facility experienced an error [ 53.737611] HMER: 0840000000000000 [ 53.737621] TFMR: 3212000870e04000 After this patch it shows old TFMR value on host console: [ 2302.267271] Severe Hypervisor Maintenance interrupt [Recovered] [ 2302.267305] Error detail: Timer facility experienced an error [ 2302.267320] HMER: 0840000000000000 [ 2302.267330] TFMR: 3212000870e14010 Fixes: 674f7696f ("opal/hmi: Rework HMI handling of TFAC errors") Cc: skiboot-stable@lists.ozlabs.org Signed-off-by: Mahesh Salgaonkar <mahesh@linux.vnet.ibm.com> Signed-off-by: Stewart Smith <stewart@linux.ibm.com>
* core/pci: Prefer ibm, slot-label when finding loc codesOliver O'Halloran2019-04-171-5/+10
| | | | | | | | | | | | | | | | | On OpenPower systems the ibm,slot-label property is used to identify slots rather than the more verbose ibm,slot-location-code. The slot-label lookup is currently broken since it assumes that the ibm,slot-label is in the PCI device node rather than in the node of the device that provides the slot (e.g. root port or switch downstream port). This patch corrects the lookup code to search the parent node (and possibly it's grandparents), similar to how we search for ibm,slot-location-code. Fixes: 1c3baae4f2b3 ("hdata/iohub: Look for IOVPD on P9") Signed-off-by: Oliver O'Halloran <oohall@gmail.com> Signed-off-by: Stewart Smith <stewart@linux.ibm.com>
* opal/hmi: Never trust a cow!Frederic Barrat2019-04-091-1/+1
| | | | | | | | | | With opencapi, it's fairly common to trigger HMIs during AFU development on the FPGA, by not replying in time to an NPU command, for example. So shift the blame reported by that cow to avoid crowding my mailbox. Signed-off-by: Frederic Barrat <fbarrat@linux.ibm.com> Signed-off-by: Stewart Smith <stewart@linux.ibm.com>
* hw/npu2: Dump (more) npu2 registers on link error and HMIsFrederic Barrat2019-04-091-57/+1
| | | | | | | | | | | | | | | | | | We were already logging some NPU registers during an HMI. This patch cleans up a bit how it is done and separates what is global from what is specific to nvlink or opencapi. Since we can now receive an error interrupt when an opencapi link goes down unexpectedly, we also dump the NPU state but we limit it to the registers of the brick which hit the error. The list of registers to dump was worked out with the hw team to allow for proper debugging. For each register, we print the name as found in the NPU workbook, the scom address and the register value. Signed-off-by: Frederic Barrat <fbarrat@linux.ibm.com> Reviewed-by: Andrew Donnellan <andrew.donnellan@au1.ibm.com> Signed-off-by: Stewart Smith <stewart@linux.ibm.com>
* cpufeatures: Add tm-suspend-hypervisor-assist and tm-suspend-xer-so-bug nodeStewart Smith2019-04-093-3/+209
| | | | | | | | | | | | | | | | | tm-suspend-hypervisor-assist for P9 >=DD2.2 And a tm-suspend-xer-so-bug node for P9 DD2.2 only. I also treat P9P as P9 DD2.3 and add a unit test for the cpufeatures infrastructure. Fixes: https://github.com/open-power/skiboot/issues/233 Suggested-by: Paul Mackerras <paulus@ozlabs.org> Signed-off-by: Stewart Smith <stewart@linux.ibm.com> Tested-by: Michael Neuling <mikey@neuling.org> Reviewed-by: Vaidyanathan Srinivasan <svaidy@linux.vnet.ibm.com> Tested-by: Vaidyanathan Srinivasan <svaidy@linux.vnet.ibm.com> [stewart: drop USABLE_OS for tm-suspend-hypervisor-assist] Signed-off-by: Stewart Smith <stewart@linux.ibm.com>
* Force noinline for pci_add_(one_)device_node(s)()Stewart Smith2019-03-291-10/+10
| | | | | | We call all of these things recursively, so don't use excess stack. Signed-off-by: Stewart Smith <stewart@linux.ibm.com>
* core/i2c: split i2c_request_send()Oliver O'Halloran2019-03-281-44/+53
| | | | | | | | | | | | | | | Split the i2c_request_send() method into two methods: i2c_request_send() which allocates and populates and i2c_request structure, and i2c_request_sync() which take a request structure and blocks until it completes. This allows code that allocates a i2c_request structure elsewhere to make use of the existing busy-wait and request retry logic. Fix the return types to use int64_t while we're here since these are returning OPAL_API error codes. Signed-off-by: Oliver O'Halloran <oohall@gmail.com> Signed-off-by: Stewart Smith <stewart@linux.ibm.com>
* core/i2c: Poll on request state in i2c_request_send()Oliver O'Halloran2019-03-281-22/+4
| | | | | | | | Use the new built-in state variable rather than a single-use completion function. Makes things a bit cleaner. Signed-off-by: Oliver O'Halloran <oohall@gmail.com> Signed-off-by: Stewart Smith <stewart@linux.ibm.com>
* core/stack: Rename backtrace functions, get rid of wrappersAndrew Donnellan2019-03-281-6/+7
| | | | | | | | | Rename ___backtrace() to backtrace_create() and ___print_backtrace() to backtrace_print(). Get rid of __backtrace() and __print_backtrace() wrappers. Signed-off-by: Andrew Donnellan <andrew.donnellan@au1.ibm.com> Signed-off-by: Stewart Smith <stewart@linux.ibm.com>
* core/stack: Convert stack check code to not use backtrace wrapperAndrew Donnellan2019-03-281-5/+5
| | | | | | | | We're about to get rid of __backtrace() and __print_backtrace(), convert the stack check code to not use them. Signed-off-by: Andrew Donnellan <andrew.donnellan@au1.ibm.com> Signed-off-by: Stewart Smith <stewart@linux.ibm.com>
* core/stack: Store PIR in ___backtrace()Andrew Donnellan2019-03-281-3/+3
| | | | | | | | In ___backtrace(), store the current PIR in the metadata struct, rather than relying on the caller to do it. Signed-off-by: Andrew Donnellan <andrew.donnellan@au1.ibm.com> Signed-off-by: Stewart Smith <stewart@linux.ibm.com>
* core/stack: Define a backtrace metadata structAndrew Donnellan2019-03-281-27/+26
| | | | | | | | | | | | | | | | Every time we take a backtrace, we have to store the number of entries, the OPAL API token, r1 caller and PIR values. Rather than defining these and passing them around all over the place, let's throw them in a struct. Define a struct, struct bt_metadata, to store these details, and convert ___backtrace() and ___print_backtrace() to use it. We change the wrapper functions __backtrace() and __print_backtrace() to call ___backtrace()/___print_backtrace() with struct bt_metadata, but don't change their parameter profiles for now - we'll do that later. Signed-off-by: Andrew Donnellan <andrew.donnellan@au1.ibm.com> Signed-off-by: Stewart Smith <stewart@linux.ibm.com>
* core/stack: Remove r1 argument from ___backtrace()Andrew Donnellan2019-03-281-4/+2
| | | | | | | | | ___backtrace() is always called with r1 = __builtin_frame_address(0), and it's unlikely we're going to need it to do something else any time soon, so simplify the API by removing the parameter. Signed-off-by: Andrew Donnellan <andrew.donnellan@au1.ibm.com> Signed-off-by: Stewart Smith <stewart@linux.ibm.com>
* Fix hang in pnv_platform_error_reboot path due to TOD failure.Mahesh Salgaonkar2019-03-281-0/+10
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | On TOD failure, with TB stuck, when linux heads down to pnv_platform_error_reboot() path due to unrecoverable hmi event, the panic cpu gets stuck in OPAL inside ipmi_queue_msg_sync(). At this time, rest all other cpus are in smp_handle_nmi_ipi() waiting for panic cpu to proceed. But with panic cpu stuck inside OPAL, linux never recovers/reboot. p0 c1 t0 NIA : 0x000000003001dd3c <.time_wait+0x64> CFAR : 0x000000003001dce4 <.time_wait+0xc> MSR : 0x9000000002803002 LR : 0x000000003002ecf8 <.ipmi_queue_msg_sync+0xec> STACK: SP NIA 0x0000000031c236e0 0x0000000031c23760 (big-endian) 0x0000000031c23760 0x000000003002ecf8 <.ipmi_queue_msg_sync+0xec> 0x0000000031c237f0 0x00000000300aa5f8 <.hiomap_queue_msg_sync+0x7c> 0x0000000031c23880 0x00000000300aaadc <.hiomap_window_move+0x150> 0x0000000031c23950 0x00000000300ab1d8 <.ipmi_hiomap_write+0xcc> 0x0000000031c23a90 0x00000000300a7b18 <.blocklevel_raw_write+0xbc> 0x0000000031c23b30 0x00000000300a7c34 <.blocklevel_write+0xfc> 0x0000000031c23bf0 0x0000000030030be0 <.flash_nvram_write+0xd4> 0x0000000031c23c90 0x000000003002c128 <.opal_write_nvram+0xd0> 0x0000000031c23d20 0x00000000300051e4 <opal_entry+0x134> 0xc000001fea6e7870 0xc0000000000a9060 <opal_nvram_write+0x80> 0xc000001fea6e78c0 0xc000000000030b84 <nvram_write_os_partition+0x94> 0xc000001fea6e7960 0xc0000000000310b0 <nvram_pstore_write+0xb0> 0xc000001fea6e7990 0xc0000000004792d4 <pstore_dump+0x1d4> 0xc000001fea6e7ad0 0xc00000000018a570 <kmsg_dump+0x140> 0xc000001fea6e7b40 0xc000000000028e5c <panic_flush_kmsg_end+0x2c> 0xc000001fea6e7b60 0xc0000000000a7168 <pnv_platform_error_reboot+0x68> 0xc000001fea6e7bd0 0xc0000000000ac9b8 <hmi_event_handler+0x1d8> 0xc000001fea6e7c80 0xc00000000012d6c8 <process_one_work+0x1b8> 0xc000001fea6e7d20 0xc00000000012da28 <worker_thread+0x88> 0xc000001fea6e7db0 0xc0000000001366f4 <kthread+0x164> 0xc000001fea6e7e20 0xc00000000000b65c <ret_from_kernel_thread+0x5c> This is because, there is a while loop towards the end of ipmi_queue_msg_sync() which keeps looping until "sync_msg" does not match with "msg". It loops over time_wait_ms() until exit condition is met. In normal scenario time_wait_ms() calls run pollers so that ipmi backend gets a chance to check ipmi response and set sync_msg to NULL. while (sync_msg == msg) time_wait_ms(10); But in the event when TB is in failed state time_wait_ms()->time_wait_poll() returns immediately without calling pollers and hence we end up looping forever. This patch fixes this hang by calling opal_run_pollers() in TB failed state as well. Fixes: 1764f2452 ("opal: Fix hang in time_wait* calls on HMI for TB errors.") Cc: skiboot-stable@lists.ozlabs.org Signed-off-by: Mahesh Salgaonkar <mahesh@linux.vnet.ibm.com> Signed-off-by: Stewart Smith <stewart@linux.ibm.com>
* core/ipmi: Print correct netfn valueVasant Hegde2019-03-281-1/+1
| | | | | | Fixes: 7516e382 (core/ipmi: Improve error message) Signed-off-by: Vasant Hegde <hegdevasant@linux.vnet.ibm.com> Signed-off-by: Stewart Smith <stewart@linux.ibm.com>
* external/mambo: Populate kernel-base-address in the DTRussell Currey2019-03-281-0/+9
| | | | | | | | | | | | | | skiboot.tcl defines PAYLOAD_ADDR as 0x20000000, which is the default in skiboot. This is also the default in skiboot unless kernel-base-address is set in the device tree. If you change PAYLOAD_ADDR to something else for mambo, skiboot won't see it because it doesn't set that DT property, so fix it so that it does. Signed-off-by: Russell Currey <ruscur@russell.cc> Acked-by: Michael Neuling <mikey@neuling.org> [stewart: fix up mambo hacks for STB] Signed-off-by: Stewart Smith <stewart@linux.ibm.com>
* core/flash: Retry requests as necessary in flash_load_resource()Andrew Jeffery2019-03-281-2/+31
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | We would like to successfully boot if we have a dependency on the BMC for flash even if the BMC is not current ready to service flash requests. On the assumption that it will become ready, retry for several minutes to cover a BMC reboot cycle and *eventually* rather than *immediately* crash out with: [ 269.549748] reboot: Restarting system [ 390.297462587,5] OPAL: Reboot request... [ 390.297737995,5] RESET: Initiating fast reboot 1... [ 391.074707590,5] Clearing unused memory: [ 391.075198880,5] PCI: Clearing all devices... [ 391.075201618,7] Clearing region 201ffe000000-201fff800000 [ 391.086235699,5] PCI: Resetting PHBs and training links... [ 391.254089525,3] FFS: Error 17 reading flash header [ 391.254159668,3] FLASH: Can't open ffs handle: 17 [ 392.307245135,5] PCI: Probing slots... [ 392.363723191,5] PCI Summary: ... [ 393.423255262,5] OCC: All Chip Rdy after 0 ms [ 393.453092828,5] INIT: Starting kernel at 0x20000000, fdt at 0x30800a88 390645 bytes [ 393.453202605,0] FATAL: Kernel is zeros, can't execute! [ 393.453247064,0] Assert fail: core/init.c:593:0 [ 393.453289682,0] Aborting! CPU 0040 Backtrace: S: 0000000031e03ca0 R: 000000003001af60 ._abort+0x4c S: 0000000031e03d20 R: 000000003001afdc .assert_fail+0x34 S: 0000000031e03da0 R: 00000000300146d8 .load_and_boot_kernel+0xb30 S: 0000000031e03e70 R: 0000000030026cf0 .fast_reboot_entry+0x39c S: 0000000031e03f00 R: 0000000030002a4c fast_reset_entry+0x2c --- OPAL boot --- The OPAL flash API hooks directly into the blocklevel layer, so there's no delay for e.g. the host kernel, just for asynchronously loaded resources during boot. Signed-off-by: Andrew Jeffery <andrew@aj.id.au> Signed-off-by: Stewart Smith <stewart@linux.ibm.com>
* core/pcie-slot: Don't bail early in the power on caseOliver O'Halloran2019-03-281-4/+5
| | | | | | | | | | Exiting early in the power off case makes sense since we can't disable slot power (or assert PERST) for suprise hotplug slots. However, we should not exit early in the power-on case since it's possible slot power may have been disabled (or just not enabled at boot time). Signed-off-by: Oliver O'Halloran <oohall@gmail.com> Signed-off-by: Stewart Smith <stewart@linux.ibm.com>
* core/pcie-slot: Better explain suprise_checkOliver O'Halloran2019-03-281-16/+11
| | | | | | | Working out what was actually going on here took forever. Signed-off-by: Oliver O'Halloran <oohall@gmail.com> Signed-off-by: Stewart Smith <stewart@linux.ibm.com>
* core/pcie-slot: Set power state from the PWRCTL flagOliver O'Halloran2019-03-281-3/+3
| | | | | | | | | | | | | For some reason we look at the power control indicator and use that to determine if the slot is "off" rather than the power control flag that is used to power down the slot. While we're here change the default behaviour so that the slot is assumed to be powered on if there's no slot capability, or if there's no power control available. Signed-off-by: Oliver O'Halloran <oohall@gmail.com> Signed-off-by: Stewart Smith <stewart@linux.ibm.com>
* core/pci: Increase the max slot string sizeOliver O'Halloran2019-03-281-1/+1
| | | | | | | | | | | | | | | | | | | The maximum string length for the slot label / device location code in the PCI summary is currently 32 characters. This results in some IBM location codes being truncated due to their length, e.g. PHB#0001:02:11.0 [SWDN] SLOT=C11 x8 PHB#0001:13:00.0 [EP ] *snip* LOC_CODE=U78D3.ND1.WZS004A-P1-C PHB#0001:13:00.1 [EP ] *snip* LOC_CODE=U78D3.ND1.WZS004A-P1-C PHB#0001:13:00.2 [EP ] *snip* LOC_CODE=U78D3.ND1.WZS004A-P1-C PHB#0001:13:00.3 [EP ] *snip* LOC_CODE=U78D3.ND1.WZS004A-P1-C Which obscure the actual location of the card, and it looks bad. This patch increases the maximum length of the label string to 80 characters since that's the maximum length for a location code. Signed-off-by: Oliver O'Halloran <oohall@gmail.com> Signed-off-by: Stewart Smith <stewart@linux.ibm.com>
* hdata/iohub: Look for IOVPD on P9Oliver O'Halloran2019-03-281-0/+6
| | | | | | | | | | | P8 and P9 use the same IO VPD setup, so we need to load the IOHUB VPD on P9 systems too. Signed-off-by: Oliver O'Halloran <oohall@gmail.com> Tested-by: Vasant Hegde <hegdevasant@linux.vnet.ibm.com> [stewart: fixup op920 hdat_to_dt dts expected result, remove incorrect comment, skip IOVPD loading on non-FSP.] Signed-off-by: Stewart Smith <stewart@linux.ibm.com>
* fast-reboot: occ: Call occ_pstates_init() on fast-reset on all machinesShilpasri G Bhat2019-03-151-2/+4
| | | | | | | | | | | | | | | Commit 815417dcda2e ("init, occ: Initialise OCC earlier on BMC systems") conditionally invoked occ_pstates_init() only on FSP based systems in load_and_boot_kernel(). Due to this pstate table is re-parsed on FSP system and skipped on BMC system during fast-reboot. So this patch fixes this by invoking occ_pstates_init() on all boxes during fast-reboot. Cc: skiboot-stable@lists.ozlabs.org Fixes: 815417dcda2e ("init, occ: Initialise OCC earlier on BMC systems") Reported-by: Vasant Hegde <hegdevasant@linux.vnet.ibm.com> Signed-off-by: Shilpasri G Bhat <shilpa.bhat@linux.vnet.ibm.com> Reviewed-by: Vasant Hegde <hegdevasant@linux.vnet.ibm.com> Signed-off-by: Stewart Smith <stewart@linux.ibm.com>
* opal/hmi: set a flag to inform OS that TOD/TB has failed.Mahesh Salgaonkar2019-03-051-1/+3
| | | | | | | | | | Set a flag to indicate OS about TOD/TB failure as part of new opal_handle_hmi2 handler. This flag then can be used by OS to make sure functions depending on TB value (e.g. udelay()) are aware of TB not ticking. Signed-off-by: Mahesh Salgaonkar <mahesh@linux.vnet.ibm.com> Signed-off-by: Stewart Smith <stewart@linux.ibm.com>
* opal/hmi: Fix double unlock of hmi lock in failure path.Mahesh Salgaonkar2019-03-051-5/+1
| | | | | | | unlock once and goto error_out. Signed-off-by: Mahesh Salgaonkar <mahesh@linux.vnet.ibm.com> Signed-off-by: Stewart Smith <stewart@linux.ibm.com>
* i2c: Fix sparse warnings for type assignmentStewart Smith2019-03-011-5/+5
| | | | | | | | | | | | | | | | | | | | Use the correct beXX_to_cpu() macros. core/i2c.c:105:29: warning: incorrect type in assignment (different base types) core/i2c.c:105:29: expected unsigned int [usertype] offset core/i2c.c:105:29: got restricted beint32_t [usertype] subaddr core/i2c.c:110:29: warning: incorrect type in assignment (different base types) core/i2c.c:110:29: expected unsigned int [usertype] offset core/i2c.c:110:29: got restricted beint32_t [usertype] subaddr core/i2c.c:117:23: warning: incorrect type in assignment (different base types) core/i2c.c:117:23: expected unsigned int [usertype] dev_addr core/i2c.c:117:23: got restricted beint16_t [usertype] addr core/i2c.c:118:21: warning: incorrect type in assignment (different base types) core/i2c.c:118:21: expected unsigned int [usertype] rw_len core/i2c.c:118:21: got restricted beint32_t [usertype] size core/i2c.c:119:24: warning: cast from restricted beint64_t Signed-off-by: Stewart Smith <stewart@linux.ibm.com>
* hw/bt: Do not disable ipmi message retry during OPAL bootVasant Hegde2019-03-011-1/+2
| | | | | | | | | | | | | | | Currently OPAL doesn't know whether BMC is functioning or not. If BMC is down (like BMC reboot), then we keep on retry sending message to BMC. So in some corner cases we may hit hard lockup issue in kernel. Ideally we should avoid using synchronous path as much as possible. But for now commit 01f977c3 added option to disable message retry in synchronous. But this fix is not required during boot. Hence lets disable IPMI message retry during OPAL boot. Fixes: 01f977c3 (hw/bt: Add backend interface to disable ipmi message) Signed-off-by: Vasant Hegde <hegdevasant@linux.vnet.ibm.com> Signed-off-by: Stewart Smith <stewart@linux.ibm.com>
* core/ipmi: Add ipmi sync messages to top of the listVasant Hegde2019-03-011-1/+1
| | | | | | | | | | In ipmi_queue_msg_sync() path OPAL will wait until it gets response from BMC. If we do not get response ontime we may endup in kernel hardlockups. Hence lets add sync messages to top of the queue. This will reduces the chance of hardlockups. Signed-off-by: Vasant Hegde <hegdevasant@linux.vnet.ibm.com> Signed-off-by: Stewart Smith <stewart@linux.ibm.com>
* Don't use variable length arrays in exception codeStewart Smith2019-03-011-14/+13
| | | | | | | OMG Kees Cook was right, the code is *smaller*. We save like a dozen instructions in the exception path! Signed-off-by: Stewart Smith <stewart@linux.ibm.com>
* imc/catalog: Decompress catalog asynchronouslySantosh Sivaraj2019-02-251-0/+3
| | | | | | | | | | | | | | | In-Memory Collection(IMC) counters catalog is compressed blob which is loaded from the flash; decompression starts once the data is loaded from nvram by the main thread. This can be optimized by using the libxz API function which creates a job to do the decompression by not blocking the main thread. Refactor decompress() to use the libxz asynchronous wrapper functions. This also cleans up the error handling path in imc_init(). CC: Madhavan Srinivasan <maddy@linux.vnet.ibm.com> Signed-off-by: Santosh Sivaraj <santosh@fossix.org> Signed-off-by: Stewart Smith <stewart@linux.ibm.com>
* flash: Add support for async decompressionSantosh Sivaraj2019-02-251-0/+103
| | | | | | | | | | | | | | | | | Implement a standard API for decompressing images using the existing method found in the IMC code. This patch also standardizes error codes and does the decompression asynchronously. The IMC decompress() function is refactored to decompress blobs/images as a separate CPU job. 'xz_decompress_start()' starts the decompression in a newly created CPU job; while 'wait_xz_decompress()' waits for the job to complete. The IMC code will be first user for the new APIs; whose implementation is provided as reference in the next patch. Signed-off-by: Santosh Sivaraj <santosh@fossix.org> Signed-off-by: Stewart Smith <stewart@linux.ibm.com>
* hw/bt: Add backend interface to disable ipmi message retry optionVasant Hegde2019-02-201-0/+2
| | | | | | | | | | | | | | | | | | | | | | | | | During boot OPAL makes IPMI_GET_BT_CAPS call to BMC to get BT interface capabilities which includes IPMI message max resend count, message timeout, etc,. Most of the time OPAL gets response from BMC within specified timeout. In some corner cases (like mboxd daemon reset in BMC, BMC reboot, etc) OPAL may not get response within timeout period. In such scenarios, OPAL resends message until max resend count reaches. OPAL uses synchronous IPMI message (ipmi_queue_msg_sync()) for few operations like flash read, write, etc. Thread will wait in OPAL until it gets response from BMC. In some corner cases like BMC reboot, thread may wait in OPAL for long time (more than 20 seconds) and results in kernel hardlockup. This patch introduces new interface to disable message resend option. We will disable message resend option for synchrous message. This will greatly reduces kernel hardlock up issues. This is short term fix. Long term solution is to convert all synchronous messages to asynhrounous one. Signed-off-by: Vasant Hegde <hegdevasant@linux.vnet.ibm.com> Signed-off-by: Stewart Smith <stewart@linux.ibm.com>
* opal: Deprecate reading the PHB statusAlexey Kardashevskiy2019-02-182-3/+13
| | | | | | | | | | | | | | | | | The OPAL_PCI_EEH_FREEZE_STATUS call takes a bunch of parameters, one of them is @phb_status. It is defined as __be64* and always NULL in the current Linux upstream but if anyone ever decides to read that status, then the PHB3's handler will assume it is struct OpalIoPhb3ErrorData* (which is a lot bigger than 8 bytes) and zero it causing the stack corruption; p7ioc-phb has the same issue. This removes @phb_status from all eeh_freeze_status() hooks and moves the error message from PHB4 to the affected OPAL handlers. Signed-off-by: Alexey Kardashevskiy <aik@ozlabs.ru> Reviewed-by: Andrew Donnellan <andrew.donnellan@au1.ibm.com> Reviewed-By: Oliver O'Halloran <oohall@gmail.com> Signed-off-by: Stewart Smith <stewart@linux.ibm.com>
* firmware-versions: Add test case for parsing VERSIONStewart Smith2019-02-1318-147/+364
| | | | | | | | | | | | | | | | Also make it possible to use with afl-lop/afl-fuzz just to help make *sure* we're all good. Additionally, if we hit a entry in VERSION that is larger than our buffer size, we skip over it gracefully rather than overwriting the stack. This is only a problem if VERSION isn't trusted, which as of 4b8cc05a94513816d43fb8bd6178896b430af08f it is verified as part of Secure Boot. CC: stable # v5.9+ Fixes: 9727fe384b8685270d344201f7e051475eea3a0b [stewart: fix up include ordering for building on centos7] Signed-off-by: Stewart Smith <stewart@linux.ibm.com>
* core/exceptions: implement support for MCE interrupts in powersaveNicholas Piggin2019-02-132-4/+24
| | | | | | | | | | | | | | The ISA specifies that MCE interrupts in power saving modes will enter at 0x200 with powersave bits in SRR1 set. This is not currently supported properly, the MCE will just happen like a normal interrupt, but GPRs could be lost, which would lead to crashes (e.g., r1, r2, r13 etc). So check the power save bits similarly to the sreset vector, and handle this properly. Signed-off-by: Nicholas Piggin <npiggin@gmail.com> Signed-off-by: Stewart Smith <stewart@linux.ibm.com>
* core/exceptions: allow recoverable sreset exceptionsNicholas Piggin2019-02-134-17/+49
| | | | | | | | This requires implementing the MSR[RI] bit. Then just allow all non-fatal sreset exceptions to recover. Signed-off-by: Nicholas Piggin <npiggin@gmail.com> Signed-off-by: Stewart Smith <stewart@linux.ibm.com>
* core/exceptions: implement an exception handler for non-powersave sresetsNicholas Piggin2019-02-132-10/+49
| | | | | | | | Detect non-powersave sresets and send them to the normal exception handler which prints registers and stack. Signed-off-by: Nicholas Piggin <npiggin@gmail.com> Signed-off-by: Stewart Smith <stewart@linux.ibm.com>
* core/fast-reboot: fast reboot specific sreset patchNicholas Piggin2019-02-132-12/+20
| | | | | | | | | | | | Provide an sreset handler specifically for fast reboots, which allows FIXUP_ENDIAN to be removed from the normal sreset handler in the next patch. The save_1 == 0 condition is no longer required to signal a fast reboot. Signed-off-by: Nicholas Piggin <npiggin@gmail.com> Signed-off-by: Stewart Smith <stewart@linux.ibm.com>
* asm/head: provide asm support for interrupts to be returned fromNicholas Piggin2019-02-131-2/+2
| | | | | | | | | | | | | | This adds the redzone to the interrupt stack, and code to restore registers. This can be used for a number of things. Initially it will be used to recover from system reset interrupts, it could later be used to handle recoverable machine checks, use the decrementer to implement a watchdog, handle HMI interrupts at boot, and to implement virtual memory. Signed-off-by: Nicholas Piggin <npiggin@gmail.com> Signed-off-by: Stewart Smith <stewart@linux.ibm.com>
* core/init: enable machine check on secondariesNicholas Piggin2019-02-132-0/+40
| | | | | | | | | | Secondary CPUs currently run with MSR[ME]=0 during boot, whih means if they take a machine check, the system will checkstop. Enable ME where possible and allow them to print registers. Signed-off-by: Nicholas Piggin <npiggin@gmail.com> Signed-off-by: Stewart Smith <stewart@linux.ibm.com>
* core/fast-reboot: improve NMI handling during fast resetNicholas Piggin2019-02-131-0/+34
| | | | | | | | | | | Improve sreset and MCE handling in fast reboot. Switch the HILE bit off before copying OPAL's exception vectors, so NMIs can be handled properly. Also disable MSR[ME] while the vectors are being overwritten. Some of the remaining problem cases are documented in comments. Signed-off-by: Nicholas Piggin <npiggin@gmail.com> Signed-off-by: Stewart Smith <stewart@linux.ibm.com>
* core/init: rearrange final boot stepsNicholas Piggin2019-02-131-12/+11
| | | | | | | | | Take secondaries out of sleep mode as late as possible, which tends to help with simulator boot speeds. Make give_self_os() the last step before starting the kernel, which matches the way secondaries behave. Signed-off-by: Nicholas Piggin <npiggin@gmail.com> Signed-off-by: Stewart Smith <stewart@linux.ibm.com>
* core/exceptions: save current MSR in exception frameNicholas Piggin2019-02-121-26/+31
| | | | | | | | | Save and print the MSR of the interrupt context. This can be derived from the interrupt type, SRR1, and other system register settings. But it can be useful to quickly verify what's happening. Signed-off-by: Nicholas Piggin <npiggin@gmail.com> Signed-off-by: Stewart Smith <stewart@linux.ibm.com>
* core/cpu: do not inline cpu_relaxNicholas Piggin2019-02-121-0/+12
| | | | | | | | | The added nops now push it up in size, and -Os uninlines it for every compilation unit that calls it more than once, so it's much better to just uninline. Signed-off-by: Nicholas Piggin <npiggin@gmail.com> Signed-off-by: Stewart Smith <stewart@linux.ibm.com>
* core/init: rename setup_reset_vectorNicholas Piggin2019-02-122-3/+3
| | | | | | | Use the word copy, to match copy_exception_vectors. Signed-off-by: Nicholas Piggin <npiggin@gmail.com> Signed-off-by: Stewart Smith <stewart@linux.ibm.com>
* core/cpu: HID update raceNicholas Piggin2019-02-121-2/+2
| | | | | | | | | | | | If the per-core HID register is updated concurrently by multiple threads, updates can get lost. This has been observed during fast reboot where the HILE bit does not get cleared on all cores, which can cause machine check exception interrupts to crash. Fix this by only updating HID on thread0. Signed-off-by: Nicholas Piggin <npiggin@gmail.com> Signed-off-by: Stewart Smith <stewart@linux.ibm.com>
OpenPOWER on IntegriCloud