| Commit message (Collapse) | Author | Age | Files | Lines |
... | |
|
|
|
|
|
|
|
|
| |
Implement a fake NVRAM device based on arbitrary memory reserves.
This allows NVRAM images to be preloaded without the FSP.
Signed-off-by: Jack Miller <jack@codezen.org>
Tested-by: Chris Smart <chris@distroguy.com>
Signed-off-by: Stewart Smith <stewart@linux.vnet.ibm.com>
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Currently, we are hijacking the last bit of the resource field of the
sensor handler to differentiate the sensor families and route the
opal_sensor_read() call to the appropriate component.
Let's reserve the last 3bits and provide an API to set the sensor
family for current use and future use. This gives us a maximum of 8
families and 32 resource classes. The FSP uses 15, so we should be
fine for a while.
Signed-off-by: Cédric Le Goater <clg@kaod.org>
Signed-off-by: Stewart Smith <stewart@linux.vnet.ibm.com>
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
In TPM 2.0 Firmware 1.3.0.1 and 1.3.1.0 (at least) there exists
a bug where if you send the wrong thing to the TPM it may lock the
bus, with no way of recovery except powering the TPM off/on.
On our current systems, the only way to power the TPM off/on is to pull
the power on the system (*NOT* just power off/on to host from BMC).
So, this patch adds the ability to do things to the i2c request really
early on, well before it hits any hardware, such as quickly drop it.
Signed-off-by: Stewart Smith <stewart@linux.vnet.ibm.com>
|
|
|
|
|
|
|
|
|
|
|
|
| |
In some error conditions, we could spiral out of control on this
and spend all of our time printing the exact same backtrace.
Limit it to 16 times, because 16 is a nice number.
Cc: stable
Signed-off-by: Stewart Smith <stewart@linux.vnet.ibm.com>
Reviewed-by: Vasant Hegde <hegdevasant@linux.vnet.ibm.com>
Signed-off-by: Stewart Smith <stewart@linux.vnet.ibm.com>
|
|
|
|
|
|
|
|
|
|
| |
We would needlessly time_wait_ms_nopoll(5) if opal_run_pollers()
managed to crank things enough to load the requested resource.
Instead of needlessly sleeping, check the result of resource_loaded()
*before* going to sleep for a bit.
Signed-off-by: Stewart Smith <stewart@linux.vnet.ibm.com>
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
In the event we only have 1 CPU thread, we run asynchronous jobs
synchronously, and while we wait for them to finish, we run pollers.
However, if the jobs themselves don't call pollers (e.g. by time_wait())
then we'll end up in long periods of not running pollers at all.
To work around this, explicitly run pollers when we're the only
CPU thread (i.e. when we run the job synchronously).
Signed-off-by: Stewart Smith <stewart@linux.vnet.ibm.com>
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Some devices such as NX or the NPU will use some of the XIVE
provided IPIs for their own interrupts. Thus we need a way for
those to provide a custom irq_source_ops for portions of the IPI
space in order for them to provide their own attributes() and
if needed, interrutps() callbacks.
We achieve that by creating a second list of sources which can
overlap the primary.
The global stock of IPIs is registered by XIVE in the secondary
list which is searched when no match is found in the primary.
A new API xive_register_ipi_source() is provided for those devices
to create an overlapping source structure in the primary list for
a subset of the IPIs. Those IPIs must have been previously allocated
using xive_alloc_ipi_irqs()
Signed-off-by: Benjamin Herrenschmidt <benh@kernel.crashing.org>
Signed-off-by: Stewart Smith <stewart@linux.vnet.ibm.com>
|
|
|
|
|
|
|
| |
We don't support it yet on others.
Signed-off-by: Benjamin Herrenschmidt <benh@kernel.crashing.org>
Signed-off-by: Stewart Smith <stewart@linux.vnet.ibm.com>
|
|
|
|
|
|
|
|
|
|
|
|
| |
At the moment the generic platform initializes the UART really late,
which make debugging harder than it needs to be. Most platforms set
it up in their probe() callback but the generic platform doesn't have
one.
This adds one and initializes the UART in it.
Signed-off-by: Benjamin Herrenschmidt <benh@kernel.crashing.org>
Signed-off-by: Stewart Smith <stewart@linux.vnet.ibm.com>
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
This reverts commit d997e482705d9fdff8e25fcbe07fb56008f96ae1.
A problem was found with pre 4.2 linux kernels where a spurious WARNING
would be emitted. This change doesn't matter enough to scare users
so we can just revert it.
Warning was:
[ 0.947741] irq: irq-62==>hwirq-0x3e mapping failed: -22
[ 0.947793] ------------[ cut here ]------------
[ 0.947838] WARNING: at kernel/irq/irqdomain.c:485
Reported-by: Pridhiviraj Paidipeddi <ppaidipe@in.ibm.com>
Acked-By: Alistair Popple <alistair@popple.id.au>
Signed-off-by: Stewart Smith <stewart@linux.vnet.ibm.com>
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
An out of tree platform (p8dtu) uses a different IPMI OEM command
for IPMI_PARTIAL_ADD_ESEL. This exposed some assumptions about the BMC
implementation in our core code.
Now, with platform.bmc, each platform can dictate (or detect) the BMC
that is present. We allow it to be set at runtime rather than purely
statically in struct platform as it's possible to have differing BMC
implementations on the one machine (e.g. AMI BMC or OpenBMC).
Acked-by: Jeremy Kerr <jk@ozlabs.org>
[stewart@linux.vnet.ibm.com: remove enum, update (C) years]
Signed-off-by: Stewart Smith <stewart@linux.vnet.ibm.com>
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
The criteria to match the filter according to PCI config register
offset and length is strict one, meaning the accessed region should
matches with the filter's tracking region. However, the code isn't
correct enough - @len should be replaced with @pcrf->len.
The strict matching has to account for the length of current PCI
config register access. We have to specify precise region through
@start and @len in pci_virt_add_filter() when creating the filter.
We lost flexibility. This changes the strict criteria to a relaxed
one - the matched filter is returned when the accessed region is
overlapped with the filter's region. With this change, the individual
filter's handlers should validate the accessed (register) region if
necessary.
Fixes: 85daa7f00c50 ("core/pci: Support virtual device")
Signed-off-by: Gavin Shan <gwshan@linux.vnet.ibm.com>
Reviewed-by: Alistair Popple <alistair@popple.id.au>
Acked-by: Alistair Popple <alistair@popple.id.au>
Signed-off-by: Stewart Smith <stewart@linux.vnet.ibm.com>
|
|
|
|
|
|
|
|
| |
Also changes the function name:
mambo_read/write() -> mambo_console_read/write()
Signed-off-by: Michael Neuling <mikey@neuling.org>
Signed-off-by: Stewart Smith <stewart@linux.vnet.ibm.com>
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
These OPAL calls are exposing the host flash chip to linux as a flash
device. The host is expected to understand that it is raw flash and use
it appropriately, it isn't skiboots place to strip ecc bytes or perform
erase before writes.
Over the course of other developments blocklevel has gotten quite clever
but in this case the cleverness is inappropriate.
Fixes: https://github.com/open-power/skiboot/issues/44
Signed-off-by: Cyril Bur <cyril.bur@au1.ibm.com>
Signed-off-by: Stewart Smith <stewart@linux.vnet.ibm.com>
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
In the fast reboot path opal sends multiple special sequence to all the
CPUs using xscom operations. On freshly booted system where all CPUs are
in good condition, the fast reboot works fine. But fast reboot fails when
any of the COREs are GARDed by Service processor. This is because xscom
operations fails/timeout on the CPUs/COREs that are GARDed. Fix this issue
by skipping GARDed CPUs during fast reboot path.
The GARDed CPUs are presented as 'bad' to OPAL and OPAL marks that
cpu->state as 'cpu_state_unavailable'. This patch checks the cpu state
to skip GARDed CPUs during fast reboot.
Signed-off-by: Mahesh Salgaonkar <mahesh@linux.vnet.ibm.com>
Signed-off-by: Stewart Smith <stewart@linux.vnet.ibm.com>
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Resource loading uses the flash calls directly which works on hardware
as the blocklevel abstraction was initialised with a flash structure. On
platforms such as mambo the blocklevel abstraction was initialised with
the bogusdisk structure so calling the flash calls directly results in
following uninitialised function pointers off into lala land.
Functionality is preserved as the blocklevel is told if a flash
partition is ECC protected during the call to ffs_init().
Signed-off-by: Cyril Bur <cyril.bur@au1.ibm.com>
Signed-off-by: Stewart Smith <stewart@linux.vnet.ibm.com>
|
|
|
|
|
|
|
|
|
|
|
|
| |
We always verify and measure an image as a whole, never its subpartition
(if exists).
This removes the subid argument from sb_verify() and tb_measure()
functions, and also reflects the change to the callers, STB interface
and STB documentation.
Signed-off-by: Claudio Carvalho <cclaudio@linux.vnet.ibm.com>
Signed-off-by: Stewart Smith <stewart@linux.vnet.ibm.com>
|
|
|
|
|
|
|
|
| |
This just do some line breaking in the flash_load_resource() function.
Signed-off-by: Claudio Carvalho <cclaudio@linux.vnet.ibm.com>
[stewart@linux.vnet.ibm.com: reword commit message]
Signed-off-by: Stewart Smith <stewart@linux.vnet.ibm.com>
|
|
|
|
|
|
|
| |
This removes the toc var. It is allocated in the function, but not used.
Signed-off-by: Claudio Carvalho <cclaudio@linux.vnet.ibm.com>
Signed-off-by: Stewart Smith <stewart@linux.vnet.ibm.com>
|
|
|
|
| |
Signed-off-by: Stewart Smith <stewart@linux.vnet.ibm.com>
|
|
|
|
|
|
|
|
|
| |
In flash_subpart_info, part_actual can't be NULL (we bail out if so),
so this spurious check just manages to trigger warning in static
analysis.
Fixes: 8652ced003f7977e1126149b8011c184b88fe24e
Signed-off-by: Stewart Smith <stewart@linux.vnet.ibm.com>
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
For this stage in Trusted Boot development, we are wishing to not
force Secure Mode through the whole firmware boot process, but we
are wanting to be able to test it (classic chicken and egg problem with
build infrastructure).
We disabled secure mode if the secure-enabled devtree property is
read from the device tree *IF* we aren't overriding it through NVRAM.
Seeing as we can only increase (not decrease) what we're checking through
the NVRAM variable, it is safe.
The NVRAM setting is force-secure-mode=true in the ibm,skiboot partition.
However, if you want to force secure mode even if Hostboot has *not* set
the secure-enabled proprety in the device tree, set force-secure-mode
to "always".
There is also a force-trusted-mode NVRAM setting to force trusted mode
even if Hostboot has not enabled it int the device tree.
To indicate to Linux that we haven't gone through the whole firmware
process in secure mode, we replace the 'secure-enabled' property with
'partial-secure-enabled', to indicate that only part of the firmware
boot process has gone through secure mode.
Signed-off-by: Claudio Carvalho <cclaudio@linux.vnet.ibm.com>
[stewart@linux.vnet.ibm.com: add NVRAM flag, modify commit message]
Signed-off-by: Stewart Smith <stewart@linux.vnet.ibm.com>
|
|
|
|
|
|
|
|
| |
Some modifications related to typo errors, alignment, case letter mismatch to add
more clarity to the code.
Signed-off-by: Mukesh Ojha <mukesh02@linux.vnet.ibm.com>
Signed-off-by: Stewart Smith <stewart@linux.vnet.ibm.com>
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Currently the bootargs are unconditionally deleted, which causes
a bug where the bootargs passed in by the device tree are lost.
This patch deletes bootargs only if it needs to be replaced by the NVRAM
entry.
This patch also removes KERNEL_COMMAND_LINE config option in favour of
using the NVRAM or a device tree.
Signed-off-by: Chris Smart <chris@distroguy.com>
Acked-by: Balbir Singh <bsingharora@gmail.com>
Signed-off-by: Stewart Smith <stewart@linux.vnet.ibm.com>
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Most of the time, if we're rebooting due to a platform error, we should
trigger a checkstop. However, if we haven't been told what we should do
to trigger a checkstop (e.g. on an FSP machine), then we should still
fail to fast-reboot.
So, disable fast-reboot in the OPAL_CEC_REBOOT2 code path
for OPAL_REBOOT_PLATFORM_ERROR reboot type.
We don't save the reason for the platform error as that's already
been error logged.
Signed-off-by: Stewart Smith <stewart@linux.vnet.ibm.com>
|
|
|
|
|
|
|
|
| |
Signed-off-by: Stewart Smith <stewart@linux.vnet.ibm.com>
Reviewed-by: Andrew Donnellan <andrew.donnellan@au1.ibm.com>
[stewart@linux.vnet.ibm.com: unlock before return (suggested by Mahesh/Andrew),
disable only on non-cancelling fsp codeupdate call (suggested by Vasant)]
Signed-off-by: Stewart Smith <stewart@linux.vnet.ibm.com>
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
This fixes the previous reverts of loading the CAPP partition with
STB headers (which broke CAPP partitions without STB headers).
The new logic fixes both CAPP partition loading with STB headers *and*
addresses a long standing bug due to differing interpretations of FFS.
The f_part utility that *constructs* PNOR files just sets actualSize=totalSize
no matter on what the size of the partition is. Prior to this patch,
skiboot would always load actualSize, leading to longer than needed IPL.
The pflash utility updates actualSize, so no developer has really ever
noticed this, apart from maybe an inkling that it's odd that a freshly
baked PNOR from op-build takes ever so slightly longer to boot than one
that has had individual partitions pflashed in.
With this patch, we now compute actualSize. For partitions with a STB
header, we take the payload size from the STB header. For partitions
that don't have a STB header, we compute the size either by parsing
the ELF header or by looking at the subpartition header and computing it.
We now need to read the entire partition for partitions with subpartitions
so that we pass consistent values to be measured as part of Trusted Boot.
As of this patch, the actualSize field in FFS is *not* relied on for
partition size, we determine it from the content of the partition.
However, this patch *will* break loading of partitions that are not ELF
and do not contain subpartitions. Luckily, nothing in-tree makes use of
that.
Fixes: f0a23e4fadcdc49f134e122fa134f183f2e172f7
Based-on-patch-by: Claudio Carvalho <cclaudio@linux.vnet.ibm.com>
Signed-off-by: Stewart Smith <stewart@linux.vnet.ibm.com>
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
From the subpartition structure, we have the ability to compute
the full partition size. Do that.
This lets us only read the amount of a subpartition that is valid
and needed to be read, rather than having to read the entire thing.
We continue the current behaviour of loading flash partitions though.
Based-on-patch-by: Claudio Carvalho <cclaudio@linux.vnet.ibm.com>
Signed-off-by: Stewart Smith <stewart@linux.vnet.ibm.com>
|
|
|
|
|
|
|
|
|
|
| |
A unit test for parsing sub-partition info is useful for a number
of reasons, one of which showed its head during development of
secure/trusted boot.
This patch just moves things around, there's no functional changes.
Signed-off-by: Stewart Smith <stewart@linux.vnet.ibm.com>
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
I made the inappropriate assumption: PCI slot's power state is
always on from the beginning. We don't check the slot's power
state before turning it off in PCI enumeration path when there
are no PCI adapters behind the slot. The PCI slot's power might
have been turned off and we needn't power it off again. Otherwise,
the below (not harmful) message is raised:
[ 47.243635711,5] SkiBoot skiboot-5.4.0-rc1 starting...
:
[ 13.239871630,5] PHB#0001:02:01.0 Error -1 powering off slot
This checks power state and avoid turning it off again if it's
already in off state. Flag PCI_SLOT_FLAG_BOOTUP is also removed
after the requested operation is completed as the flag should
be used at skiboot booting stage.
Cc: stable # 5.3.0+
Reported-by: Pridhiviraj Paidipeddi <ppaidipe@linux.vnet.ibm.com>
Signed-off-by: Gavin Shan <gwshan@linux.vnet.ibm.com>
Tested-by: Pridhiviraj Paidipeddi <ppaidipe@linux.vnet.ibm.com>
Signed-off-by: Stewart Smith <stewart@linux.vnet.ibm.com>
|
|
|
|
|
|
|
|
|
|
|
| |
PCI slot pfreset() operation is obsoleted as nobody uses it. This
removes it and the related PCI slot states. No functional changes
introduced.
Signed-off-by: Gavin Shan <gwshan@linux.vnet.ibm.com>
Acked-by: Russell Currey <ruscur@russell.cc>
Reviewed-by: Andrew Donnellan <andrew.donnellan@au1.ibm.com>
Signed-off-by: Stewart Smith <stewart@linux.vnet.ibm.com>
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
If a PHB is in CAPI mode, we cannot safely fast reboot - the PHB will be
fenced during the reboot resulting in major problems when we load the new
kernel.
In order to handle this safely, we need to disable CAPI mode before
resetting PHBs during the fast reboot. However, we don't currently support
this.
In the meantime, when fast rebooting, check if there are any PHBs with a
CAPP attached, and if so, abort the fast reboot and revert to a normal
reboot instead.
Signed-off-by: Andrew Donnellan <andrew.donnellan@au1.ibm.com>
Signed-off-by: Stewart Smith <stewart@linux.vnet.ibm.com>
|
|
|
|
|
|
|
|
|
| |
This reverts commit e1e6d009860d0ef60f9daf7a0fbe15f869516bd0.
Breaks DT enough that it makes people cranky, reverting for now
Reported-by: Michael Neuling <mikey@neuling.org>
Signed-off-by: Stewart Smith <stewart@linux.vnet.ibm.com>
|
|
|
|
|
|
|
|
|
| |
This works around a problem introduced with fast-reset where if
we provided initrd through qemu (powernv) command line, we'd delete
the device tree nodes before being able to use them.
Fixes: 0279d8951ead549fdebce93130a2f6c673081862
Signed-off-by: Stewart Smith <stewart@linux.vnet.ibm.com>
|
|
|
|
|
|
|
|
|
|
| |
This masks surprise link down event on RC or downtream ports
if the PCI slots behind them support PCI surprise hotplug. The
event should be handled by PCI hotplug driver instead of EEH
subsystem.
Signed-off-by: Gavin Shan <gwshan@linux.vnet.ibm.com>
Signed-off-by: Stewart Smith <stewart@linux.vnet.ibm.com>
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
This claims PCIe surprise hotplug capability through device node's
property "ibm,slot-surprise-pluggable". The slot has the capability
when surprise hotplug is supported in its slot's capability bits or
link state change reporting is supported in PCIe link capability bits.
In order for link state events to be properly raised during surprise
hotplug, the power supply to the slot should be always on. The slot's
power state should be switched accordingly during fundamental reset.
Signed-off-by: Gavin Shan <gwshan@linux.vnet.ibm.com>
Signed-off-by: Stewart Smith <stewart@linux.vnet.ibm.com>
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
When RC's downstream link is down, we need reserve spare PCI buses
if it has an associated PCI hotplug slot. Otherwise, the adapter
behind it can't be probed successfully in PCI hot add scenario.
This reserves all available buses (to 255) for RC's hotplug slot
when its downstream is down so that PCI adapter can be hot added
to the slot afterwards.
Cc: stable # 5.3.0+
Signed-off-by: Gavin Shan <gwshan@linux.vnet.ibm.com>
Signed-off-by: Stewart Smith <stewart@linux.vnet.ibm.com>
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
We might need know the associated PCI slot before applying the chip
level quirk (phb->ops->device_init()) so that special configuration
on the specific PCI slot can be applied.
This moves the logic of creating PCI slot, applying the quirk and
linking the newly probed device to parent's child list to function
pci_scan_one(). Also, the PCI slot is created prior to applying the
quirk.
Cc: stable # 5.3.0+
Signed-off-by: Gavin Shan <gwshan@linux.vnet.ibm.com>
Signed-off-by: Stewart Smith <stewart@linux.vnet.ibm.com>
|
|
|
|
|
|
|
|
|
|
|
|
| |
When OPAL_SUCCESS is returned from slot->ops.set_power_state(),
we need update the PCI toplogy accordingly. This scenario can
happen when builtin power control functionality is ignored to
accomodate PCI surprise hotplug or not supported at all by the
hardware.
Signed-off-by: Gavin Shan <gwshan@linux.vnet.ibm.com>
Reviewed-by: Andrew Donnellan <andrew.donnellan@au1.ibm.com>
Signed-off-by: Stewart Smith <stewart@linux.vnet.ibm.com>
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
We should return cached power state instead of retrieving it from
hardware, meaning we're allowed to have the situation: the power
is off in software, but it's on in hardware when the built-in
power control functionality is ignored for some reasons (e.g.
surprise hotplug support). Otherwise, the adapter behind the
slot won't be probed in PCI hot add path.
This returns the cached power state so that OS sees synchronised
power and PCI slot hotplug state (added/removed).
Signed-off-by: Gavin Shan <gwshan@linux.vnet.ibm.com>
Reviewed-by: Andrew Donnellan <andrew.donnellan@au1.ibm.com>
Signed-off-by: Stewart Smith <stewart@linux.vnet.ibm.com>
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
We can have PCI slots where the mandatory power functionality isn't
supported. On those PCI slots, we should update (cache) the slot's
power state unconditionally because the power state reflects slot's
hotplug state (added or removed). Without this fix, the power and
slot's hotplug state are mismatched on openPower machines. FSP-based
machines don't have the issue.
Signed-off-by: Gavin Shan <gwshan@linux.vnet.ibm.com>
Reviewed-by: Andrew Donnellan <andrew.donnellan@au1.ibm.com>
Signed-off-by: Stewart Smith <stewart@linux.vnet.ibm.com>
|
|
|
|
|
|
|
|
|
|
| |
This returns error (OPAL_PARAMETER) when having invalid power state
transition requests. The invalid requests include: ON to ON, OFF to
OFF.
Signed-off-by: Gavin Shan <gwshan@linux.vnet.ibm.com>
Reviewed-by: Andrew Donnellan <andrew.donnellan@au1.ibm.com>
Signed-off-by: Stewart Smith <stewart@linux.vnet.ibm.com>
|
|
|
|
| |
Signed-off-by: Stewart Smith <stewart@linux.vnet.ibm.com>
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
PNOR partitions downloaded by the resource load framework are not being
measured in habanero, but they should be. The problem is that the
Nuvoton TPM driver is failing to be loaded.
The Nuvoton TPM driver is loaded in stb_init(), but when stb_init() is
called the P8 I2C bus has not been initialized yet. Error message:
"NUVOTON: ibm,opal-id property not found, tpm node parent ..."
This moves stb_init() to later in the boot to meet all its requirements.
Signed-off-by: Claudio Carvalho <cclaudio@linux.vnet.ibm.com>
Signed-off-by: Stewart Smith <stewart@linux.vnet.ibm.com>
|
|
|
|
|
|
|
|
|
|
|
| |
A bit of a hack to free the flattened device tree on fast reset.
This means we don't leak ~500kb memory every fast reset.
We also count the number of fast resets we've done (if enabled),
which means that for stress testing, we have a hope of finding out
how many we managed to do before we hit a problem.
Signed-off-by: Stewart Smith <stewart@linux.vnet.ibm.com>
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
This is an experimental patch that implements "Fast reboot" on P8
machines.
The basic idea is that when the OS calls OPAL reboot, we gather all
the threads in the system using a combination of patching the reset
vector and soft-resetting them, then cleanup a few bits of hardware
(we do re-probe PCIe for example), and reload & restart the bootloader.
For Trusted Boot, this means we *add* measurements to the TPM, so you
will get *different* PCR values as compared to a full IPL. This makes
sense as if you want to be sure you are running something known then,
well, do a full IPL as soft reset should never be trusted to clear any
malicious code.
This is very experimental and needs a lot of testing and also auditing
code for other bits of HW that might need to be cleaned up.
BenH TODO: I also need to check if we are properly PERST'ing PCI devices.
This is partially based on old code I had to do that on P7. I only
support it on P8 though as there are issues with the PSI interrupts
on P7 that cannot be reliably solved.
Even though this should be considered somewhat experimental, we've had
a lot of success on a variety of machines. Dozens/hundreds of reboots
across Tuleta, Garrison and Habanero.
Currently, we've hidden it behind a NVRAM config option, which *is*
liable to change in the future (to ensure that only those who know
what they're doing enable it)
You can enable the experimental support via nvram option:
nvram -p ibm,skiboot --update-config experimental-fast-reset=feeling-lucky
Signed-off-by: Benjamin Herrenschmidt <benh@kernel.crashing.org>
[stewart@linux.vnet.ibm.com: hide behind nvram option, include Mambo fixes
from Mikey]
Signed-off-by: Stewart Smith <stewart@linux.vnet.ibm.com>
|
|
|
|
|
|
|
|
| |
This will be useful for fast reboot which needs to clean a few
things up.
Signed-off-by: Benjamin Herrenschmidt <benh@kernel.crashing.org>
Signed-off-by: Stewart Smith <stewart@linux.vnet.ibm.com>
|
|
|
|
|
|
|
|
| |
Adds a helper that looks for the given NVRAM config string and checks
that associated value is equal to the supplied value.
Signed-off-by: Oliver O'Halloran <oohall@gmail.com>
Signed-off-by: Stewart Smith <stewart@linux.vnet.ibm.com>
|
|
|
|
|
|
|
|
|
|
| |
The running OS is free to re-write the contents of NVRAM. The skiboot
NVRAM parser relies on the NVRAM contents being valid so we need to
force the NVRAM contents to be revalidated after the host OS has written
to it.
Signed-off-by: Oliver O'Halloran <oohall@gmail.com>
Signed-off-by: Stewart Smith <stewart@linux.vnet.ibm.com>
|
|
|
|
|
|
|
|
|
| |
Platforms like mambo doesn't populate 'system-id' DT property. Validate
these properties before using.
Signed-off-by: Vasant Hegde <hegdevasant@linux.vnet.ibm.com>
[stewart@linux.vnet.ibm.com, memset(0) for not found dt props, fix unit test]
Signed-off-by: Stewart Smith <stewart@linux.vnet.ibm.com>
|