summaryrefslogtreecommitdiffstats
Commit message (Collapse)AuthorAgeFilesLines
...
* skiboot 5.9.5 Release NotesStewart Smith2017-12-131-0/+77
| | | | | | Signed-off-by: Stewart Smith <stewart@linux.vnet.ibm.com> (cherry picked from commit 34f923a938ddb8553287f34d7991b75035867f36) Signed-off-by: Stewart Smith <stewart@linux.vnet.ibm.com>
* external/test: make stripping out version number more robustStewart Smith2017-12-131-2/+2
| | | | | | | | | For some bizarre reason, Travis started failing on this substitution when there'd been zero code changes in this area... This at least papers over whatever the problem is for the time being. Signed-off-by: Stewart Smith <stewart@linux.vnet.ibm.com>
* xive: Ensure VC informational FIRs are maskedBenjamin Herrenschmidt2017-12-112-0/+11
| | | | | | | | | Some HostBoot versions leave those as checkstop, they are harmless and can sometimes occur during normal operations. Signed-off-by: Benjamin Herrenschmidt <benh@kernel.crashing.org> Tested-by: Oliver O'Halloran <oohall@gmail.com> Signed-off-by: Stewart Smith <stewart@linux.vnet.ibm.com>
* xive: Fix occasional VC checkstops in xive_resetBenjamin Herrenschmidt2017-12-111-3/+54
| | | | | | | | | | | | | | | | | | | | | | | | | | The current workaround for the scrub bug described in __xive_cache_scrub() has an issue in that it can leave dirty invalid entries in the cache. When cleaning up EQs or VPs during reset, if we then remove the underlying indirect page for these entries, the XIVE will checkstop when trying to flush them out of the cache. This replaces the existing workaround with a new pair of workarounds for VPs and EQs: - The VP one does the dummy watch on another entry than the one we scrubbed (which does the job of pushing old stores out) using an entry that is known to be backed by a permanent indirect page. - The EQ one switches to a more efficient workaround which consists of doing a non-side-effect ESB load from the EQ's ESe control bits. Signed-off-by: Benjamin Herrenschmidt <benh@kernel.crashing.org> Signed-off-by: Stewart Smith <stewart@linux.vnet.ibm.com>
* io: Add load_wait() helperBenjamin Herrenschmidt2017-12-111-0/+8
| | | | | | | | | | | | | | | | | | | | | | | This uses the standard form twi/isync pair to ensure a load is consumed by the core before continuing. This can be necessary under some circumstances for example when having the following sequence: - Store reg A - Load reg A (ensure above store pushed out) - delay loop - Store reg A IE, a mandatory delay between 2 stores. In theory the first store is only guaranteed to rach the device after the load from the same location has completed. However the processor will start executing the delay loop without waiting for the return value from the load. This construct enforces that the delay loop isn't executed until the load value has been returned. Signed-off-by: Benjamin Herrenschmidt <benh@kernel.crashing.org> Signed-off-by: Stewart Smith <stewart@linux.vnet.ibm.com>
* xive: Do not return a trigger page for an escalation interruptBenjamin Herrenschmidt2017-12-111-2/+2
| | | | | | | | | This is bogus, we don't support them. (Thankfully the callers didn't actually try to use this on escalation interrupts). Signed-off-by: Benjamin Herrenschmidt <benh@kernel.crashing.org> Tested-by: Oliver O'Halloran <oohall@gmail.com> Signed-off-by: Stewart Smith <stewart@linux.vnet.ibm.com>
* xive: Mark a freed IRQ's IVE as valid and maskedBenjamin Herrenschmidt2017-12-111-1/+1
| | | | | | | | | | | Removing the valid bit means a FIR will trip if it's accessed inadvertently. Under some circumstances, the XIVE will speculatively access an IVE for a masked interrupt and trip it. So make sure that freed entries are still marked valid (but masked). Signed-off-by: Benjamin Herrenschmidt <benh@kernel.crashing.org> Tested-by: Oliver O'Halloran <oohall@gmail.com> Signed-off-by: Stewart Smith <stewart@linux.vnet.ibm.com>
* chiptod: Keep boot timestamps contiguousOliver O'Halloran2017-12-112-7/+16
| | | | | | | | | | | | | | | | | | | | | | | Currently we reset the timebase value to (almost) zero when synchronising the timebase of each chip to the Chip TOD network which results in this: [ 42.374813167,5] CPU: All 80 processors called in... [ 2.222791151,5] FLASH: Found system flash: Macronix MXxxL51235F id:0 [ 2.222977933,5] BT: Interface initialized, IO 0x00e4 This patch modifies the chiptod_init() process to use the current timebase value rather than resetting it to zero. This results in the timestamps remaining contigious from the start of hostboot until the petikernel starts. e.g. [ 70.188811484,5] CPU: All 144 processors called in... [ 72.458004252,5] FLASH: Found system flash: id:0 [ 72.458147358,5] BT: Interface initialized, IO 0x00e4 Signed-off-by: Oliver O'Halloran <oohall@gmail.com> Reviewed-by: Vaidyanathan Srinivasan <svaidy@linux.vnet.ibm.com> Signed-off-by: Stewart Smith <stewart@linux.vnet.ibm.com>
* hdata/spira: Add missing newline to prlog() callReza Arbab2017-12-111-1/+1
| | | | | | | We're missing a \n here. Signed-off-by: Reza Arbab <arbab@linux.vnet.ibm.com> Signed-off-by: Stewart Smith <stewart@linux.vnet.ibm.com>
* opal/xscom: Add recovery for lost core wakeup scom failures.Mahesh Salgaonkar2017-12-112-3/+85
| | | | | | | | | | | | | | | | | | | Due to a hardware issue where core responding to scom was delayed due to thread reconfiguration, leaves the SCOM logic in a state where the subsequent scom to that core can get errors. This is affected for Core PC scom registers in the range of 20010A80-20010ABF The solution is if a xscom timeout occurs to one of Core PC scom registers in the range of 20010A80-20010ABF, a clearing scom write is done to 0x20010800 with data of '0x00000000' which will also get a timeout but clears the scom logic errors. After the clearing write is done the original scom operation can be retried. The scom timeout is reported as status 0x4 (Invalid address) in HMER[21-23]. Signed-off-by: Mahesh Salgaonkar <mahesh@linux.vnet.ibm.com> Reviewed-by: Nicholas Piggin <npiggin@gmail.com> Signed-off-by: Stewart Smith <stewart@linux.vnet.ibm.com>
* opal/xscom: Move the delay inside xscom_reset() function.Mahesh Salgaonkar2017-12-111-18/+21
| | | | | | | | | | So caller of xscom_reset() does not have to bother about adding a delay separately. Instead caller can control whether to add a delay or not using second argument to xscom_reset(). Signed-off-by: Mahesh Salgaonkar <mahesh@linux.vnet.ibm.com> Reviewed-by: Nicholas Piggin <npiggin@gmail.com> Signed-off-by: Stewart Smith <stewart@linux.vnet.ibm.com>
* phb4: Change PCI MMIO timersMichael Neuling2017-12-111-2/+2
| | | | | | | | | | | | | Currently we have a mismatch between the NCU and PCI timers for MMIO accesses. The PCI timers must be lower than the NCU timers otherwise it may cause checkstops. This changes PCI timeouts controlled by skiboot to 33-50ms. It should be forwards and backwards compatible with expected hostboot changes to the NCU timer. Signed-off-by: Michael Neuling <mikey@neuling.org> Signed-off-by: Stewart Smith <stewart@linux.vnet.ibm.com>
* timer: Stop calling list_top() racilyBenjamin Herrenschmidt2017-12-111-4/+5
| | | | | | | | | | This will trip the debug checks in debug builds under some circumstances and is actually a rather bad idea as we might look at a timer that is concurrently being removed and modified, and thus incorrectly assume there is no work to do. Signed-off-by: Benjamin Herrenschmidt <benh@kernel.crashing.org> Signed-off-by: Stewart Smith <stewart@linux.vnet.ibm.com>
* fsp: Bail out of HIR if FSP is resetting voluntarilyAnanth N Mavinakayanahalli2017-12-061-4/+16
| | | | | | | | | | | | | | | | a. Surveillance response times out and OPAL triggers a HIR b. Before the HIR process kicks in, OPAL gets a PSI interrupt indicating link down c. HIR process continues and OPAL tries to write to DRCR; PSI link inactive => xstop OPAL should confirm that the FSP is not already in reset in the HIR path. [V2] Handle the case where a second reset is triggered due to the two resets happening in succession. Signed-off-by: Ananth N Mavinakayanahalli <ananth@linux.vnet.ibm.com> Tested-by: Pridhiviraj Paidipeddi <ppaidipe@linux.vnet.ibm.com> Reviewed-by: Vasant Hegde <hegdevasant@linux.vnet.ibm.com> Signed-off-by: Stewart Smith <stewart@linux.vnet.ibm.com>
* Fix booting & OPAL call return values with DEBUG=1Stewart Smith2017-12-061-2/+3
| | | | | | | | | | | | | | | | | | On a debug build, _mcount would trash r3 and opal_exit_check would not restore it, leaving OPAL calls returning garbage. this fix simply preserves the return value and doesn't let the compiler get fancy on us. We effectively just get an extra `mr` instruction to restore r3. Fixes: 9c565ee6bca4b665d9d1120bfff5e88ee80615bc Reported-by: Benjamin Herrenschmidt <benh@kernel.crashing.org> Reported-by: Andrew Donnellan <andrew.donnellan@au1.ibm.com> Suggested-by: Nicholas Piggin <npiggin@gmail.com> Signed-off-by: Stewart Smith <stewart@linux.vnet.ibm.com> Reviewed-by: Andrew Donnellan <andrew.donnellan@au1.ibm.com> Tested-by: Andrew Donnellan <andrew.donnellan@au1.ibm.com> Signed-off-by: Stewart Smith <stewart@linux.vnet.ibm.com>
* hw/imc: Check ucode state before exposing units to LinuxMadhavan Srinivasan2017-12-051-1/+22
| | | | | | | | | | | | | | | | | | | | disable_unavailable_units() checks whether the ucode is in the running state before enabling the nest units in the device tree. From a recent debug, it is found that on some system boot, ucode is not loaded and running in all the chips in the system. And this caused a fail in OPAL_IMC_COUNTERS_STOP call where we check for ucode state on each chip. Bug here is that disable_unavailable_units() checks the state of the ucode only in boot cpu chip. Patch adds a condition in disable_unavailable_units() to check for the ucode state in all the chip before enabling the nest units in the device tree node. Fixes: f98d59958db19 ('skiboot: Find the IMC DTB') Signed-off-by: Madhavan Srinivasan <maddy@linux.vnet.ibm.com> [stewart: clarify with comment and better variable name] Signed-off-by: Stewart Smith <stewart@linux.vnet.ibm.com>
* dctl: p9 increase thread quiesce timeoutNicholas Piggin2017-12-041-4/+14
| | | | | | | | | | | | | | We require all instructions to be completed before a thread is considered stopped, by the dctl interface. Long running instructions like cache misses and CI loads may take a significant amount of time to complete, and timeouts have been observed in stress testing. Increase the timeout significantly, to cover this. The workbook just says to poll, but we like to have timeouts to avoid getting stuck in firmware. Signed-off-by: Nicholas Piggin <npiggin@gmail.com> Signed-off-by: Stewart Smith <stewart@linux.vnet.ibm.com>
* sreset_kernel: only run SMT tests due to not supporting re-entryStewart Smith2017-12-042-9/+2
| | | | | Fixes: 0d84ea6bda03a00a1765dd7240a9e5231a537e96 Signed-off-by: Stewart Smith <stewart@linux.vnet.ibm.com>
* Use systemsim-p9 v1.1Stewart Smith2017-12-048-11/+11
| | | | Signed-off-by: Stewart Smith <stewart@linux.vnet.ibm.com>
* direct-controls: enable fast reboot direct controls for mamboNicholas Piggin2017-12-033-4/+25
| | | | | | | | Add mambo direct controls to stop threads, which is required for reliable fast-reboot. Enable direct controls by default on mambo. Signed-off-by: Nicholas Piggin <npiggin@gmail.com> Signed-off-by: Stewart Smith <stewart@linux.vnet.ibm.com>
* fast-reboot: bare bones fast reboot implementation for POWER9Nicholas Piggin2017-12-035-33/+79
| | | | | | | | | | | | | This is an initial fast reboot implementation for p9 which has only been tested on the Witherspoon platform, and without the use of NPUs, NX/VAS, etc. This has worked reasonably well so far, with no failures in about 100 reboots. It is hidden behind the traditional fast-reboot experimental nvram option, until more platforms and configurations are tested. Signed-off-by: Nicholas Piggin <npiggin@gmail.com> Signed-off-by: Stewart Smith <stewart@linux.vnet.ibm.com>
* fast-reboot: move boot CPU cleanup logically together with secondariesNicholas Piggin2017-12-031-8/+8
| | | | | | | | | | | | Move the boot CPU cleanup and state transition to active, logically together with secondaries. Don't release secondaries from fast reboot hold until everyone has cleaned up and transitioned to active. This is cosmetic, but it is helpful to run the fast reboot state machine the same way on all CPUs. Signed-off-by: Nicholas Piggin <npiggin@gmail.com> Signed-off-by: Stewart Smith <stewart@linux.vnet.ibm.com>
* fast-reboot: move fdt freeing into initNicholas Piggin2017-12-032-7/+9
| | | | Signed-off-by: Stewart Smith <stewart@linux.vnet.ibm.com>
* fast-reboot: improve failure error messagesNicholas Piggin2017-12-031-3/+13
| | | | | | | | | Change existing failure error messages to PR_NOTICE so they get printed to the console, and add some new ones. It's not a more severe class because it falls back to IPL on failure. Signed-off-by: Nicholas Piggin <npiggin@gmail.com> Signed-off-by: Stewart Smith <stewart@linux.vnet.ibm.com>
* fast-reboot: quiesce opal before initiating a fast rebootNicholas Piggin2017-12-033-39/+24
| | | | | | | | | | | | | | | | | | | Switch fast reboot to use quiescing rather than "wait for a while". If firmware can not be quiesced, then fast reboot is skipped. This significantly improves the robustness of fast reboot in the face of bugs or unexpected latencies. Complexity of synchronization in fast-reboot is reduced, because we are guaranteed to be single-threaded when quiesce succeeds, so locks can be removed. In the case that firmware can be quiesced, then it will generally reduce fast reboot times by nearly 200ms, because quiescing usually takes very little time. Signed-off-by: Nicholas Piggin <npiggin@gmail.com> Signed-off-by: Stewart Smith <stewart@linux.vnet.ibm.com>
* core: Add support for quiescing OPALNicholas Piggin2017-12-037-4/+250
| | | | | | | | | | | | | | | | Quiescing is ensuring all host controlled CPUs (except the current one) are out of OPAL and prevented from entering. This can be use in debug and shutdown paths, particularly with system reset sequences. This patch adds per-CPU entry and exit tracking for OPAL calls, and adds logic to "hold" or "reject" at entry time, if OPAL is quiesced. An OPAL call is added, to expose the functionality to Linux, where it can be used for shutdown, kexec, and before generating sreset IPIs for debugging (so the debug code does not recurse into OPAL). Signed-off-by: Nicholas Piggin <npiggin@gmail.com> Signed-off-by: Stewart Smith <stewart@linux.vnet.ibm.com>
* core/opal: always verify cpu->pir on entryNicholas Piggin2017-12-031-5/+7
| | | | | Signed-off-by: Nicholas Piggin <npiggin@gmail.com> Signed-off-by: Stewart Smith <stewart@linux.vnet.ibm.com>
* asm/head: move opal entry token check into CNicholas Piggin2017-12-032-12/+8
| | | | | | | Move opal_check_token from asm to C. Signed-off-by: Nicholas Piggin <npiggin@gmail.com> Signed-off-by: Stewart Smith <stewart@linux.vnet.ibm.com>
* asm/head: add entry/exit callsNicholas Piggin2017-12-032-10/+33
| | | | | | | | | Add entry and exit C functions that can do some more complex checks before the opal proper call. This requires saving off volatile registers that have arguments in them. Signed-off-by: Nicholas Piggin <npiggin@gmail.com> Signed-off-by: Stewart Smith <stewart@linux.vnet.ibm.com>
* core/lock: improve bust_locksNicholas Piggin2017-12-031-0/+3
| | | | | | | | | Prevent try_lock from modifying the lock state when bust_locks is set. unlock will not unlock it in that case, so locks will get taken and never released while bust_locks is set. Signed-off-by: Nicholas Piggin <npiggin@gmail.com> Signed-off-by: Stewart Smith <stewart@linux.vnet.ibm.com>
* core/lock: Introduce atomic cmpxchg and implement try_lock with itNicholas Piggin2017-12-036-50/+88
| | | | | | | | | cmpxchg will be used in a subsequent change, and this reduces the amount of asm code. Signed-off-by: Nicholas Piggin <npiggin@gmail.com> [stewart: fix some ifdef __TEST__ foo to ensure unittests work] Signed-off-by: Stewart Smith <stewart@linux.vnet.ibm.com>
* direct-controls: add xscom error handling for p8Nicholas Piggin2017-12-031-9/+27
| | | | | | | | Add xscom checks which will print something useful and return error back to callers (which already have error handling plumbed in). Signed-off-by: Nicholas Piggin <npiggin@gmail.com> Signed-off-by: Stewart Smith <stewart@linux.vnet.ibm.com>
* direct-controls: p8 implementation of generic direct controlsNicholas Piggin2017-12-031-93/+119
| | | | | | | | | | | This reworks the sreset functionality that was brought over from fast-reboot, and fits it under the generic direct controls APIs. The fast reboot APIs are implemented using generic direct controls, which also makes them available on p9. Signed-off-by: Nicholas Piggin <npiggin@gmail.com> Signed-off-by: Stewart Smith <stewart@linux.vnet.ibm.com>
* direct-controls: change p8_sreset_all_others sequenceNicholas Piggin2017-12-031-10/+5
| | | | | | | | | Change the p8_sreset_all_others sequence from prenap all, sreset all; to prenap, sreset all. This makes it more suitable to fit the direct controls APIs, which does not expose "prenap". Signed-off-by: Nicholas Piggin <npiggin@gmail.com> Signed-off-by: Stewart Smith <stewart@linux.vnet.ibm.com>
* fast-reboot: move sreset direct controls to direct-controls.cNicholas Piggin2017-12-033-283/+322
| | | | | Signed-off-by: Nicholas Piggin <npiggin@gmail.com> Signed-off-by: Stewart Smith <stewart@linux.vnet.ibm.com>
* fast-reboot: allow mambo fast reboot independent of CPU typeNicholas Piggin2017-12-031-1/+2
| | | | | | | Don't tie mambo fast reboot to POWER8 CPU type. Signed-off-by: Nicholas Piggin <npiggin@gmail.com> Signed-off-by: Stewart Smith <stewart@linux.vnet.ibm.com>
* fast-reboot: move de-asserting of special wakeups to the initiatorNicholas Piggin2017-12-031-3/+3
| | | | | | | | | | | | | Currently the boot CPU (not the initiator) clears special wakeups after all CPUs have called in. After the earlier change to have the initiator wait for secondaries before calling in, this is no longer necessary. Have the initiator finish the entire sreset sequence, clearing special wakeups after all others have called in. Signed-off-by: Nicholas Piggin <npiggin@gmail.com> Signed-off-by: Stewart Smith <stewart@linux.vnet.ibm.com>
* fast-reboot: inline fast_reset_p8 into fast_rebootNicholas Piggin2017-12-031-30/+24
| | | | | | | | | This function has shrunk to the point it's not so helpful to keep it, it's no longer power8 specific, and getting rid of it simplifies error handling a little in future changes. Signed-off-by: Nicholas Piggin <npiggin@gmail.com> Signed-off-by: Stewart Smith <stewart@linux.vnet.ibm.com>
* fast-reboot: remove delay after sresetNicholas Piggin2017-12-031-2/+1
| | | | | | | | | There is a 100ms delay when targets reach sreset which does not appear to have a good purpose. Remove it and therefore reduce the sreset timeout by the same amount. Signed-off-by: Nicholas Piggin <npiggin@gmail.com> Signed-off-by: Stewart Smith <stewart@linux.vnet.ibm.com>
* fast-reboot: add more barriers around cpu state changesNicholas Piggin2017-12-032-1/+7
| | | | | | | | This is a bit of paranoia, but when a CPU changes state to signal it has reached a particular point, all previous stores should be visible. Signed-off-by: Nicholas Piggin <npiggin@gmail.com> Signed-off-by: Stewart Smith <stewart@linux.vnet.ibm.com>
* fast-reboot: add sreset timeout detection and handlingNicholas Piggin2017-12-031-33/+45
| | | | | | | | | | | | | Have the initiator wait for all its sreset targets to call in, and time out after 200ms if they did not. Fail and revert to IPL reboot. Testing indicates that after successful sreset_all_others(), it takes less than 102ms (in hundreds of fast reboots) for secondaries to call in. 100 of that is due to an initial delay, but core un-splitting was not measured. Signed-off-by: Nicholas Piggin <npiggin@gmail.com> Signed-off-by: Stewart Smith <stewart@linux.vnet.ibm.com>
* fast-reboot: make spin loops consistent and SMT friendlyNicholas Piggin2017-12-031-9/+15
| | | | | Signed-off-by: Nicholas Piggin <npiggin@gmail.com> Signed-off-by: Stewart Smith <stewart@linux.vnet.ibm.com>
* fast-reboot: add sreset_all_others error handlingNicholas Piggin2017-12-031-10/+13
| | | | | | | | | | | | Pass back failures from sreset_all_others, also change return codes to OPAL_ form in sreset_all_prepare to match. Errors will revert to the IPL path, so it's not critical to completely clean up everything if that would complicate things. Detecting the error and failing is the important thing. Signed-off-by: Nicholas Piggin <npiggin@gmail.com> Signed-off-by: Stewart Smith <stewart@linux.vnet.ibm.com>
* fast-reboot: factor out the mambo sreset codeNicholas Piggin2017-12-031-26/+62
| | | | | | | Move the mambo sreset code out from the P8 implementation. Signed-off-by: Nicholas Piggin <npiggin@gmail.com> Signed-off-by: Stewart Smith <stewart@linux.vnet.ibm.com>
* fast-reboot: clean up some common cpu iteration processes with macrosNicholas Piggin2017-12-033-46/+49
| | | | | Signed-off-by: Nicholas Piggin <npiggin@gmail.com> Signed-off-by: Stewart Smith <stewart@linux.vnet.ibm.com>
* fast-reboot: remove last man standing logicNicholas Piggin2017-12-031-22/+1
| | | | | | | | | | | The "last man standing" logic has the initiator CPU sreset all others, then one of them sresets the initiator. This complicates the fast reboot process and increases potential for errors. The initiator can simply branch to 0x100 directly. Signed-off-by: Nicholas Piggin <npiggin@gmail.com> Signed-off-by: Stewart Smith <stewart@linux.vnet.ibm.com>
* fast-reboot: factor out direct control loops for sresetNicholas Piggin2017-12-031-21/+58
| | | | | | | | This provides a simple API that is amenable to be implemented by the direct-controls subsystem in a future change. Signed-off-by: Nicholas Piggin <npiggin@gmail.com> Signed-off-by: Stewart Smith <stewart@linux.vnet.ibm.com>
* fast-reboot: restore SMT priority on spin loop exitNicholas Piggin2017-12-031-0/+1
| | | | | Signed-off-by: Nicholas Piggin <npiggin@gmail.com> Signed-off-by: Stewart Smith <stewart@linux.vnet.ibm.com>
* external/pflash: Fix non-zero return code for successful read when size%256 != 0Suraj Jitindar Singh2017-12-011-1/+1
| | | | | | | | | | | | | | | | | | | | When performing a read the return value from pflash is non-zero, even for a successful read, when the size being read is not a multiple of 256. This is because do_read_file returns the value from the write system call which is then returned by pflash. When the size is a multiple of 256 we get lucky in that this wraps around back to zero. However for any other value the return code is size % 256. This means even when the operation is successful the return code will seem to reflect an error. Fix this by returning zero if the entire size was read correctly, otherwise return the corresponding error code. Fixes: e1cf130d ("external/pflash: Remove use of exit() and fix memory leaks") Reported-by: Pridhiviraj Paidipeddi <ppaidipe@linux.vnet.ibm.com> Signed-off-by: Suraj Jitindar Singh <sjitindarsingh@gmail.com> Reviewed-by: Cyril Bur <cyrilbur@gmail.com> Signed-off-by: Stewart Smith <stewart@linux.vnet.ibm.com>
* gard: Add testsOliver O'Halloran2017-12-0122-2/+148
| | | | | | | I hear Stewart likes these for some reason. Dunno why. Signed-off-by: Oliver O'Halloran <oohall@gmail.com> Signed-off-by: Stewart Smith <stewart@linux.vnet.ibm.com>
OpenPOWER on IntegriCloud