Age | Commit message (Collapse) | Author | Files | Lines |
|
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>
|
|
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>
|
|
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>
|
|
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>
|
|
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>
|
|
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>
|
|
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>
|
|
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>
|
|
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>
|
|
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>
|
|
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>
|
|
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>
|
|
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>
|
|
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>
|
|
Signed-off-by: Oliver O'Halloran <oohall@gmail.com>
|
|
Signed-off-by: Oliver O'Halloran <oohall@gmail.com>
|
|
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>
|
|
git-subtree-dir: libstb/tss2/ibmtpm20tss/utils
git-subtree-split: fae1383d3d859bacac1084fe822ce9f313e01f4e
Signed-off-by: Oliver O'Halloran <oohall@gmail.com>
|
|
git-subtree-dir: libstb/crypto/mbedtls
git-subtree-split: 7a03e1cbf5569b5e4de32d8c42a3083175503804
Signed-off-by: Oliver O'Halloran <oohall@gmail.com>
|
|
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>
|
|
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>
|
|
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>
|
|
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>
|
|
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>
|
|
Signed-off-by: Vasant Hegde <hegdevasant@linux.vnet.ibm.com>
Signed-off-by: Oliver O'Halloran <oohall@gmail.com>
|
|
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.
|
|
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>
|
|
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>
|
|
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>
|
|
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>
|
|
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>
|
|
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>
|
|
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>
|
|
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>
|
|
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>
|
|
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>
|
|
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>
|
|
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>
|
|
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>
|
|
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>
|
|
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>
|
|
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>
|
|
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>
|
|
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>
|
|
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>
|
|
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>
|
|
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>
|
|
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>
|
|
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>
|
|
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>
|