aboutsummaryrefslogtreecommitdiff
AgeCommit message (Collapse)AuthorFilesLines
2020-10-01secvar: overhaul secvar struct by removing static sized fieldsEric Richter3-97/+88
Originally, the secvar struct was intended to contain all the variable information seperate from the linked list/etc metadata, so that copying and serialization/deserialization could be handled by a single memcpy(). This is fragile, potentially compiler dependent, and doesn't account for endianness. Therefore, this patch removes the static allocation for key, now allocates a buffer for data, and completely removes the now unnecessary secvar_node struct. As a side effect, some of the secvar_util functionality has been tweaked where it makes sense. Most notably alloc_secvar now takes in an extra argument as it now has to allocate the key Signed-off-by: Eric Richter <erichte@linux.ibm.com> Signed-off-by: Oliver O'Halloran <oohall@gmail.com>
2020-10-01secvar_util: add new helper functionsEric Richter2-3/+65
This patch adds the following helper functions: - dealloc_secvar() - new_secvar() - copy_bank_list() dealloc_secvar() frees a whole secvar_node reference including its children allocations. This also updates the clear_bank_list() helper function to use this destructor. new_secvar() allocates a secvar_node, and fills it with data provided via arguments. copy_bank_list() creates a deep copy of a secvar bank list Signed-off-by: Eric Richter <erichte@linux.ibm.com> Signed-off-by: Oliver O'Halloran <oohall@gmail.com>
2020-10-01secvar: change backend hook interface to take in bank referencesNayna Jain2-8/+20
Previously, backends were implicitly expected to operate on global references to the variable and update banks. This patch changes the interface for this driver to instead take the banks in as an argument. This removes the implict dependency on these references, makes the design consistent with the storage driver, and also will simplify unit testing of these functions. Signed-off-by: Nayna Jain <nayna@linux.ibm.com> Signed-off-by: Eric Richter <erichte@linux.ibm.com> Signed-off-by: Oliver O'Halloran <oohall@gmail.com>
2020-10-01secvar_main: rework secvar_main error flow, make storage locking explicitEric Richter1-14/+67
This patch adjusts the behavior of secvar_main to actually halt the boot in some form if there is an issue initializing secure variables. The secvar storage driver contains the secure boot state, and therefore if that fails to initialize, we immediately need to halt the boot. For all other cases we enforce secure boot in the bootloader by setting the secure mode flag, but booting with an empty keyring (and thus, cannot verify a kexec image). Previously, the storage driver was expected to handle any locking procedures implicitly as part of the write operation. This patch uses the new lockdown hook which makes locking explicit and part of the secvar_main flow. The storage driver is now locked unconditionally when exiting secvar_main, and the lockdown() call should halt the boot if it encounters any sign of struggle. Signed-off-by: Eric Richter <erichte@linux.ibm.com> Signed-off-by: Oliver O'Halloran <oohall@gmail.com>
2020-10-01include/secvar.h: add .lockdown() hook to secvar storage driverEric Richter1-3/+4
Previously, it was implied that the storage driver would lock itself after performing a write action. As this behavior is not particularly clear when reviewing the main secvar flow, this action instead has been made explicit. Signed-off-by: Eric Richter <erichte@linux.ibm.com> Signed-off-by: Oliver O'Halloran <oohall@gmail.com>
2020-10-01libstb/secureboot: OS Secure Boot is enabled only if FW secureboot is enabledNayna Jain3-1/+7
OS Secure Boot establishes a chain of trust from firmware to the OS. However, OS Secure Boot can only be secure if the chain of trust beneath it - from hardware to firmware - has been established by Firmware Secure Boot. This patch ensures that OS Secure Boot is enabled only if Firmware Secure Boot is enabled. Signed-off-by: Nayna Jain <nayna@linux.ibm.com> Signed-off-by: Eric Richter <erichte@linux.ibm.com> Signed-off-by: Oliver O'Halloran <oohall@gmail.com>
2020-10-01libstb/secureboot: expose secureboot_enforce for later use in secvarEric Richter2-1/+2
This patch exposes the secureboot_enforce() function to unify any system-halting behavior enacted by either firmware or OS secure boot. Signed-off-by: Eric Richter <erichte@linux.ibm.com> Signed-off-by: Oliver O'Halloran <oohall@gmail.com>
2020-10-01libstb: Set TPM platform auth to random passwordRyan Grimm1-0/+1
Set in core/init.c before trustedboot_exit_boot_services. Signed-off-by: Ryan Grimm <grimm@linux.ibm.com> Signed-off-by: Mauro S. M. Rodrigues <maurosr@linux.vnet.ibm.com> Signed-off-by: Oliver O'Halloran <oohall@gmail.com>
2020-10-01libstb/tss: Remove old tss implementationMauro S. M. Rodrigues11-3730/+0
This is being removed in favor of using a standard TSS library which offers a more broad implementation that is required for the new necessities of trusted and secure boot. Signed-off-by: Mauro S. M. Rodrigues <maurosr@linux.vnet.ibm.com> Signed-off-by: Oliver O'Halloran <oohall@gmail.com>
2020-10-01libstb/tss2: Switch to new implementation of PCR Read/Extend and EventlogMauro S. M. Rodrigues7-68/+69
The new implementation of PCR_Read, PCR_Extend and Eventlog uses the recently introduced standard TSS library. Old TSS implementation will be removed in the following commit. Signed-off-by: Mauro S. M. Rodrigues <maurosr@linux.vnet.ibm.com> Signed-off-by: Oliver O'Halloran <oohall@gmail.com>
2020-10-01libstb/trustedboot: Introduce new eventlog implementationMauro S. M. Rodrigues2-0/+156
This new implementation uses the recently introduced standard TSS library, reducing maintenance burden in skiboot side. We have yet to switch over this new implementation and to remove the old one in future commits. Signed-off-by: Mauro S. M. Rodrigues <maurosr@linux.vnet.ibm.com> Signed-off-by: Oliver O'Halloran <oohall@gmail.com>
2020-10-01libstb/tss2: Add TSS wrapping functionsMauro S. M. Rodrigues2-0/+753
In this commit we add some fundamental TSS operations: - tss_nv_read_public - tss_nv_read - tss_nv_write - tss_nv_write_lock - tss_nv_define_space - tss_nv_undefine_space - tss_get_defined_nv_indices - tss_pcr_extend - tss_pcr_read - tss_get_random_number - tss_set_platform_auth Co-authored-by: Eric Richter <erichte@linux.ibm.com> Co-authored-by: Ryan Grimm <grimm@linux.ibm.com> Signed-off-by: Mauro S. M. Rodrigues <maurosr@linux.vnet.ibm.com> Signed-off-by: Mauro S. M. Rodrigues <maurosr@linux.vnet.ibm.com> Signed-off-by: Oliver O'Halloran <oohall@gmail.com>
2020-10-01TPM/TSS: Register TPM chip for further use within TSSMauro S. M. Rodrigues2-0/+2
TSS will know which device and transmit handler to use through this registration, and the equivalent unregistering process. Signed-off-by: Mauro S. M. Rodrigues <maurosr@linux.vnet.ibm.com> Signed-off-by: Oliver O'Halloran <oohall@gmail.com>
2020-10-01libstb/tss2: Add basic Build infrastructure for tss2Mauro S. M. Rodrigues5-1/+84
Co-authored-by: Eric Richter <erichte@linux.ibm.com> Signed-off-by: Mauro S. M. Rodrigues <maurosr@linux.vnet.ibm.com> Signed-off-by: Oliver O'Halloran <oohall@gmail.com>
2020-10-01libstb: remove old mbedtls filesEric Richter4-633/+0
Signed-off-by: Oliver O'Halloran <oohall@gmail.com>
2020-10-01crypto/mbedtls: enable/disable unnecessary features to shrink sizeEric Richter1-21/+22
Signed-off-by: Oliver O'Halloran <oohall@gmail.com>
2020-10-01crypto: add mbedtls build integration via git subtreeMauro S. M. Rodrigues3-1/+151
Secure variable support requires more crypto support than skiboot currently has. Since mbedtls' x509, etc implementations have rather tight dependencies which prevent easy cherry picking (unlike the existing sha512.c), it is easier to integrate and maintain the whole mbedtls library as a subtree. Authored-by: Eric Richter <erichte@linux.ibm.com> Signed-off-by: Eric Richter <erichte@linux.ibm.com> Signed-off-by: Mauro S. M. Rodrigues <maurosr@linux.vnet.ibm.com> Signed-off-by: Oliver O'Halloran <oohall@gmail.com>
2020-10-01Squashed 'libstb/tss2/ibmtpm20tss/utils/' content from commit fae1383d3dMauro S. M. Rodrigues758-0/+149568
git-subtree-dir: libstb/tss2/ibmtpm20tss/utils git-subtree-split: fae1383d3d859bacac1084fe822ce9f313e01f4e Signed-off-by: Oliver O'Halloran <oohall@gmail.com>
2020-10-01Squashed 'libstb/crypto/mbedtls/' content from commit 7a03e1cbf5Mauro S. M. Rodrigues985-0/+233953
git-subtree-dir: libstb/crypto/mbedtls git-subtree-split: 7a03e1cbf5569b5e4de32d8c42a3083175503804 Signed-off-by: Oliver O'Halloran <oohall@gmail.com>
2020-09-30external/mambo: Disable MEMORY_OVERFLOWMichael Ellerman1-0/+1
Mambo has a strange feature called MEMORY_OVERFLOW, enabled by default, which causes some accesses to non-existent memory addresses to transparently "create" memory. This can be confusing when debugging, eg: systemsim % mysim cpu 0 display spr pc 0xC0000000000246B8 systemsim % mysim memory display 0xC0000000000246B8 8 0x0000000000000000 Appears to show that the memory at pc (NIP) is currently zeroes. The astute observer will note that "mysim memory display" takes physical addresses, not effective addresses. So unless this machine has > 12XB of RAM, this access should have failed as there is no memory at that address. Turning MEMORY_OVERFLOW off gives us a much more sensible result: systemsim % mysim memory display 0xC0000000000246B8 8 Illegal Address 0xC0000000000246B8 It doesn't appear to have any effect on accesses done from Linux, with the setting enabled or disabled we still get a machine check for bad accesses in real mode: 0:mon> p $__mmu_off return value is 0x9000000030001003 0:mon> d c008000000000000 c008000000000000 [15447.242793] Disabling lock debugging due to kernel taint [15447.242824] MCE: CPU0: machine check (Severe) Host Real address Load/Store (foreign) [Not recovered] [15447.242868] MCE: CPU0: NIP: [c000000000103090] mread+0x90/0x190 [15447.242897] MCE: CPU0: Initiator CPU [15447.242918] MCE: CPU0: Hardware error [15447.242939] opal: Hardware platform error: Unrecoverable Machine Check exception [15447.242978] CPU: 0 PID: 18 Comm: kopald Tainted: G M 5.7.0-gcc-8.2.0-13354-gd475a86526b5-dirty #127 [15447.243022] NIP: c000000000103090 LR: c000000000103034 CTR: c0000000000c2050 [15447.243059] REGS: c0000000fffbfd70 TRAP: 0200 Tainted: G M (5.7.0-gcc-8.2.0-13354-gd475a86526b5-dirty) [15447.243101] MSR: 9000000000201003 <SF,HV,ME,RI,LE> CR: 28002224 XER: 20040000 [15447.243150] CFAR: c000000000029660 DAR: c008000000000000 DSISR: 00000008 IRQMASK: 3 [15447.243150] GPR00: 0000000028002224 c0000000f05074c0 c000000001775e00 0000000000000000 [15447.243150] GPR04: c0000000f0507768 0000000000000010 0000000000000010 c0000000f0507768 [15447.243150] GPR08: 0007ffff0faf8899 0000000000000000 c0000000f0507767 9000000030001003 [15447.243150] GPR12: 0000000031c10000 c000000001970000 c0000000f0507738 0000000000000000 [15447.243150] GPR16: 000000000000002e 0000000000000010 000000000000002e 0000000000000010 [15447.243150] GPR20: c000000000e563d0 c000000000ffcf88 c000000000fddf30 c008000000000000 [15447.243150] GPR24: c0000000f0507767 c000000000ffc678 0000000000000040 c0000000f0507878 [15447.243150] GPR28: c0000000f0507768 c0000000f0507768 0000000000000010 0000000000000000 [15447.243485] NIP [c000000000103090] mread+0x90/0x190 [15447.243514] LR [c000000000103034] mread+0x34/0x190 [15447.243538] Call Trace: [15447.243559] [c0000000f05074c0] [c0000000f0507510] 0xc0000000f0507510 (unreliable) [15447.243602] [c0000000f0507510] [c000000000107b48] xmon_core+0xd18/0x3a10 [15447.243640] [c0000000f0507850] [c00000000010a870] xmon+0x30/0x80 [15447.243677] [c0000000f05079f0] [c0000000001050d4] sysrq_handle_xmon+0xc4/0xd0 [15447.243720] [c0000000f0507a20] [c000000000882954] __handle_sysrq+0xd4/0x220 [15447.243758] [c0000000f0507ac0] [c00000000089db68] __hvc_poll+0x268/0x4b0 [15447.243796] [c0000000f0507b60] [c00000000089e824] hvc_handle_interrupt+0x24/0x70 [15447.243838] [c0000000f0507b80] [c0000000001c2474] __handle_irq_event_percpu+0xb4/0x350 [15447.243880] [c0000000f0507c50] [c0000000001c2754] handle_irq_event_percpu+0x44/0xc0 [15447.243923] [c0000000f0507c90] [c0000000001c2844] handle_irq_event+0x74/0xc0 [15447.243965] [c0000000f0507cc0] [c0000000001c9770] handle_level_irq+0xe0/0x1c0 [15447.244006] [c0000000f0507cf0] [c0000000001c0a44] generic_handle_irq+0x54/0x80 [15447.244046] [c0000000f0507d10] [c0000000000ca050] opal_handle_events+0x130/0x150 [15447.244088] [c0000000f0507d60] [c0000000000c1e7c] kopald+0x9c/0x140 [15447.244124] [c0000000f0507db0] [c00000000016ea9c] kthread+0x19c/0x1b0 [15447.244161] [c0000000f0507e20] [c00000000000d1a8] ret_from_kernel_thread+0x5c/0x74 Signed-off-by: Michael Ellerman <mpe@ellerman.id.au> Signed-off-by: Oliver O'Halloran <oohall@gmail.com>
2020-09-30opal-prd: Have a worker process handle page offliningOliver O'Halloran1-19/+64
The memory_error() hservice interface expects the memory_error() call to just accept the offline request and return without actually offlining the memory. Currently we will attempt to offline the marked pages before returning to HBRT which can result in an excessively long time spent in the memory_error() hservice call which blocks HBRT from processing other errors. Fix this by adding a worker process which performs the page offlining via the sysfs memory error interfaces. Reviewed-by: Vasant Hegde <hegdevasant@linux.vnet.ibm.com> Signed-off-by: Oliver O'Halloran <oohall@gmail.com>
2020-09-29platform/mowgli: Add mowgli.cLuluTHSu2-1/+65
This is the initial version. Cc: skiboot-stable@lists.ozlabs.org Cc: skiboot-stable@lists.ozlabs.org # skiboot-op940.x Signed-off-by: LuluTHSu <Lulu_Su@wistron.com> Reviewed-by: Dan Horák <dan@danny.cz> [oliver: fixed up whitepace errors] Signed-off-by: Oliver O'Halloran <oohall@gmail.com>
2020-09-29external/mambo Update SIM_CTRL1Anton Blanchard1-1/+1
The configuration of SIM_CTRL1 doesn't match POWER9 in a number of ways, including missing vslv, vsrv, addex and xsmax*/xsmin*/xscmp* instructions. Signed-off-by: Anton Blanchard <anton@ozlabs.org> Signed-off-by: Oliver O'Halloran <oohall@gmail.com>
2020-09-29asm/head: fix power save wakeup register corruptionNicholas Piggin1-4/+4
Power save wakeup handlers can clobber r30 before testing for state loss and avoiding restoring non-volatile GPRs. Fix this by using r5 instead (and move the register usage to one place, for clarity). Cc: skiboot-stable@lists.ozlabs.org Fixes: 8a43bf86b7 ("core/exceptions: implement an exception handler for non-powersave sresets") Signed-off-by: Nicholas Piggin <npiggin@gmail.com> Signed-off-by: Oliver O'Halloran <oohall@gmail.com>
2020-09-10skiboot v6.6.3 release notesVasant Hegde1-0/+21
Signed-off-by: Vasant Hegde <hegdevasant@linux.vnet.ibm.com> Signed-off-by: Oliver O'Halloran <oohall@gmail.com>
2020-09-09stack: only print stack usage backtraces when we hit a new watermarkOliver O'Halloran1-4/+4
With DEBUG=1 builds we use the mcount hook to instrument how much stack space we're using. If we detect that a function call has come within 2KB of the bottom of the stack we currently print a backtrace. This can result in a huge amount of console IO in DEBUG=1 builds which can cause op-test timeouts, etc. Printing a backtrace on each function call isn't terribly useful, and it ends up crowding out the backtrace that's printed when we hit a new stack usage watermark. The watermark should provide enough information to find and fix excessive stack usage issues so drop the per-function backtrace printing and move the warning into the high-watermark check. This change is largely necessary because of DEBUG=1 expands adds a backtrace save area to struct lock which expands the size of it to nearly 2KB. struct cpu_thread (which lives at the bottom of the per-thread stacks) contains three locks and an additional backtrace save area which is enabled when DEBUG=1. The extra space requirements result in cpu_thread ballooning from ~420 bytes to nearly 8KB. Any growth in cpu_thread also results in less stack space being available for the thread, so when DEBUG=1 is enabled we go from having a 16KB stack to an 8KB stack. Although this seems large, skiboot does have some fairly deep call chains (UART console flushing, TPM drivers, both combined) which can cause the thread to come within 2KB of the stack use warning zone. Signed-off-by: Oliver O'Halloran <oohall@gmail.com> --- Maybe we should swap locations of the normal and emergency stacks so cpu_thread takes space from the emergency stack rather than the normal one. The e-stack should only be used at runtime where the call chains should be smaller.
2020-08-28fsp/dump: Handle non-MPIPL scenarioVasant Hegde1-4/+4
If MPIPL is not enabled then we will not create `/ibm,opal/dump` node and we should continue to parse/retrieve SYSDUMP. I missed this scenario when I fixed similar issue last time :-( Fixes: 92b7968 (fsp: Skip sysdump retrieval only in MPIPL boot) Signed-off-by: Vasant Hegde <hegdevasant@linux.vnet.ibm.com> Signed-off-by: Oliver O'Halloran <oohall@gmail.com>
2020-08-28external/mambo: Do not enable TM on P9 in ibm, pa-featuresJordan Niethe1-1/+1
Bytes 22-23 Bit 0 in ibm,pa-features indicate TM support. None of the pa_features_p9*[] in hdata/cpu-common.c set this bit so do not set it in the ibm,pa-features made for mambo either. Signed-off-by: Jordan Niethe <jniethe5@gmail.com> Signed-off-by: Oliver O'Halloran <oohall@gmail.com>
2020-08-28external/ffspart: define $(sbindir) for MakefileDan Horák1-0/+3
Right now the $(sbindir) variable isn't defined, so the binary gets installed directly into $(DESTDIR). Signed-off-by: Dan Horák <dan@danny.cz> Signed-off-by: Oliver O'Halloran <oohall@gmail.com>
2020-08-28hw/phb4: Verify AER support before initialising AER regsOliver O'Halloran1-0/+3
Check the AER capability offset pointer is non-zero before enabling the AER messages. If the device doesn't support AER we end up writing garbage to config offset 0x0 + PCIECAP_AER_CAPCTL, or 0x18. For a normal device this is one of the BARs so this doesn't do much, but for a bridge this results in overriding: 0x18 - The primary bus number 0x19 - The secondary bus number 0x1A - The subordinate bus number 0x1B - The latency timer 0x1B is hardwired to zero for PCIe devices, but overwriting the bus number register can cause issues with routing of config space accesses. It's worth pointing out that we write actual values for the secondary and subordinate bus numbers before scanning the secondary bus, but the primary bus number is never restored. Cc: skiboot-stable@lists.ozlabs.org Signed-off-by: Oliver O'Halloran <oohall@gmail.com>
2020-08-28hw/phb4: Actually enable error reportingOliver O'Halloran1-0/+1
PHB3 had an errata about correctable errors and when Ben was doing the initial PHB4 port he deleted the corresponding config write to DEVCTL. Whoops. Cc: skiboot-stable@lists.ozlabs.org Signed-off-by: Oliver O'Halloran <oohall@gmail.com>
2020-08-07Enable fused core mode support in OPALVaidyanathan Srinivasan1-4/+0
Previous commit 482f18adf21eeb5f6ce2a93334725509a8f6f0cd added check for fused core mode and bailed out. The check can be removed since fused core mode is now supported in OPAL. Signed-off-by: Vaidyanathan Srinivasan <svaidy@linux.ibm.com> Signed-off-by: Oliver O'Halloran <oohall@gmail.com>
2020-08-07Add POWER9 Fleetwood platform supportVaidyanathan Srinivasan1-0/+4
The system is larger than ZZ and uses P9 Cumulus chip. However the interactions with host is via FSP and FSP mailbox which are identical to a ZZ platform. Add the DT string and detect as ZZ to avoid creating a nearly identical FSP based platform. Signed-off-by: Vaidyanathan Srinivasan <svaidy@linux.ibm.com> Signed-off-by: Vasant Hegde <hegdevasant@linux.vnet.ibm.com> Signed-off-by: Oliver O'Halloran <oohall@gmail.com>
2020-08-07Add POWER9 Cumulus processor PVR typeVaidyanathan Srinivasan2-0/+34
Add PVR checks and feature mapping for POWER9 Cumulus chip. Signed-off-by: Vaidyanathan Srinivasan <svaidy@linux.ibm.com> Signed-off-by: Vasant Hegde <hegdevasant@linux.vnet.ibm.com> Signed-off-by: Oliver O'Halloran <oohall@gmail.com>
2020-08-07imc: Use pir_to_core_id() rather than cpu_get_core_index()Benjamin Herrenschmidt1-4/+4
The IMC HW targets HW ECs, not fused cores on P9 Signed-off-by: Benjamin Herrenschmidt <benh@kernel.crashing.org> Signed-off-by: Michael Neuling <mikey@neuling.org> Signed-off-by: Vaidyanathan Srinivasan <svaidy@linux.ibm.com> Signed-off-by: Oliver O'Halloran <oohall@gmail.com>
2020-08-07cpu: Make cpu_get_core_index() return the fused core numberBenjamin Herrenschmidt4-1/+25
cpu_get_core_index() currently uses pir_to_core_id() which returns an EC number always (ie, a normal core number) even in fused core mode. This is inconsistent with cpu_get_thread_index() which returns a thread within a fused core (0...7) on P9. So let's make things consistent and document it. Signed-off-by: Benjamin Herrenschmidt <benh@kernel.crashing.org> Signed-off-by: Michael Neuling <mikey@neuling.org> Signed-off-by: Vaidyanathan Srinivasan <svaidy@linux.ibm.com> Signed-off-by: Oliver O'Halloran <oohall@gmail.com>
2020-08-07slw: Limit fused cores P9 to STOP0/1/2Benjamin Herrenschmidt1-1/+81
FROM: Benjamin Herrenschmidt <benh@kernel.crashing.org> Linux doesn't know how to properly restore state on "both halves" of a fused core, so limit ourselves to STOP states that don't require HV state restore for bare metal kernels (KVM is still broken) until we add a new representation for STOP states. The new representation will have per-state versioning so that we can control their individual enablement based on whether the OS has the necessary workarounds to make them work. Signed-off-by: Benjamin Herrenschmidt <benh@kernel.crashing.org> Signed-off-by: Michael Neuling <mikey@neuling.org> Signed-off-by: Vaidyanathan Srinivasan <svaidy@linux.vnet.ibm.com> Signed-off-by: Oliver O'Halloran <oohall@gmail.com>
2020-08-07direct-ctl: Use the EC primary for special wakeupsBenjamin Herrenschmidt1-4/+4
Signed-off-by: Benjamin Herrenschmidt <benh@kernel.crashing.org> Signed-off-by: Michael Neuling <mikey@neuling.org> Signed-off-by: Vaidyanathan Srinivasan <svaidy@linux.ibm.com> Signed-off-by: Oliver O'Halloran <oohall@gmail.com>
2020-08-07cpu: Keep track of the "ec_primary" in big core moreBenjamin Herrenschmidt2-6/+15
The "EC" primary is the primary thread of an EC, ie, the corresponding small core "half" of the big core where the thread resides. It will be necessary for the direct controls to target the right half when doing special wakeups among others. Signed-off-by: Benjamin Herrenschmidt <benh@kernel.crashing.org> Signed-off-by: Michael Neuling <mikey@neuling.org> Signed-off-by: Vaidyanathan Srinivasan <svaidy@linux.ibm.com> Signed-off-by: Oliver O'Halloran <oohall@gmail.com>
2020-08-07chip: Fix pir_to_thread_id for fused coresBenjamin Herrenschmidt2-1/+8
pir_to_core_id() and pir_to_thread_id() are extensively used by the direct controls code and are expected to return the "normal" (non-fused, aka EC) core/thread IDs. Signed-off-by: Benjamin Herrenschmidt <benh@kernel.crashing.org> Signed-off-by: Michael Neuling <mikey@neuling.org> Signed-off-by: Vaidyanathan Srinivasan <svaidy@linux.ibm.com> Signed-off-by: Oliver O'Halloran <oohall@gmail.com>
2020-08-07xive: Set the fused core mode properlyBenjamin Herrenschmidt2-0/+5
Set or clear the fused core mode bit in the XIVE inits properly. While HostBoot is supposed to do it, I prefer not depending on it doing the right thing, since we already configure that register ourselves anyway. Signed-off-by: Benjamin Herrenschmidt <benh@kernel.crashing.org> Signed-off-by: Michael Neuling <mikey@neuling.org> Signed-off-by: Vaidyanathan Srinivasan <svaidy@linux.ibm.com> Signed-off-by: Oliver O'Halloran <oohall@gmail.com>
2020-08-07Add basic P9 fused core supportRyan Grimm8-16/+110
P9 cores can be configured into fused core mode where two core chiplets function as an 8-threaded, single core. So, bump four to eight in boot_entry when in fused core mode and cpu_thread_count in init_boot_cpu. The HID, AMOR, TSCR, RPR require the first active thread on that core chiplet to load the copy for that core chiplet. So, send thread 1 of a fused core to init_shared_sprs in boot_entry. The code checks for fused core mode in the core thead state register and puts a field in struct cpu_thread. This flag is checked when updating the HID and in XIVE code when setting the special bar. For XSCOM, the core ID is the non-fused EX. So, create macros to arrange the bits. It's fairly verbose but somewhat readable. This was tested on a P9 ZZ with 16 fused cores and ran HTX for over 24 hours. Signed-off-by: Ryan Grimm <grimm@linux.vnet.ibm.com> Signed-off-by: Benjamin Herrenschmidt <benh@kernel.crashing.org> Signed-off-by: Michael Neuling <mikey@neuling.org> Signed-off-by: Vaidyanathan Srinivasan <svaidy@linux.ibm.com> Signed-off-by: Oliver O'Halloran <oohall@gmail.com>
2020-08-07xive/p9: Enforce thread enablement before TIMA accessesCédric Le Goater1-0/+15
To activate the HW thread context ring, and its associated thread interrupt registers, a thread needs to raise the VT bit in word2. This requires access to the TIMA and this access is only granted if the thread was first enabled at the XIVE IC level. This is done in a sequence in xive_cpu_callin() but there is a chance that the accesses done on the TIMA do not see the update of the enable register. To make sure that the enablement has completed, add an extra load on the PC_THREAD_EN_REGx register. This guarantees that the TIMA accesses will see the latest state of the enable register. Signed-off-by: Cédric Le Goater <clg@kaod.org> Signed-off-by: Oliver O'Halloran <oohall@gmail.com>
2020-08-07doc: Document more platformsJoel Stanley1-1/+4
These platforms are supported in the tree but didn't make it to the docs folder yet. Signed-off-by: Joel Stanley <joel@jms.id.au> Signed-off-by: Oliver O'Halloran <oohall@gmail.com>
2020-08-07Fix typos in commentGustavo Romero1-2/+2
Fix two typos in comment describing a member of 'platform' struct. Signed-off-by: Gustavo Romero <gromero@linux.ibm.com> Signed-off-by: Oliver O'Halloran <oohall@gmail.com>
2020-08-07hdata: Add new "smp-cable-connector" VPD keywordKlaus Heinrich Kiwi1-0/+1
Recent FSP versions are defining a new VPD keyword 'SN' that brings SMP Cable Connector FRU info. Signed-off-by: Klaus Heinrich Kiwi <klaus@linux.vnet.ibm.com> Reviewed-by: Vasant Hegde <hegdevasant@linux.vnet.ibm.com> Signed-off-by: Oliver O'Halloran <oohall@gmail.com>
2020-08-07Update comments for bit manipulation macrosGustavo Romero1-3/+3
Bit manipulation code was updated but comments related to it were not. This commit updates the comments for the main macros, GET/SETFIELD, to make them match the code. Signed-off-by: Gustavo Romero <gromero@linux.ibm.com> Signed-off-by: Oliver O'Halloran <oohall@gmail.com>
2020-08-07xive: Fix typos in commentsGustavo Romero1-2/+2
Fix a typo in comment about Presentation Controller Base Address Register and another typo about code to configure the queue overflows. Signed-off-by: Gustavo Romero <gromero@linux.ibm.com> Reviewed-by: Cédric Le Goater <clg@kaod.org> Signed-off-by: Oliver O'Halloran <oohall@gmail.com>
2020-08-07hw/psi-p9: Configure IRQ offset before XIVE notifyOliver O'Halloran1-10/+10
When configuring the XIVE notification address any currently pending interrupts will be delivered once the the valid bit in the BAR is set. Currently we enable the notify BAR before we've configured the global interrupt number offset for the PSI interrupts. If any PSI interrupt is pending at this point we'll send an interrupt trigger notification for the wrong interrupt vector. This can potentially cause a checkstop since there may not be an EAS / IVT configure for that vector. Fix this by fixing the ordering so we setup the offset before the XIVE notification address. Cc: Cédric Le Goater <clg@kaod.org> Signed-off-by: Oliver O'Halloran <oohall@gmail.com> Reviewed-by: Cédric Le Goater <clg@kaod.org> Signed-off-by: Oliver O'Halloran <oohall@gmail.com>
2020-08-07hdata: Ensure the prd-label hbrt-code-image is prefixedOliver O'Halloran1-0/+9
Older versions of opal-prd (i.e. most of them shipped by distros) expect the HBRT image to have the PRD label of "ibm,hbrt-code-image". Commit c3bfa3209559 ("hdata: Fix reserved node label search") made opal-prd check for both strings, but since opal-prd itself is the only component interested in locating the hbrt-code-image we might as well just add the prefix in firmware. Cc: Vasant Hegde <hegdevasant@linux.vnet.ibm.com> Signed-off-by: Oliver O'Halloran <oohall@gmail.com>