| Age | Commit message (Collapse) | Author | Files | Lines |
|---|
|
Use Software Package Data Exchange (SPDX) to indicate license for each
file that is unique to skiboot.
At the same time, ensure the (C) who and years are correct.
See https://spdx.org/
Signed-off-by: Stewart Smith <stewart@linux.ibm.com>
[oliver: Added a few missing files]
Signed-off-by: Oliver O'Halloran <oohall@gmail.com>
|
|
This takes a checksum of skiboot memory after boot that should be
unchanged during OS operation, and verifies it before allowing a
fast reboot.
This is not read-only memory from skiboot's point of view, beause
it includes things like the opal branch table that gets populated
during boot.
This helps to improve the integrity of firmware against host and
runtime firmware memory scribble bugs.
Signed-off-by: Nicholas Piggin <npiggin@gmail.com>
Signed-off-by: Stewart Smith <stewart@linux.ibm.com>
|
|
For many systems, scanning PCI takes about as much time as
zeroing all of RAM, so we may as well do them at the same time
and cut a few seconds off the total fast reboot time.
Signed-off-by: Stewart Smith <stewart@linux.ibm.com>
|
|
Stack allocation first allocates a memory region sized to hold stacks
for all possible CPUs up to the maximum PIR of the architecture, zeros
the region, then initialises all stacks. Max PIR is 32768 on POWER9,
which is 512MB for stacks.
The stack region is then shrunk after CPUs are discovered, but this is
a bit of a hack, and it leaves a hole in the memory allocation regions
as it's done after mem regions are initialised.
0x000000000000..00002fffffff : ibm,os-reserve - OS
0x000030000000..0000303fffff : ibm,firmware-code - OPAL
0x000030400000..000030ffffff : ibm,firmware-heap - OPAL
0x000031000000..000031bfffff : ibm,firmware-data - OPAL
0x000031c00000..000031c0ffff : ibm,firmware-stacks - OPAL
*** gap ***
0x000051c00000..000051d01fff : ibm,firmware-allocs-memory@0 - OPAL
0x000051d02000..00007fffffff : ibm,firmware-allocs-memory@0 - OS
0x000080000000..000080b3cdff : initramfs - OPAL
0x000080b3ce00..000080b7cdff : ibm,fake-nvram - OPAL
0x000080b7ce00..0000ffffffff : ibm,firmware-allocs-memory@0 - OS
This change moves zeroing into the per-cpu stack setup. The boot CPU
stack is set up based on the current PIR. Then the size of the stack
region is set, by discovering the maximum PIR of the system from the
device tree, before mem regions are intialised.
This results in all memory being accounted within memory regions,
and less memory fragmentation of OPAL allocations.
Signed-off-by: Nicholas Piggin <npiggin@gmail.com>
Signed-off-by: Stewart Smith <stewart@linux.vnet.ibm.com>
|
|
Run the mem_region sanity checkers before proceeding with fast
reboot.
This is the beginning of proactive sanity checks on opal data
for fast reboot (with complements the reactive disable_fast_reboot
cases). This is encouraged to re-use and share any kind of debug
code and unit test code.
Signed-off-by: Nicholas Piggin <npiggin@gmail.com>
Signed-off-by: Stewart Smith <stewart@linux.vnet.ibm.com>
|
|
Add a new type of memory reservation that indicates a memory region is
only used by hardware and should not be touched by software. This is
needed for the in-memory tracing buffers. These reservations have the
"no-map" property which indicates that the host kernel should not setup
any virtual address mappings that cover this range, unless of course a
device driver does so explicitly.
Signed-off-by: Oliver O'Halloran <oohall@gmail.com>
Signed-off-by: Stewart Smith <stewart@linux.vnet.ibm.com>
|
|
Currently all existing reservations are made by hostboot itself or on
behalf of some other part of system firmware (e.g. the OCCs). We want
to add a "true" hardware reservation type that should not be touched
by the host OS. To prepare for that this patch renames the existing
reservation type to refect it's actual usage.
Signed-off-by: Oliver O'Halloran <oohall@gmail.com>
Signed-off-by: Stewart Smith <stewart@linux.vnet.ibm.com>
|
|
SLW image)
Memory regions in skiboot have an interesting life cycle. First, we get
a bunch from the initial device tree or hdat specifying some existing
reserved ranges (as well as adding some of our own if they're missing)
but we also get ranges for the entirety of RAM.
The idea is that we can do node local allocations for per node resources
(which we do) and then, just prior to booting linux, we copy the reserved
memory regions to expose to linux along with a set of reserver regions
to cover the node local allocations.
The problem was that mem_range_is_reserved() was wanting subtle different
semantics for memory region type than region_is_reserved() provided.
That is, we were overriding the meaning of REGION_SKIBOOT_HEAP to mean both
"this is reserved by skiboot" *and* "this is a memory region that covers
all of memory and will be shrunk to cover just the memory we have allocated
for it just before we boot the payload (linux)".
So what would happen is we would ask "hey, is the memory holding the SLW
image reserved?" and we'd get the answer of "yes" but referring to the memory
region that covers the entirety of memory in a NUMA node, *not* meaning
our intent of "this will be reserved when we start linux".
To fix this, introduce a new memory region type REGION_MEMORY. This has
the semantics of a memory region that covers a block of memory that we can
allocate from (using local_alloc) and that the part that was allocated
will be passed to linux as reserved, but that the entire range will not
be reserved.
So our new semantics are:
- region_is_reservable() is true if the region *MAY* be reserved
(i.e. is the regions that cover the whole of memory OR is explicitly reserved)
- region_is_reserved() is true if the region *WILL* be reserved
(i.e. is explicitly reserved)
This way we check that the SLW image is explicitly reserved and if it isn't,
we reserve it.
Fixes: 58033e44
Acked-by: Jeremy Kerr <jk@ozlabs.org>
Signed-off-by: Stewart Smith <stewart@linux.vnet.ibm.com>
|
|
This change adds a function to check whether a range of memory is
covered by one or more reservations.
Signed-off-by: Jeremy Kerr <jk@ozlabs.org>
Signed-off-by: Stewart Smith <stewart@linux.vnet.ibm.com>
|
|
|
|
All current users of mem_reserve are actually wanting HW_RESERVED
memory; these reservations are for memory initialised pre-skiboot.
This change marks these regions as REGION_HW_RESERVED instead of
REGION_RESERVED. We also rename mem_reserve to mem_reserve_hw to reflect
this change.
This fixes an issue where the PRD daemon cannot find reserved ranges
(eg, the homer image) that have been created by skiboot itself.
Signed-off-by: Jeremy Kerr <jk@ozlabs.org>
Signed-off-by: Stewart Smith <stewart@linux.vnet.ibm.com>
|
|
|
|
This change allows the mem_region code to distinguish reserved memory
that was allocated before skiboot init, by introducing a new
mem_region_type member.
When we extract reserved ranges from the device tree, we mark them with
this new type.
Signed-off-by: Jeremy Kerr <jk@ozlabs.org>
Signed-off-by: Stewart Smith <stewart@linux.vnet.ibm.com>
|
|
We'll want to store non-memory nodes in this pointer too.
Signed-off-by: Jeremy Kerr <jk@ozlabs.org>
Signed-off-by: Stewart Smith <stewart@linux.vnet.ibm.com>
|
|
Currently, we have a single lock for the entire mem_region system; this
protects both the global region list, and the allocations from each
region.
This means we can't allocate memory while traversing the global region
list, as any malloc/realloc/free will try to acquire the mem_region lock
again.
This change separates the locking into different functions. We keep the
mem_region_lock to protect the regions list, and introduce a per-region
lock to protect allocations from the regions' free_lists.
Then we remove the open-coded invocations of mem_alloc, where we'd
avoided malloc() due to the above locking issue.
Signed-off-by: Jeremy Kerr <jk@ozlabs.org>
Signed-off-by: Stewart Smith <stewart@linux.vnet.ibm.com>
|
|
Currently, we have a single lock for the entire mem_region system; this
protects both the global region list, and the allocations from each
region.
This means we can't allocate memory while traversing the global region
list, as any malloc/realloc/free will try to acquire the mem_region lock
again.
This change separates the locking into different functions. We keep the
mem_region_lock to protect the regions list, and introduce a per-region
lock to protect allocations from the regions' free_lists.
Then we remove the open-coded invocations of mem_alloc, where we'd
avoided malloc() due to the above locking issue.
Signed-off-by: Jeremy Kerr <jk@ozlabs.org>
Signed-off-by: Stewart Smith <stewart@linux.vnet.ibm.com>
|
|
In skiboot, CPU stacks are indexed by PIR.
During boot, we have two ideas about what the actual maximum PIR is:
1) detect CPU type (P7 or P8): we know max PIR is max for that proc
(e.g. 1024, 8192)
2) start all CPUs (go through device tree for CPUs that exist).
We now know the *actual* CPUs we have and the max PIR.
e.g 1, 64, 3319 or whatever
Each CPU stack is 16KB.
So max CPU stacks size for P7 is 16MB, for P8 is 128MB.
The *actual* max for the machine we're booting on is based on max PIR
we detect during boot. I have found the following:
Mambo: 16kb max (one CPU)
P7: 64, meaning 64*16k = 1MB
P8: 3320, meaning 3320*16k = 51MB
So, currently, we were not reseting the size of the skiboot_cpu_stacks
memory region correctly before boot (we construct that part of the device
tree as the very last thing before booting the payload), even though the
comment in mem_region.c would suggest we were, we weren't. Because code
comments are evil and are nothing but filty, filthy lies.
With this patch, we now properly adjust the CPU stacks memory region
size after we've detected CPU type and after we've found the real
max PIR.
This saves between about 77MB and 128MB-16kB of memory from being in a
reserved region and it'll now be available to the OS to use for things
such as cat pictures rather than being firmware stack space waiting for
a CPU that will never appear.
You can see the difference in skiboot log, "Reserved regions:":
Before:
ALL: 0x000031a00000..0000399fffff : ibm,firmware-stacks
AFTER:
Mambo: 0x000031a00000..000031a1ffff : ibm,firmware-stacks
P7: 0x000031a00000..000031afffff : ibm,firmware-stacks.
P8: 0x000031a00000..000034ddffff : ibm,firmware-stacks
Signed-off-by: Stewart Smith <stewart@linux.vnet.ibm.com>
|
|
__builtin_frame_address really wants constants
Signed-off-by: Benjamin Herrenschmidt <benh@kernel.crashing.org>
|
|
This better states the intention of what it should return.
I was bit unsure when fixing mem_size(), so hopefully this
makes future me (or other people) less unsure as to the
intended return value of this function.
No functional changes, just rename.
Signed-off-by: Stewart Smith <stewart@linux.vnet.ibm.com>
Acked-by: Rusty Russell <rusty@au1.ibm.com>
|
|
Signed-off-by: Benjamin Herrenschmidt <benh@kernel.crashing.org>
|
