2019-05-27 08:55:01 +02:00
|
|
|
|
// SPDX-License-Identifier: GPL-2.0-or-later
|
2005-04-16 15:20:36 -07:00
|
|
|
|
/*
|
|
|
|
|
*
|
|
|
|
|
* Procedures for interfacing to the RTAS on CHRP machines.
|
|
|
|
|
*
|
|
|
|
|
* Peter Bergner, IBM March 2001.
|
|
|
|
|
* Copyright (C) 2001 IBM.
|
|
|
|
|
*/
|
|
|
|
|
|
2022-11-18 09:07:46 -06:00
|
|
|
|
#define pr_fmt(fmt) "rtas: " fmt
|
|
|
|
|
|
powerpc/rtas: improve function information lookups
The core RTAS support code and its clients perform two types of lookup
for RTAS firmware function information.
First, mapping a known function name to a token. The typical use case
invokes rtas_token() to retrieve the token value to pass to
rtas_call(). rtas_token() relies on of_get_property(), which performs
a linear search of the /rtas node's property list under a lock with
IRQs disabled.
Second, and less common: given a token value, looking up some
information about the function. The primary example is the sys_rtas
filter path, which linearly scans a small table to match the token to
a rtas_filter struct. Another use case to come is RTAS entry/exit
tracepoints, which will require efficient lookup of function names
from token values. Currently there is no general API for this.
We need something much like the existing rtas_filters table, but more
general and organized to facilitate efficient lookups.
Introduce:
* A new rtas_function type, aggregating function name, token,
and filter. Other function characteristics could be added in the
future.
* An array of rtas_function, where each element corresponds to a known
RTAS function. All information in the table is static save the token
values, which are derived from the device tree at boot. The array is
sorted by function name to allow binary search.
* A named constant for each known RTAS function, used to index the
function array. These also will be used in a client-facing API to be
added later.
* An xarray that maps valid tokens to rtas_function objects.
Fold the existing rtas_filter table into the new rtas_function array,
with the appropriate adjustments to block_rtas_call(). Remove
now-redundant fields from struct rtas_filter. Preserve the function of
the CONFIG_CPU_BIG_ENDIAN guard in the current filter table by
introducing a per-function flag that is set for the function entries
related to pseries LPAR migration. These have never had working users
via sys_rtas on ppc64le; see commit de0f7349a0dd ("powerpc/rtas:
prevent suspend-related sys_rtas use on LE").
Convert rtas_token() to use a lockless binary search on the function
table. Fall back to the old behavior for lookups against names that
are not known to be RTAS functions, but issue a warning. rtas_token()
is for function names; it is not a general facility for accessing
arbitrary properties of the /rtas node. All known misuses of
rtas_token() have been converted to more appropriate of_ APIs in
preceding changes.
Signed-off-by: Nathan Lynch <nathanl@linux.ibm.com>
Signed-off-by: Michael Ellerman <mpe@ellerman.id.au>
Link: https://lore.kernel.org/r/20230125-b4-powerpc-rtas-queue-v3-8-26929c8cce78@linux.ibm.com
2023-02-10 12:41:56 -06:00
|
|
|
|
#include <linux/bsearch.h>
|
2006-01-11 12:17:48 -08:00
|
|
|
|
#include <linux/capability.h>
|
2005-11-07 16:41:59 +11:00
|
|
|
|
#include <linux/delay.h>
|
2022-11-18 09:07:45 -06:00
|
|
|
|
#include <linux/export.h>
|
|
|
|
|
#include <linux/init.h>
|
powerpc/rtas: improve function information lookups
The core RTAS support code and its clients perform two types of lookup
for RTAS firmware function information.
First, mapping a known function name to a token. The typical use case
invokes rtas_token() to retrieve the token value to pass to
rtas_call(). rtas_token() relies on of_get_property(), which performs
a linear search of the /rtas node's property list under a lock with
IRQs disabled.
Second, and less common: given a token value, looking up some
information about the function. The primary example is the sys_rtas
filter path, which linearly scans a small table to match the token to
a rtas_filter struct. Another use case to come is RTAS entry/exit
tracepoints, which will require efficient lookup of function names
from token values. Currently there is no general API for this.
We need something much like the existing rtas_filters table, but more
general and organized to facilitate efficient lookups.
Introduce:
* A new rtas_function type, aggregating function name, token,
and filter. Other function characteristics could be added in the
future.
* An array of rtas_function, where each element corresponds to a known
RTAS function. All information in the table is static save the token
values, which are derived from the device tree at boot. The array is
sorted by function name to allow binary search.
* A named constant for each known RTAS function, used to index the
function array. These also will be used in a client-facing API to be
added later.
* An xarray that maps valid tokens to rtas_function objects.
Fold the existing rtas_filter table into the new rtas_function array,
with the appropriate adjustments to block_rtas_call(). Remove
now-redundant fields from struct rtas_filter. Preserve the function of
the CONFIG_CPU_BIG_ENDIAN guard in the current filter table by
introducing a per-function flag that is set for the function entries
related to pseries LPAR migration. These have never had working users
via sys_rtas on ppc64le; see commit de0f7349a0dd ("powerpc/rtas:
prevent suspend-related sys_rtas use on LE").
Convert rtas_token() to use a lockless binary search on the function
table. Fall back to the old behavior for lookups against names that
are not known to be RTAS functions, but issue a warning. rtas_token()
is for function names; it is not a general facility for accessing
arbitrary properties of the /rtas node. All known misuses of
rtas_token() have been converted to more appropriate of_ APIs in
preceding changes.
Signed-off-by: Nathan Lynch <nathanl@linux.ibm.com>
Signed-off-by: Michael Ellerman <mpe@ellerman.id.au>
Link: https://lore.kernel.org/r/20230125-b4-powerpc-rtas-queue-v3-8-26929c8cce78@linux.ibm.com
2023-02-10 12:41:56 -06:00
|
|
|
|
#include <linux/kconfig.h>
|
2022-11-18 09:07:45 -06:00
|
|
|
|
#include <linux/kernel.h>
|
2023-03-06 15:33:45 -06:00
|
|
|
|
#include <linux/lockdep.h>
|
2010-07-12 14:36:09 +10:00
|
|
|
|
#include <linux/memblock.h>
|
powerpc/rtas: Facilitate high-level call sequences
On RTAS platforms there is a general restriction that the OS must not
enter RTAS on more than one CPU at a time. This low-level
serialization requirement is satisfied by holding a spin
lock (rtas_lock) across most RTAS function invocations.
However, some pseries RTAS functions require multiple successive calls
to complete a logical operation. Beginning a new call sequence for such a
function may disrupt any other sequences of that function already in
progress. Safe and reliable use of these functions effectively
requires higher-level serialization beyond what is already done at the
level of RTAS entry and exit.
Where a sequence-based RTAS function is invoked only through
sys_rtas(), with no in-kernel users, there is no issue as far as the
kernel is concerned. User space is responsible for appropriately
serializing its call sequences. (Whether user space code actually
takes measures to prevent sequence interleaving is another matter.)
Examples of such functions currently include ibm,platform-dump and
ibm,get-vpd.
But where a sequence-based RTAS function has both user space and
in-kernel uesrs, there is a hazard. Even if the in-kernel call sites
of such a function serialize their sequences correctly, a user of
sys_rtas() can invoke the same function at any time, potentially
disrupting a sequence in progress.
So in order to prevent disruption of kernel-based RTAS call sequences,
they must serialize not only with themselves but also with sys_rtas()
users, somehow. Preferably without adding more function-specific hacks
to sys_rtas(). This is a prerequisite for adding an in-kernel call
sequence of ibm,get-vpd, which is in a change to follow.
Note that it has never been feasible for the kernel to prevent
sys_rtas()-based sequences from being disrupted because control
returns to user space on every call. sys_rtas()-based users of these
functions have always been, and continue to be, responsible for
coordinating their call sequences with other users, even those which
may invoke the RTAS functions through less direct means than
sys_rtas(). This is an unavoidable consequence of exposing
sequence-based RTAS functions through sys_rtas().
* Add an optional mutex member to struct rtas_function.
* Statically define a mutex for each RTAS function with known call
sequence serialization requirements, and assign its address to the
.lock member of the corresponding function table entry, along with
justifying commentary.
* In sys_rtas(), if the table entry for the RTAS function being
called has a populated lock member, acquire it before taking
rtas_lock and entering RTAS.
* Kernel-based RTAS call sequences are expected to access the
appropriate mutex explicitly by name. For example, a user of the
ibm,activate-firmware RTAS function would do:
int token = rtas_function_token(RTAS_FN_IBM_ACTIVATE_FIRMWARE);
int fwrc;
mutex_lock(&rtas_ibm_activate_firmware_lock);
do {
fwrc = rtas_call(token, 0, 1, NULL);
} while (rtas_busy_delay(fwrc));
mutex_unlock(&rtas_ibm_activate_firmware_lock);
There should be no perceivable change introduced here except that
concurrent callers of the same RTAS function via sys_rtas() may block
on a mutex instead of spinning on rtas_lock.
Signed-off-by: Nathan Lynch <nathanl@linux.ibm.com>
Signed-off-by: Michael Ellerman <mpe@ellerman.id.au>
Link: https://msgid.link/20231212-papr-sys_rtas-vs-lockdown-v6-6-e9eafd0c8c6c@linux.ibm.com
2023-12-12 11:01:53 -06:00
|
|
|
|
#include <linux/mutex.h>
|
2022-11-18 09:07:45 -06:00
|
|
|
|
#include <linux/of.h>
|
|
|
|
|
#include <linux/of_fdt.h>
|
2011-07-25 17:13:10 -07:00
|
|
|
|
#include <linux/reboot.h>
|
2022-11-18 09:07:45 -06:00
|
|
|
|
#include <linux/sched.h>
|
2022-09-26 08:16:43 -05:00
|
|
|
|
#include <linux/security.h>
|
2022-11-18 09:07:45 -06:00
|
|
|
|
#include <linux/slab.h>
|
|
|
|
|
#include <linux/spinlock.h>
|
|
|
|
|
#include <linux/stdarg.h>
|
2018-05-02 23:20:48 +10:00
|
|
|
|
#include <linux/syscalls.h>
|
2022-11-18 09:07:45 -06:00
|
|
|
|
#include <linux/types.h>
|
|
|
|
|
#include <linux/uaccess.h>
|
powerpc/rtas: improve function information lookups
The core RTAS support code and its clients perform two types of lookup
for RTAS firmware function information.
First, mapping a known function name to a token. The typical use case
invokes rtas_token() to retrieve the token value to pass to
rtas_call(). rtas_token() relies on of_get_property(), which performs
a linear search of the /rtas node's property list under a lock with
IRQs disabled.
Second, and less common: given a token value, looking up some
information about the function. The primary example is the sys_rtas
filter path, which linearly scans a small table to match the token to
a rtas_filter struct. Another use case to come is RTAS entry/exit
tracepoints, which will require efficient lookup of function names
from token values. Currently there is no general API for this.
We need something much like the existing rtas_filters table, but more
general and organized to facilitate efficient lookups.
Introduce:
* A new rtas_function type, aggregating function name, token,
and filter. Other function characteristics could be added in the
future.
* An array of rtas_function, where each element corresponds to a known
RTAS function. All information in the table is static save the token
values, which are derived from the device tree at boot. The array is
sorted by function name to allow binary search.
* A named constant for each known RTAS function, used to index the
function array. These also will be used in a client-facing API to be
added later.
* An xarray that maps valid tokens to rtas_function objects.
Fold the existing rtas_filter table into the new rtas_function array,
with the appropriate adjustments to block_rtas_call(). Remove
now-redundant fields from struct rtas_filter. Preserve the function of
the CONFIG_CPU_BIG_ENDIAN guard in the current filter table by
introducing a per-function flag that is set for the function entries
related to pseries LPAR migration. These have never had working users
via sys_rtas on ppc64le; see commit de0f7349a0dd ("powerpc/rtas:
prevent suspend-related sys_rtas use on LE").
Convert rtas_token() to use a lockless binary search on the function
table. Fall back to the old behavior for lookups against names that
are not known to be RTAS functions, but issue a warning. rtas_token()
is for function names; it is not a general facility for accessing
arbitrary properties of the /rtas node. All known misuses of
rtas_token() have been converted to more appropriate of_ APIs in
preceding changes.
Signed-off-by: Nathan Lynch <nathanl@linux.ibm.com>
Signed-off-by: Michael Ellerman <mpe@ellerman.id.au>
Link: https://lore.kernel.org/r/20230125-b4-powerpc-rtas-queue-v3-8-26929c8cce78@linux.ibm.com
2023-02-10 12:41:56 -06:00
|
|
|
|
#include <linux/xarray.h>
|
2005-04-16 15:20:36 -07:00
|
|
|
|
|
2022-11-18 09:07:45 -06:00
|
|
|
|
#include <asm/delay.h>
|
|
|
|
|
#include <asm/firmware.h>
|
2021-06-18 01:51:03 +10:00
|
|
|
|
#include <asm/interrupt.h>
|
2005-04-16 15:20:36 -07:00
|
|
|
|
#include <asm/machdep.h>
|
2022-11-18 09:07:45 -06:00
|
|
|
|
#include <asm/mmu.h>
|
2005-04-16 15:20:36 -07:00
|
|
|
|
#include <asm/page.h>
|
powerpc/pseries: add RTAS work area allocator
Various pseries-specific RTAS functions take a temporary "work area"
parameter - a buffer in memory accessible to RTAS. Typically such
functions are passed the statically allocated rtas_data_buf buffer as
the argument. This buffer is protected by a global spinlock. So users
of rtas_data_buf cannot perform sleeping operations while accessing
the buffer.
Most RTAS functions that have a work area parameter can return a
status (-2/990x) that indicates that the caller should retry. Before
retrying, the caller may need to reschedule or sleep (see
rtas_busy_delay() for details). This combination of factors
leads to uncomfortable constructions like this:
do {
spin_lock(&rtas_data_buf_lock);
rc = rtas_call(token, __pa(rtas_data_buf, ...);
if (rc == 0) {
/* parse or copy out rtas_data_buf contents */
}
spin_unlock(&rtas_data_buf_lock);
} while (rtas_busy_delay(rc));
Another unfortunately common way of handling this is for callers to
blithely ignore the possibility of a -2/990x status and hope for the
best.
If users were allowed to perform blocking operations while owning a
work area, the programming model would become less tedious and
error-prone. Users could schedule away, sleep, or perform other
blocking operations without having to release and re-acquire
resources.
We could continue to use a single work area buffer, and convert
rtas_data_buf_lock to a mutex. But that would impose an unnecessarily
coarse serialization on all users. As awkward as the current design
is, it prevents longer running operations that need to repeatedly use
rtas_data_buf from blocking the progress of others.
There are more considerations. One is that while 4KB is fine for all
current in-kernel uses, some RTAS calls can take much smaller buffers,
and some (VPD, platform dumps) would likely benefit from larger
ones. Another is that at least one RTAS function (ibm,get-vpd)
has *two* work area parameters. And finally, we should expect the
number of work area users in the kernel to increase over time as we
introduce lockdown-compatible ABIs to replace less safe use cases
based on sys_rtas/librtas.
So a special-purpose allocator for RTAS work area buffers seems worth
trying.
Properties:
* The backing memory for the allocator is reserved early in boot in
order to satisfy RTAS addressing requirements, and then managed with
genalloc.
* Allocations can block, but they never fail (mempool-like).
* Prioritizes first-come, first-serve fairness over throughput.
* Early boot allocations before the allocator has been initialized are
served via an internal static buffer.
Intended to replace rtas_data_buf. New code that needs RTAS work area
buffers should prefer this API.
Signed-off-by: Nathan Lynch <nathanl@linux.ibm.com>
Signed-off-by: Michael Ellerman <mpe@ellerman.id.au>
Link: https://lore.kernel.org/r/20230125-b4-powerpc-rtas-queue-v3-12-26929c8cce78@linux.ibm.com
2023-02-10 12:42:00 -06:00
|
|
|
|
#include <asm/rtas-work-area.h>
|
2022-11-18 09:07:45 -06:00
|
|
|
|
#include <asm/rtas.h>
|
2009-06-16 16:42:50 +00:00
|
|
|
|
#include <asm/time.h>
|
2023-02-10 12:41:59 -06:00
|
|
|
|
#include <asm/trace.h>
|
2022-11-18 09:07:45 -06:00
|
|
|
|
#include <asm/udbg.h>
|
2005-04-16 15:20:36 -07:00
|
|
|
|
|
powerpc/rtas: improve function information lookups
The core RTAS support code and its clients perform two types of lookup
for RTAS firmware function information.
First, mapping a known function name to a token. The typical use case
invokes rtas_token() to retrieve the token value to pass to
rtas_call(). rtas_token() relies on of_get_property(), which performs
a linear search of the /rtas node's property list under a lock with
IRQs disabled.
Second, and less common: given a token value, looking up some
information about the function. The primary example is the sys_rtas
filter path, which linearly scans a small table to match the token to
a rtas_filter struct. Another use case to come is RTAS entry/exit
tracepoints, which will require efficient lookup of function names
from token values. Currently there is no general API for this.
We need something much like the existing rtas_filters table, but more
general and organized to facilitate efficient lookups.
Introduce:
* A new rtas_function type, aggregating function name, token,
and filter. Other function characteristics could be added in the
future.
* An array of rtas_function, where each element corresponds to a known
RTAS function. All information in the table is static save the token
values, which are derived from the device tree at boot. The array is
sorted by function name to allow binary search.
* A named constant for each known RTAS function, used to index the
function array. These also will be used in a client-facing API to be
added later.
* An xarray that maps valid tokens to rtas_function objects.
Fold the existing rtas_filter table into the new rtas_function array,
with the appropriate adjustments to block_rtas_call(). Remove
now-redundant fields from struct rtas_filter. Preserve the function of
the CONFIG_CPU_BIG_ENDIAN guard in the current filter table by
introducing a per-function flag that is set for the function entries
related to pseries LPAR migration. These have never had working users
via sys_rtas on ppc64le; see commit de0f7349a0dd ("powerpc/rtas:
prevent suspend-related sys_rtas use on LE").
Convert rtas_token() to use a lockless binary search on the function
table. Fall back to the old behavior for lookups against names that
are not known to be RTAS functions, but issue a warning. rtas_token()
is for function names; it is not a general facility for accessing
arbitrary properties of the /rtas node. All known misuses of
rtas_token() have been converted to more appropriate of_ APIs in
preceding changes.
Signed-off-by: Nathan Lynch <nathanl@linux.ibm.com>
Signed-off-by: Michael Ellerman <mpe@ellerman.id.au>
Link: https://lore.kernel.org/r/20230125-b4-powerpc-rtas-queue-v3-8-26929c8cce78@linux.ibm.com
2023-02-10 12:41:56 -06:00
|
|
|
|
struct rtas_filter {
|
|
|
|
|
/* Indexes into the args buffer, -1 if not used */
|
|
|
|
|
const int buf_idx1;
|
|
|
|
|
const int size_idx1;
|
|
|
|
|
const int buf_idx2;
|
|
|
|
|
const int size_idx2;
|
|
|
|
|
/*
|
|
|
|
|
* Assumed buffer size per the spec if the function does not
|
|
|
|
|
* have a size parameter, e.g. ibm,errinjct. 0 if unused.
|
|
|
|
|
*/
|
|
|
|
|
const int fixed_size;
|
|
|
|
|
};
|
|
|
|
|
|
|
|
|
|
/**
|
|
|
|
|
* struct rtas_function - Descriptor for RTAS functions.
|
|
|
|
|
*
|
|
|
|
|
* @token: Value of @name if it exists under the /rtas node.
|
|
|
|
|
* @name: Function name.
|
|
|
|
|
* @filter: If non-NULL, invoking this function via the rtas syscall is
|
|
|
|
|
* generally allowed, and @filter describes constraints on the
|
|
|
|
|
* arguments. See also @banned_for_syscall_on_le.
|
|
|
|
|
* @banned_for_syscall_on_le: Set when call via sys_rtas is generally allowed
|
|
|
|
|
* but specifically restricted on ppc64le. Such
|
|
|
|
|
* functions are believed to have no users on
|
|
|
|
|
* ppc64le, and we want to keep it that way. It does
|
|
|
|
|
* not make sense for this to be set when @filter
|
2023-03-06 15:33:43 -06:00
|
|
|
|
* is NULL.
|
powerpc/rtas: Facilitate high-level call sequences
On RTAS platforms there is a general restriction that the OS must not
enter RTAS on more than one CPU at a time. This low-level
serialization requirement is satisfied by holding a spin
lock (rtas_lock) across most RTAS function invocations.
However, some pseries RTAS functions require multiple successive calls
to complete a logical operation. Beginning a new call sequence for such a
function may disrupt any other sequences of that function already in
progress. Safe and reliable use of these functions effectively
requires higher-level serialization beyond what is already done at the
level of RTAS entry and exit.
Where a sequence-based RTAS function is invoked only through
sys_rtas(), with no in-kernel users, there is no issue as far as the
kernel is concerned. User space is responsible for appropriately
serializing its call sequences. (Whether user space code actually
takes measures to prevent sequence interleaving is another matter.)
Examples of such functions currently include ibm,platform-dump and
ibm,get-vpd.
But where a sequence-based RTAS function has both user space and
in-kernel uesrs, there is a hazard. Even if the in-kernel call sites
of such a function serialize their sequences correctly, a user of
sys_rtas() can invoke the same function at any time, potentially
disrupting a sequence in progress.
So in order to prevent disruption of kernel-based RTAS call sequences,
they must serialize not only with themselves but also with sys_rtas()
users, somehow. Preferably without adding more function-specific hacks
to sys_rtas(). This is a prerequisite for adding an in-kernel call
sequence of ibm,get-vpd, which is in a change to follow.
Note that it has never been feasible for the kernel to prevent
sys_rtas()-based sequences from being disrupted because control
returns to user space on every call. sys_rtas()-based users of these
functions have always been, and continue to be, responsible for
coordinating their call sequences with other users, even those which
may invoke the RTAS functions through less direct means than
sys_rtas(). This is an unavoidable consequence of exposing
sequence-based RTAS functions through sys_rtas().
* Add an optional mutex member to struct rtas_function.
* Statically define a mutex for each RTAS function with known call
sequence serialization requirements, and assign its address to the
.lock member of the corresponding function table entry, along with
justifying commentary.
* In sys_rtas(), if the table entry for the RTAS function being
called has a populated lock member, acquire it before taking
rtas_lock and entering RTAS.
* Kernel-based RTAS call sequences are expected to access the
appropriate mutex explicitly by name. For example, a user of the
ibm,activate-firmware RTAS function would do:
int token = rtas_function_token(RTAS_FN_IBM_ACTIVATE_FIRMWARE);
int fwrc;
mutex_lock(&rtas_ibm_activate_firmware_lock);
do {
fwrc = rtas_call(token, 0, 1, NULL);
} while (rtas_busy_delay(fwrc));
mutex_unlock(&rtas_ibm_activate_firmware_lock);
There should be no perceivable change introduced here except that
concurrent callers of the same RTAS function via sys_rtas() may block
on a mutex instead of spinning on rtas_lock.
Signed-off-by: Nathan Lynch <nathanl@linux.ibm.com>
Signed-off-by: Michael Ellerman <mpe@ellerman.id.au>
Link: https://msgid.link/20231212-papr-sys_rtas-vs-lockdown-v6-6-e9eafd0c8c6c@linux.ibm.com
2023-12-12 11:01:53 -06:00
|
|
|
|
* @lock: Pointer to an optional dedicated per-function mutex. This
|
|
|
|
|
* should be set for functions that require multiple calls in
|
|
|
|
|
* sequence to complete a single operation, and such sequences
|
|
|
|
|
* will disrupt each other if allowed to interleave. Users of
|
|
|
|
|
* this function are required to hold the associated lock for
|
|
|
|
|
* the duration of the call sequence. Add an explanatory
|
|
|
|
|
* comment to the function table entry if setting this member.
|
powerpc/rtas: improve function information lookups
The core RTAS support code and its clients perform two types of lookup
for RTAS firmware function information.
First, mapping a known function name to a token. The typical use case
invokes rtas_token() to retrieve the token value to pass to
rtas_call(). rtas_token() relies on of_get_property(), which performs
a linear search of the /rtas node's property list under a lock with
IRQs disabled.
Second, and less common: given a token value, looking up some
information about the function. The primary example is the sys_rtas
filter path, which linearly scans a small table to match the token to
a rtas_filter struct. Another use case to come is RTAS entry/exit
tracepoints, which will require efficient lookup of function names
from token values. Currently there is no general API for this.
We need something much like the existing rtas_filters table, but more
general and organized to facilitate efficient lookups.
Introduce:
* A new rtas_function type, aggregating function name, token,
and filter. Other function characteristics could be added in the
future.
* An array of rtas_function, where each element corresponds to a known
RTAS function. All information in the table is static save the token
values, which are derived from the device tree at boot. The array is
sorted by function name to allow binary search.
* A named constant for each known RTAS function, used to index the
function array. These also will be used in a client-facing API to be
added later.
* An xarray that maps valid tokens to rtas_function objects.
Fold the existing rtas_filter table into the new rtas_function array,
with the appropriate adjustments to block_rtas_call(). Remove
now-redundant fields from struct rtas_filter. Preserve the function of
the CONFIG_CPU_BIG_ENDIAN guard in the current filter table by
introducing a per-function flag that is set for the function entries
related to pseries LPAR migration. These have never had working users
via sys_rtas on ppc64le; see commit de0f7349a0dd ("powerpc/rtas:
prevent suspend-related sys_rtas use on LE").
Convert rtas_token() to use a lockless binary search on the function
table. Fall back to the old behavior for lookups against names that
are not known to be RTAS functions, but issue a warning. rtas_token()
is for function names; it is not a general facility for accessing
arbitrary properties of the /rtas node. All known misuses of
rtas_token() have been converted to more appropriate of_ APIs in
preceding changes.
Signed-off-by: Nathan Lynch <nathanl@linux.ibm.com>
Signed-off-by: Michael Ellerman <mpe@ellerman.id.au>
Link: https://lore.kernel.org/r/20230125-b4-powerpc-rtas-queue-v3-8-26929c8cce78@linux.ibm.com
2023-02-10 12:41:56 -06:00
|
|
|
|
*/
|
|
|
|
|
struct rtas_function {
|
|
|
|
|
s32 token;
|
|
|
|
|
const bool banned_for_syscall_on_le:1;
|
|
|
|
|
const char * const name;
|
|
|
|
|
const struct rtas_filter *filter;
|
powerpc/rtas: Facilitate high-level call sequences
On RTAS platforms there is a general restriction that the OS must not
enter RTAS on more than one CPU at a time. This low-level
serialization requirement is satisfied by holding a spin
lock (rtas_lock) across most RTAS function invocations.
However, some pseries RTAS functions require multiple successive calls
to complete a logical operation. Beginning a new call sequence for such a
function may disrupt any other sequences of that function already in
progress. Safe and reliable use of these functions effectively
requires higher-level serialization beyond what is already done at the
level of RTAS entry and exit.
Where a sequence-based RTAS function is invoked only through
sys_rtas(), with no in-kernel users, there is no issue as far as the
kernel is concerned. User space is responsible for appropriately
serializing its call sequences. (Whether user space code actually
takes measures to prevent sequence interleaving is another matter.)
Examples of such functions currently include ibm,platform-dump and
ibm,get-vpd.
But where a sequence-based RTAS function has both user space and
in-kernel uesrs, there is a hazard. Even if the in-kernel call sites
of such a function serialize their sequences correctly, a user of
sys_rtas() can invoke the same function at any time, potentially
disrupting a sequence in progress.
So in order to prevent disruption of kernel-based RTAS call sequences,
they must serialize not only with themselves but also with sys_rtas()
users, somehow. Preferably without adding more function-specific hacks
to sys_rtas(). This is a prerequisite for adding an in-kernel call
sequence of ibm,get-vpd, which is in a change to follow.
Note that it has never been feasible for the kernel to prevent
sys_rtas()-based sequences from being disrupted because control
returns to user space on every call. sys_rtas()-based users of these
functions have always been, and continue to be, responsible for
coordinating their call sequences with other users, even those which
may invoke the RTAS functions through less direct means than
sys_rtas(). This is an unavoidable consequence of exposing
sequence-based RTAS functions through sys_rtas().
* Add an optional mutex member to struct rtas_function.
* Statically define a mutex for each RTAS function with known call
sequence serialization requirements, and assign its address to the
.lock member of the corresponding function table entry, along with
justifying commentary.
* In sys_rtas(), if the table entry for the RTAS function being
called has a populated lock member, acquire it before taking
rtas_lock and entering RTAS.
* Kernel-based RTAS call sequences are expected to access the
appropriate mutex explicitly by name. For example, a user of the
ibm,activate-firmware RTAS function would do:
int token = rtas_function_token(RTAS_FN_IBM_ACTIVATE_FIRMWARE);
int fwrc;
mutex_lock(&rtas_ibm_activate_firmware_lock);
do {
fwrc = rtas_call(token, 0, 1, NULL);
} while (rtas_busy_delay(fwrc));
mutex_unlock(&rtas_ibm_activate_firmware_lock);
There should be no perceivable change introduced here except that
concurrent callers of the same RTAS function via sys_rtas() may block
on a mutex instead of spinning on rtas_lock.
Signed-off-by: Nathan Lynch <nathanl@linux.ibm.com>
Signed-off-by: Michael Ellerman <mpe@ellerman.id.au>
Link: https://msgid.link/20231212-papr-sys_rtas-vs-lockdown-v6-6-e9eafd0c8c6c@linux.ibm.com
2023-12-12 11:01:53 -06:00
|
|
|
|
struct mutex *lock;
|
powerpc/rtas: improve function information lookups
The core RTAS support code and its clients perform two types of lookup
for RTAS firmware function information.
First, mapping a known function name to a token. The typical use case
invokes rtas_token() to retrieve the token value to pass to
rtas_call(). rtas_token() relies on of_get_property(), which performs
a linear search of the /rtas node's property list under a lock with
IRQs disabled.
Second, and less common: given a token value, looking up some
information about the function. The primary example is the sys_rtas
filter path, which linearly scans a small table to match the token to
a rtas_filter struct. Another use case to come is RTAS entry/exit
tracepoints, which will require efficient lookup of function names
from token values. Currently there is no general API for this.
We need something much like the existing rtas_filters table, but more
general and organized to facilitate efficient lookups.
Introduce:
* A new rtas_function type, aggregating function name, token,
and filter. Other function characteristics could be added in the
future.
* An array of rtas_function, where each element corresponds to a known
RTAS function. All information in the table is static save the token
values, which are derived from the device tree at boot. The array is
sorted by function name to allow binary search.
* A named constant for each known RTAS function, used to index the
function array. These also will be used in a client-facing API to be
added later.
* An xarray that maps valid tokens to rtas_function objects.
Fold the existing rtas_filter table into the new rtas_function array,
with the appropriate adjustments to block_rtas_call(). Remove
now-redundant fields from struct rtas_filter. Preserve the function of
the CONFIG_CPU_BIG_ENDIAN guard in the current filter table by
introducing a per-function flag that is set for the function entries
related to pseries LPAR migration. These have never had working users
via sys_rtas on ppc64le; see commit de0f7349a0dd ("powerpc/rtas:
prevent suspend-related sys_rtas use on LE").
Convert rtas_token() to use a lockless binary search on the function
table. Fall back to the old behavior for lookups against names that
are not known to be RTAS functions, but issue a warning. rtas_token()
is for function names; it is not a general facility for accessing
arbitrary properties of the /rtas node. All known misuses of
rtas_token() have been converted to more appropriate of_ APIs in
preceding changes.
Signed-off-by: Nathan Lynch <nathanl@linux.ibm.com>
Signed-off-by: Michael Ellerman <mpe@ellerman.id.au>
Link: https://lore.kernel.org/r/20230125-b4-powerpc-rtas-queue-v3-8-26929c8cce78@linux.ibm.com
2023-02-10 12:41:56 -06:00
|
|
|
|
};
|
|
|
|
|
|
powerpc/rtas: Facilitate high-level call sequences
On RTAS platforms there is a general restriction that the OS must not
enter RTAS on more than one CPU at a time. This low-level
serialization requirement is satisfied by holding a spin
lock (rtas_lock) across most RTAS function invocations.
However, some pseries RTAS functions require multiple successive calls
to complete a logical operation. Beginning a new call sequence for such a
function may disrupt any other sequences of that function already in
progress. Safe and reliable use of these functions effectively
requires higher-level serialization beyond what is already done at the
level of RTAS entry and exit.
Where a sequence-based RTAS function is invoked only through
sys_rtas(), with no in-kernel users, there is no issue as far as the
kernel is concerned. User space is responsible for appropriately
serializing its call sequences. (Whether user space code actually
takes measures to prevent sequence interleaving is another matter.)
Examples of such functions currently include ibm,platform-dump and
ibm,get-vpd.
But where a sequence-based RTAS function has both user space and
in-kernel uesrs, there is a hazard. Even if the in-kernel call sites
of such a function serialize their sequences correctly, a user of
sys_rtas() can invoke the same function at any time, potentially
disrupting a sequence in progress.
So in order to prevent disruption of kernel-based RTAS call sequences,
they must serialize not only with themselves but also with sys_rtas()
users, somehow. Preferably without adding more function-specific hacks
to sys_rtas(). This is a prerequisite for adding an in-kernel call
sequence of ibm,get-vpd, which is in a change to follow.
Note that it has never been feasible for the kernel to prevent
sys_rtas()-based sequences from being disrupted because control
returns to user space on every call. sys_rtas()-based users of these
functions have always been, and continue to be, responsible for
coordinating their call sequences with other users, even those which
may invoke the RTAS functions through less direct means than
sys_rtas(). This is an unavoidable consequence of exposing
sequence-based RTAS functions through sys_rtas().
* Add an optional mutex member to struct rtas_function.
* Statically define a mutex for each RTAS function with known call
sequence serialization requirements, and assign its address to the
.lock member of the corresponding function table entry, along with
justifying commentary.
* In sys_rtas(), if the table entry for the RTAS function being
called has a populated lock member, acquire it before taking
rtas_lock and entering RTAS.
* Kernel-based RTAS call sequences are expected to access the
appropriate mutex explicitly by name. For example, a user of the
ibm,activate-firmware RTAS function would do:
int token = rtas_function_token(RTAS_FN_IBM_ACTIVATE_FIRMWARE);
int fwrc;
mutex_lock(&rtas_ibm_activate_firmware_lock);
do {
fwrc = rtas_call(token, 0, 1, NULL);
} while (rtas_busy_delay(fwrc));
mutex_unlock(&rtas_ibm_activate_firmware_lock);
There should be no perceivable change introduced here except that
concurrent callers of the same RTAS function via sys_rtas() may block
on a mutex instead of spinning on rtas_lock.
Signed-off-by: Nathan Lynch <nathanl@linux.ibm.com>
Signed-off-by: Michael Ellerman <mpe@ellerman.id.au>
Link: https://msgid.link/20231212-papr-sys_rtas-vs-lockdown-v6-6-e9eafd0c8c6c@linux.ibm.com
2023-12-12 11:01:53 -06:00
|
|
|
|
/*
|
|
|
|
|
* Per-function locks for sequence-based RTAS functions.
|
|
|
|
|
*/
|
|
|
|
|
static DEFINE_MUTEX(rtas_ibm_activate_firmware_lock);
|
|
|
|
|
static DEFINE_MUTEX(rtas_ibm_get_dynamic_sensor_state_lock);
|
|
|
|
|
static DEFINE_MUTEX(rtas_ibm_get_indices_lock);
|
|
|
|
|
static DEFINE_MUTEX(rtas_ibm_lpar_perftools_lock);
|
|
|
|
|
static DEFINE_MUTEX(rtas_ibm_physical_attestation_lock);
|
|
|
|
|
static DEFINE_MUTEX(rtas_ibm_set_dynamic_indicator_lock);
|
|
|
|
|
DEFINE_MUTEX(rtas_ibm_get_vpd_lock);
|
|
|
|
|
|
powerpc/rtas: improve function information lookups
The core RTAS support code and its clients perform two types of lookup
for RTAS firmware function information.
First, mapping a known function name to a token. The typical use case
invokes rtas_token() to retrieve the token value to pass to
rtas_call(). rtas_token() relies on of_get_property(), which performs
a linear search of the /rtas node's property list under a lock with
IRQs disabled.
Second, and less common: given a token value, looking up some
information about the function. The primary example is the sys_rtas
filter path, which linearly scans a small table to match the token to
a rtas_filter struct. Another use case to come is RTAS entry/exit
tracepoints, which will require efficient lookup of function names
from token values. Currently there is no general API for this.
We need something much like the existing rtas_filters table, but more
general and organized to facilitate efficient lookups.
Introduce:
* A new rtas_function type, aggregating function name, token,
and filter. Other function characteristics could be added in the
future.
* An array of rtas_function, where each element corresponds to a known
RTAS function. All information in the table is static save the token
values, which are derived from the device tree at boot. The array is
sorted by function name to allow binary search.
* A named constant for each known RTAS function, used to index the
function array. These also will be used in a client-facing API to be
added later.
* An xarray that maps valid tokens to rtas_function objects.
Fold the existing rtas_filter table into the new rtas_function array,
with the appropriate adjustments to block_rtas_call(). Remove
now-redundant fields from struct rtas_filter. Preserve the function of
the CONFIG_CPU_BIG_ENDIAN guard in the current filter table by
introducing a per-function flag that is set for the function entries
related to pseries LPAR migration. These have never had working users
via sys_rtas on ppc64le; see commit de0f7349a0dd ("powerpc/rtas:
prevent suspend-related sys_rtas use on LE").
Convert rtas_token() to use a lockless binary search on the function
table. Fall back to the old behavior for lookups against names that
are not known to be RTAS functions, but issue a warning. rtas_token()
is for function names; it is not a general facility for accessing
arbitrary properties of the /rtas node. All known misuses of
rtas_token() have been converted to more appropriate of_ APIs in
preceding changes.
Signed-off-by: Nathan Lynch <nathanl@linux.ibm.com>
Signed-off-by: Michael Ellerman <mpe@ellerman.id.au>
Link: https://lore.kernel.org/r/20230125-b4-powerpc-rtas-queue-v3-8-26929c8cce78@linux.ibm.com
2023-02-10 12:41:56 -06:00
|
|
|
|
static struct rtas_function rtas_function_table[] __ro_after_init = {
|
|
|
|
|
[RTAS_FNIDX__CHECK_EXCEPTION] = {
|
|
|
|
|
.name = "check-exception",
|
|
|
|
|
},
|
|
|
|
|
[RTAS_FNIDX__DISPLAY_CHARACTER] = {
|
|
|
|
|
.name = "display-character",
|
|
|
|
|
.filter = &(const struct rtas_filter) {
|
|
|
|
|
.buf_idx1 = -1, .size_idx1 = -1,
|
|
|
|
|
.buf_idx2 = -1, .size_idx2 = -1,
|
|
|
|
|
},
|
|
|
|
|
},
|
|
|
|
|
[RTAS_FNIDX__EVENT_SCAN] = {
|
|
|
|
|
.name = "event-scan",
|
|
|
|
|
},
|
|
|
|
|
[RTAS_FNIDX__FREEZE_TIME_BASE] = {
|
|
|
|
|
.name = "freeze-time-base",
|
|
|
|
|
},
|
|
|
|
|
[RTAS_FNIDX__GET_POWER_LEVEL] = {
|
|
|
|
|
.name = "get-power-level",
|
|
|
|
|
.filter = &(const struct rtas_filter) {
|
|
|
|
|
.buf_idx1 = -1, .size_idx1 = -1,
|
|
|
|
|
.buf_idx2 = -1, .size_idx2 = -1,
|
|
|
|
|
},
|
|
|
|
|
},
|
|
|
|
|
[RTAS_FNIDX__GET_SENSOR_STATE] = {
|
|
|
|
|
.name = "get-sensor-state",
|
|
|
|
|
.filter = &(const struct rtas_filter) {
|
|
|
|
|
.buf_idx1 = -1, .size_idx1 = -1,
|
|
|
|
|
.buf_idx2 = -1, .size_idx2 = -1,
|
|
|
|
|
},
|
|
|
|
|
},
|
|
|
|
|
[RTAS_FNIDX__GET_TERM_CHAR] = {
|
|
|
|
|
.name = "get-term-char",
|
|
|
|
|
},
|
|
|
|
|
[RTAS_FNIDX__GET_TIME_OF_DAY] = {
|
|
|
|
|
.name = "get-time-of-day",
|
|
|
|
|
.filter = &(const struct rtas_filter) {
|
|
|
|
|
.buf_idx1 = -1, .size_idx1 = -1,
|
|
|
|
|
.buf_idx2 = -1, .size_idx2 = -1,
|
|
|
|
|
},
|
|
|
|
|
},
|
|
|
|
|
[RTAS_FNIDX__IBM_ACTIVATE_FIRMWARE] = {
|
|
|
|
|
.name = "ibm,activate-firmware",
|
|
|
|
|
.filter = &(const struct rtas_filter) {
|
|
|
|
|
.buf_idx1 = -1, .size_idx1 = -1,
|
|
|
|
|
.buf_idx2 = -1, .size_idx2 = -1,
|
|
|
|
|
},
|
powerpc/rtas: Facilitate high-level call sequences
On RTAS platforms there is a general restriction that the OS must not
enter RTAS on more than one CPU at a time. This low-level
serialization requirement is satisfied by holding a spin
lock (rtas_lock) across most RTAS function invocations.
However, some pseries RTAS functions require multiple successive calls
to complete a logical operation. Beginning a new call sequence for such a
function may disrupt any other sequences of that function already in
progress. Safe and reliable use of these functions effectively
requires higher-level serialization beyond what is already done at the
level of RTAS entry and exit.
Where a sequence-based RTAS function is invoked only through
sys_rtas(), with no in-kernel users, there is no issue as far as the
kernel is concerned. User space is responsible for appropriately
serializing its call sequences. (Whether user space code actually
takes measures to prevent sequence interleaving is another matter.)
Examples of such functions currently include ibm,platform-dump and
ibm,get-vpd.
But where a sequence-based RTAS function has both user space and
in-kernel uesrs, there is a hazard. Even if the in-kernel call sites
of such a function serialize their sequences correctly, a user of
sys_rtas() can invoke the same function at any time, potentially
disrupting a sequence in progress.
So in order to prevent disruption of kernel-based RTAS call sequences,
they must serialize not only with themselves but also with sys_rtas()
users, somehow. Preferably without adding more function-specific hacks
to sys_rtas(). This is a prerequisite for adding an in-kernel call
sequence of ibm,get-vpd, which is in a change to follow.
Note that it has never been feasible for the kernel to prevent
sys_rtas()-based sequences from being disrupted because control
returns to user space on every call. sys_rtas()-based users of these
functions have always been, and continue to be, responsible for
coordinating their call sequences with other users, even those which
may invoke the RTAS functions through less direct means than
sys_rtas(). This is an unavoidable consequence of exposing
sequence-based RTAS functions through sys_rtas().
* Add an optional mutex member to struct rtas_function.
* Statically define a mutex for each RTAS function with known call
sequence serialization requirements, and assign its address to the
.lock member of the corresponding function table entry, along with
justifying commentary.
* In sys_rtas(), if the table entry for the RTAS function being
called has a populated lock member, acquire it before taking
rtas_lock and entering RTAS.
* Kernel-based RTAS call sequences are expected to access the
appropriate mutex explicitly by name. For example, a user of the
ibm,activate-firmware RTAS function would do:
int token = rtas_function_token(RTAS_FN_IBM_ACTIVATE_FIRMWARE);
int fwrc;
mutex_lock(&rtas_ibm_activate_firmware_lock);
do {
fwrc = rtas_call(token, 0, 1, NULL);
} while (rtas_busy_delay(fwrc));
mutex_unlock(&rtas_ibm_activate_firmware_lock);
There should be no perceivable change introduced here except that
concurrent callers of the same RTAS function via sys_rtas() may block
on a mutex instead of spinning on rtas_lock.
Signed-off-by: Nathan Lynch <nathanl@linux.ibm.com>
Signed-off-by: Michael Ellerman <mpe@ellerman.id.au>
Link: https://msgid.link/20231212-papr-sys_rtas-vs-lockdown-v6-6-e9eafd0c8c6c@linux.ibm.com
2023-12-12 11:01:53 -06:00
|
|
|
|
/*
|
|
|
|
|
* PAPR+ as of v2.13 doesn't explicitly impose any
|
|
|
|
|
* restriction, but this typically requires multiple
|
|
|
|
|
* calls before success, and there's no reason to
|
|
|
|
|
* allow sequences to interleave.
|
|
|
|
|
*/
|
|
|
|
|
.lock = &rtas_ibm_activate_firmware_lock,
|
powerpc/rtas: improve function information lookups
The core RTAS support code and its clients perform two types of lookup
for RTAS firmware function information.
First, mapping a known function name to a token. The typical use case
invokes rtas_token() to retrieve the token value to pass to
rtas_call(). rtas_token() relies on of_get_property(), which performs
a linear search of the /rtas node's property list under a lock with
IRQs disabled.
Second, and less common: given a token value, looking up some
information about the function. The primary example is the sys_rtas
filter path, which linearly scans a small table to match the token to
a rtas_filter struct. Another use case to come is RTAS entry/exit
tracepoints, which will require efficient lookup of function names
from token values. Currently there is no general API for this.
We need something much like the existing rtas_filters table, but more
general and organized to facilitate efficient lookups.
Introduce:
* A new rtas_function type, aggregating function name, token,
and filter. Other function characteristics could be added in the
future.
* An array of rtas_function, where each element corresponds to a known
RTAS function. All information in the table is static save the token
values, which are derived from the device tree at boot. The array is
sorted by function name to allow binary search.
* A named constant for each known RTAS function, used to index the
function array. These also will be used in a client-facing API to be
added later.
* An xarray that maps valid tokens to rtas_function objects.
Fold the existing rtas_filter table into the new rtas_function array,
with the appropriate adjustments to block_rtas_call(). Remove
now-redundant fields from struct rtas_filter. Preserve the function of
the CONFIG_CPU_BIG_ENDIAN guard in the current filter table by
introducing a per-function flag that is set for the function entries
related to pseries LPAR migration. These have never had working users
via sys_rtas on ppc64le; see commit de0f7349a0dd ("powerpc/rtas:
prevent suspend-related sys_rtas use on LE").
Convert rtas_token() to use a lockless binary search on the function
table. Fall back to the old behavior for lookups against names that
are not known to be RTAS functions, but issue a warning. rtas_token()
is for function names; it is not a general facility for accessing
arbitrary properties of the /rtas node. All known misuses of
rtas_token() have been converted to more appropriate of_ APIs in
preceding changes.
Signed-off-by: Nathan Lynch <nathanl@linux.ibm.com>
Signed-off-by: Michael Ellerman <mpe@ellerman.id.au>
Link: https://lore.kernel.org/r/20230125-b4-powerpc-rtas-queue-v3-8-26929c8cce78@linux.ibm.com
2023-02-10 12:41:56 -06:00
|
|
|
|
},
|
|
|
|
|
[RTAS_FNIDX__IBM_CBE_START_PTCAL] = {
|
|
|
|
|
.name = "ibm,cbe-start-ptcal",
|
|
|
|
|
},
|
|
|
|
|
[RTAS_FNIDX__IBM_CBE_STOP_PTCAL] = {
|
|
|
|
|
.name = "ibm,cbe-stop-ptcal",
|
|
|
|
|
},
|
|
|
|
|
[RTAS_FNIDX__IBM_CHANGE_MSI] = {
|
|
|
|
|
.name = "ibm,change-msi",
|
|
|
|
|
},
|
|
|
|
|
[RTAS_FNIDX__IBM_CLOSE_ERRINJCT] = {
|
|
|
|
|
.name = "ibm,close-errinjct",
|
|
|
|
|
.filter = &(const struct rtas_filter) {
|
|
|
|
|
.buf_idx1 = -1, .size_idx1 = -1,
|
|
|
|
|
.buf_idx2 = -1, .size_idx2 = -1,
|
|
|
|
|
},
|
|
|
|
|
},
|
|
|
|
|
[RTAS_FNIDX__IBM_CONFIGURE_BRIDGE] = {
|
|
|
|
|
.name = "ibm,configure-bridge",
|
|
|
|
|
},
|
|
|
|
|
[RTAS_FNIDX__IBM_CONFIGURE_CONNECTOR] = {
|
|
|
|
|
.name = "ibm,configure-connector",
|
|
|
|
|
.filter = &(const struct rtas_filter) {
|
|
|
|
|
.buf_idx1 = 0, .size_idx1 = -1,
|
|
|
|
|
.buf_idx2 = 1, .size_idx2 = -1,
|
|
|
|
|
.fixed_size = 4096,
|
|
|
|
|
},
|
|
|
|
|
},
|
|
|
|
|
[RTAS_FNIDX__IBM_CONFIGURE_KERNEL_DUMP] = {
|
|
|
|
|
.name = "ibm,configure-kernel-dump",
|
|
|
|
|
},
|
|
|
|
|
[RTAS_FNIDX__IBM_CONFIGURE_PE] = {
|
|
|
|
|
.name = "ibm,configure-pe",
|
|
|
|
|
},
|
|
|
|
|
[RTAS_FNIDX__IBM_CREATE_PE_DMA_WINDOW] = {
|
|
|
|
|
.name = "ibm,create-pe-dma-window",
|
|
|
|
|
},
|
|
|
|
|
[RTAS_FNIDX__IBM_DISPLAY_MESSAGE] = {
|
|
|
|
|
.name = "ibm,display-message",
|
|
|
|
|
.filter = &(const struct rtas_filter) {
|
|
|
|
|
.buf_idx1 = 0, .size_idx1 = -1,
|
|
|
|
|
.buf_idx2 = -1, .size_idx2 = -1,
|
|
|
|
|
},
|
|
|
|
|
},
|
|
|
|
|
[RTAS_FNIDX__IBM_ERRINJCT] = {
|
|
|
|
|
.name = "ibm,errinjct",
|
|
|
|
|
.filter = &(const struct rtas_filter) {
|
|
|
|
|
.buf_idx1 = 2, .size_idx1 = -1,
|
|
|
|
|
.buf_idx2 = -1, .size_idx2 = -1,
|
|
|
|
|
.fixed_size = 1024,
|
|
|
|
|
},
|
|
|
|
|
},
|
|
|
|
|
[RTAS_FNIDX__IBM_EXTI2C] = {
|
|
|
|
|
.name = "ibm,exti2c",
|
|
|
|
|
},
|
|
|
|
|
[RTAS_FNIDX__IBM_GET_CONFIG_ADDR_INFO] = {
|
|
|
|
|
.name = "ibm,get-config-addr-info",
|
|
|
|
|
},
|
|
|
|
|
[RTAS_FNIDX__IBM_GET_CONFIG_ADDR_INFO2] = {
|
|
|
|
|
.name = "ibm,get-config-addr-info2",
|
|
|
|
|
.filter = &(const struct rtas_filter) {
|
|
|
|
|
.buf_idx1 = -1, .size_idx1 = -1,
|
|
|
|
|
.buf_idx2 = -1, .size_idx2 = -1,
|
|
|
|
|
},
|
|
|
|
|
},
|
|
|
|
|
[RTAS_FNIDX__IBM_GET_DYNAMIC_SENSOR_STATE] = {
|
|
|
|
|
.name = "ibm,get-dynamic-sensor-state",
|
|
|
|
|
.filter = &(const struct rtas_filter) {
|
|
|
|
|
.buf_idx1 = 1, .size_idx1 = -1,
|
|
|
|
|
.buf_idx2 = -1, .size_idx2 = -1,
|
|
|
|
|
},
|
powerpc/rtas: Facilitate high-level call sequences
On RTAS platforms there is a general restriction that the OS must not
enter RTAS on more than one CPU at a time. This low-level
serialization requirement is satisfied by holding a spin
lock (rtas_lock) across most RTAS function invocations.
However, some pseries RTAS functions require multiple successive calls
to complete a logical operation. Beginning a new call sequence for such a
function may disrupt any other sequences of that function already in
progress. Safe and reliable use of these functions effectively
requires higher-level serialization beyond what is already done at the
level of RTAS entry and exit.
Where a sequence-based RTAS function is invoked only through
sys_rtas(), with no in-kernel users, there is no issue as far as the
kernel is concerned. User space is responsible for appropriately
serializing its call sequences. (Whether user space code actually
takes measures to prevent sequence interleaving is another matter.)
Examples of such functions currently include ibm,platform-dump and
ibm,get-vpd.
But where a sequence-based RTAS function has both user space and
in-kernel uesrs, there is a hazard. Even if the in-kernel call sites
of such a function serialize their sequences correctly, a user of
sys_rtas() can invoke the same function at any time, potentially
disrupting a sequence in progress.
So in order to prevent disruption of kernel-based RTAS call sequences,
they must serialize not only with themselves but also with sys_rtas()
users, somehow. Preferably without adding more function-specific hacks
to sys_rtas(). This is a prerequisite for adding an in-kernel call
sequence of ibm,get-vpd, which is in a change to follow.
Note that it has never been feasible for the kernel to prevent
sys_rtas()-based sequences from being disrupted because control
returns to user space on every call. sys_rtas()-based users of these
functions have always been, and continue to be, responsible for
coordinating their call sequences with other users, even those which
may invoke the RTAS functions through less direct means than
sys_rtas(). This is an unavoidable consequence of exposing
sequence-based RTAS functions through sys_rtas().
* Add an optional mutex member to struct rtas_function.
* Statically define a mutex for each RTAS function with known call
sequence serialization requirements, and assign its address to the
.lock member of the corresponding function table entry, along with
justifying commentary.
* In sys_rtas(), if the table entry for the RTAS function being
called has a populated lock member, acquire it before taking
rtas_lock and entering RTAS.
* Kernel-based RTAS call sequences are expected to access the
appropriate mutex explicitly by name. For example, a user of the
ibm,activate-firmware RTAS function would do:
int token = rtas_function_token(RTAS_FN_IBM_ACTIVATE_FIRMWARE);
int fwrc;
mutex_lock(&rtas_ibm_activate_firmware_lock);
do {
fwrc = rtas_call(token, 0, 1, NULL);
} while (rtas_busy_delay(fwrc));
mutex_unlock(&rtas_ibm_activate_firmware_lock);
There should be no perceivable change introduced here except that
concurrent callers of the same RTAS function via sys_rtas() may block
on a mutex instead of spinning on rtas_lock.
Signed-off-by: Nathan Lynch <nathanl@linux.ibm.com>
Signed-off-by: Michael Ellerman <mpe@ellerman.id.au>
Link: https://msgid.link/20231212-papr-sys_rtas-vs-lockdown-v6-6-e9eafd0c8c6c@linux.ibm.com
2023-12-12 11:01:53 -06:00
|
|
|
|
/*
|
|
|
|
|
* PAPR+ v2.13 R1–7.3.19–3 is explicit that the OS
|
|
|
|
|
* must not call ibm,get-dynamic-sensor-state with
|
|
|
|
|
* different inputs until a non-retry status has been
|
|
|
|
|
* returned.
|
|
|
|
|
*/
|
|
|
|
|
.lock = &rtas_ibm_get_dynamic_sensor_state_lock,
|
powerpc/rtas: improve function information lookups
The core RTAS support code and its clients perform two types of lookup
for RTAS firmware function information.
First, mapping a known function name to a token. The typical use case
invokes rtas_token() to retrieve the token value to pass to
rtas_call(). rtas_token() relies on of_get_property(), which performs
a linear search of the /rtas node's property list under a lock with
IRQs disabled.
Second, and less common: given a token value, looking up some
information about the function. The primary example is the sys_rtas
filter path, which linearly scans a small table to match the token to
a rtas_filter struct. Another use case to come is RTAS entry/exit
tracepoints, which will require efficient lookup of function names
from token values. Currently there is no general API for this.
We need something much like the existing rtas_filters table, but more
general and organized to facilitate efficient lookups.
Introduce:
* A new rtas_function type, aggregating function name, token,
and filter. Other function characteristics could be added in the
future.
* An array of rtas_function, where each element corresponds to a known
RTAS function. All information in the table is static save the token
values, which are derived from the device tree at boot. The array is
sorted by function name to allow binary search.
* A named constant for each known RTAS function, used to index the
function array. These also will be used in a client-facing API to be
added later.
* An xarray that maps valid tokens to rtas_function objects.
Fold the existing rtas_filter table into the new rtas_function array,
with the appropriate adjustments to block_rtas_call(). Remove
now-redundant fields from struct rtas_filter. Preserve the function of
the CONFIG_CPU_BIG_ENDIAN guard in the current filter table by
introducing a per-function flag that is set for the function entries
related to pseries LPAR migration. These have never had working users
via sys_rtas on ppc64le; see commit de0f7349a0dd ("powerpc/rtas:
prevent suspend-related sys_rtas use on LE").
Convert rtas_token() to use a lockless binary search on the function
table. Fall back to the old behavior for lookups against names that
are not known to be RTAS functions, but issue a warning. rtas_token()
is for function names; it is not a general facility for accessing
arbitrary properties of the /rtas node. All known misuses of
rtas_token() have been converted to more appropriate of_ APIs in
preceding changes.
Signed-off-by: Nathan Lynch <nathanl@linux.ibm.com>
Signed-off-by: Michael Ellerman <mpe@ellerman.id.au>
Link: https://lore.kernel.org/r/20230125-b4-powerpc-rtas-queue-v3-8-26929c8cce78@linux.ibm.com
2023-02-10 12:41:56 -06:00
|
|
|
|
},
|
|
|
|
|
[RTAS_FNIDX__IBM_GET_INDICES] = {
|
|
|
|
|
.name = "ibm,get-indices",
|
|
|
|
|
.filter = &(const struct rtas_filter) {
|
|
|
|
|
.buf_idx1 = 2, .size_idx1 = 3,
|
|
|
|
|
.buf_idx2 = -1, .size_idx2 = -1,
|
|
|
|
|
},
|
powerpc/rtas: Facilitate high-level call sequences
On RTAS platforms there is a general restriction that the OS must not
enter RTAS on more than one CPU at a time. This low-level
serialization requirement is satisfied by holding a spin
lock (rtas_lock) across most RTAS function invocations.
However, some pseries RTAS functions require multiple successive calls
to complete a logical operation. Beginning a new call sequence for such a
function may disrupt any other sequences of that function already in
progress. Safe and reliable use of these functions effectively
requires higher-level serialization beyond what is already done at the
level of RTAS entry and exit.
Where a sequence-based RTAS function is invoked only through
sys_rtas(), with no in-kernel users, there is no issue as far as the
kernel is concerned. User space is responsible for appropriately
serializing its call sequences. (Whether user space code actually
takes measures to prevent sequence interleaving is another matter.)
Examples of such functions currently include ibm,platform-dump and
ibm,get-vpd.
But where a sequence-based RTAS function has both user space and
in-kernel uesrs, there is a hazard. Even if the in-kernel call sites
of such a function serialize their sequences correctly, a user of
sys_rtas() can invoke the same function at any time, potentially
disrupting a sequence in progress.
So in order to prevent disruption of kernel-based RTAS call sequences,
they must serialize not only with themselves but also with sys_rtas()
users, somehow. Preferably without adding more function-specific hacks
to sys_rtas(). This is a prerequisite for adding an in-kernel call
sequence of ibm,get-vpd, which is in a change to follow.
Note that it has never been feasible for the kernel to prevent
sys_rtas()-based sequences from being disrupted because control
returns to user space on every call. sys_rtas()-based users of these
functions have always been, and continue to be, responsible for
coordinating their call sequences with other users, even those which
may invoke the RTAS functions through less direct means than
sys_rtas(). This is an unavoidable consequence of exposing
sequence-based RTAS functions through sys_rtas().
* Add an optional mutex member to struct rtas_function.
* Statically define a mutex for each RTAS function with known call
sequence serialization requirements, and assign its address to the
.lock member of the corresponding function table entry, along with
justifying commentary.
* In sys_rtas(), if the table entry for the RTAS function being
called has a populated lock member, acquire it before taking
rtas_lock and entering RTAS.
* Kernel-based RTAS call sequences are expected to access the
appropriate mutex explicitly by name. For example, a user of the
ibm,activate-firmware RTAS function would do:
int token = rtas_function_token(RTAS_FN_IBM_ACTIVATE_FIRMWARE);
int fwrc;
mutex_lock(&rtas_ibm_activate_firmware_lock);
do {
fwrc = rtas_call(token, 0, 1, NULL);
} while (rtas_busy_delay(fwrc));
mutex_unlock(&rtas_ibm_activate_firmware_lock);
There should be no perceivable change introduced here except that
concurrent callers of the same RTAS function via sys_rtas() may block
on a mutex instead of spinning on rtas_lock.
Signed-off-by: Nathan Lynch <nathanl@linux.ibm.com>
Signed-off-by: Michael Ellerman <mpe@ellerman.id.au>
Link: https://msgid.link/20231212-papr-sys_rtas-vs-lockdown-v6-6-e9eafd0c8c6c@linux.ibm.com
2023-12-12 11:01:53 -06:00
|
|
|
|
/*
|
|
|
|
|
* PAPR+ v2.13 R1–7.3.17–2 says that the OS must not
|
|
|
|
|
* interleave ibm,get-indices call sequences with
|
|
|
|
|
* different inputs.
|
|
|
|
|
*/
|
|
|
|
|
.lock = &rtas_ibm_get_indices_lock,
|
powerpc/rtas: improve function information lookups
The core RTAS support code and its clients perform two types of lookup
for RTAS firmware function information.
First, mapping a known function name to a token. The typical use case
invokes rtas_token() to retrieve the token value to pass to
rtas_call(). rtas_token() relies on of_get_property(), which performs
a linear search of the /rtas node's property list under a lock with
IRQs disabled.
Second, and less common: given a token value, looking up some
information about the function. The primary example is the sys_rtas
filter path, which linearly scans a small table to match the token to
a rtas_filter struct. Another use case to come is RTAS entry/exit
tracepoints, which will require efficient lookup of function names
from token values. Currently there is no general API for this.
We need something much like the existing rtas_filters table, but more
general and organized to facilitate efficient lookups.
Introduce:
* A new rtas_function type, aggregating function name, token,
and filter. Other function characteristics could be added in the
future.
* An array of rtas_function, where each element corresponds to a known
RTAS function. All information in the table is static save the token
values, which are derived from the device tree at boot. The array is
sorted by function name to allow binary search.
* A named constant for each known RTAS function, used to index the
function array. These also will be used in a client-facing API to be
added later.
* An xarray that maps valid tokens to rtas_function objects.
Fold the existing rtas_filter table into the new rtas_function array,
with the appropriate adjustments to block_rtas_call(). Remove
now-redundant fields from struct rtas_filter. Preserve the function of
the CONFIG_CPU_BIG_ENDIAN guard in the current filter table by
introducing a per-function flag that is set for the function entries
related to pseries LPAR migration. These have never had working users
via sys_rtas on ppc64le; see commit de0f7349a0dd ("powerpc/rtas:
prevent suspend-related sys_rtas use on LE").
Convert rtas_token() to use a lockless binary search on the function
table. Fall back to the old behavior for lookups against names that
are not known to be RTAS functions, but issue a warning. rtas_token()
is for function names; it is not a general facility for accessing
arbitrary properties of the /rtas node. All known misuses of
rtas_token() have been converted to more appropriate of_ APIs in
preceding changes.
Signed-off-by: Nathan Lynch <nathanl@linux.ibm.com>
Signed-off-by: Michael Ellerman <mpe@ellerman.id.au>
Link: https://lore.kernel.org/r/20230125-b4-powerpc-rtas-queue-v3-8-26929c8cce78@linux.ibm.com
2023-02-10 12:41:56 -06:00
|
|
|
|
},
|
|
|
|
|
[RTAS_FNIDX__IBM_GET_RIO_TOPOLOGY] = {
|
|
|
|
|
.name = "ibm,get-rio-topology",
|
|
|
|
|
},
|
|
|
|
|
[RTAS_FNIDX__IBM_GET_SYSTEM_PARAMETER] = {
|
|
|
|
|
.name = "ibm,get-system-parameter",
|
|
|
|
|
.filter = &(const struct rtas_filter) {
|
|
|
|
|
.buf_idx1 = 1, .size_idx1 = 2,
|
|
|
|
|
.buf_idx2 = -1, .size_idx2 = -1,
|
|
|
|
|
},
|
|
|
|
|
},
|
|
|
|
|
[RTAS_FNIDX__IBM_GET_VPD] = {
|
|
|
|
|
.name = "ibm,get-vpd",
|
|
|
|
|
.filter = &(const struct rtas_filter) {
|
|
|
|
|
.buf_idx1 = 0, .size_idx1 = -1,
|
|
|
|
|
.buf_idx2 = 1, .size_idx2 = 2,
|
|
|
|
|
},
|
powerpc/rtas: Facilitate high-level call sequences
On RTAS platforms there is a general restriction that the OS must not
enter RTAS on more than one CPU at a time. This low-level
serialization requirement is satisfied by holding a spin
lock (rtas_lock) across most RTAS function invocations.
However, some pseries RTAS functions require multiple successive calls
to complete a logical operation. Beginning a new call sequence for such a
function may disrupt any other sequences of that function already in
progress. Safe and reliable use of these functions effectively
requires higher-level serialization beyond what is already done at the
level of RTAS entry and exit.
Where a sequence-based RTAS function is invoked only through
sys_rtas(), with no in-kernel users, there is no issue as far as the
kernel is concerned. User space is responsible for appropriately
serializing its call sequences. (Whether user space code actually
takes measures to prevent sequence interleaving is another matter.)
Examples of such functions currently include ibm,platform-dump and
ibm,get-vpd.
But where a sequence-based RTAS function has both user space and
in-kernel uesrs, there is a hazard. Even if the in-kernel call sites
of such a function serialize their sequences correctly, a user of
sys_rtas() can invoke the same function at any time, potentially
disrupting a sequence in progress.
So in order to prevent disruption of kernel-based RTAS call sequences,
they must serialize not only with themselves but also with sys_rtas()
users, somehow. Preferably without adding more function-specific hacks
to sys_rtas(). This is a prerequisite for adding an in-kernel call
sequence of ibm,get-vpd, which is in a change to follow.
Note that it has never been feasible for the kernel to prevent
sys_rtas()-based sequences from being disrupted because control
returns to user space on every call. sys_rtas()-based users of these
functions have always been, and continue to be, responsible for
coordinating their call sequences with other users, even those which
may invoke the RTAS functions through less direct means than
sys_rtas(). This is an unavoidable consequence of exposing
sequence-based RTAS functions through sys_rtas().
* Add an optional mutex member to struct rtas_function.
* Statically define a mutex for each RTAS function with known call
sequence serialization requirements, and assign its address to the
.lock member of the corresponding function table entry, along with
justifying commentary.
* In sys_rtas(), if the table entry for the RTAS function being
called has a populated lock member, acquire it before taking
rtas_lock and entering RTAS.
* Kernel-based RTAS call sequences are expected to access the
appropriate mutex explicitly by name. For example, a user of the
ibm,activate-firmware RTAS function would do:
int token = rtas_function_token(RTAS_FN_IBM_ACTIVATE_FIRMWARE);
int fwrc;
mutex_lock(&rtas_ibm_activate_firmware_lock);
do {
fwrc = rtas_call(token, 0, 1, NULL);
} while (rtas_busy_delay(fwrc));
mutex_unlock(&rtas_ibm_activate_firmware_lock);
There should be no perceivable change introduced here except that
concurrent callers of the same RTAS function via sys_rtas() may block
on a mutex instead of spinning on rtas_lock.
Signed-off-by: Nathan Lynch <nathanl@linux.ibm.com>
Signed-off-by: Michael Ellerman <mpe@ellerman.id.au>
Link: https://msgid.link/20231212-papr-sys_rtas-vs-lockdown-v6-6-e9eafd0c8c6c@linux.ibm.com
2023-12-12 11:01:53 -06:00
|
|
|
|
/*
|
|
|
|
|
* PAPR+ v2.13 R1–7.3.20–4 indicates that sequences
|
|
|
|
|
* should not be allowed to interleave.
|
|
|
|
|
*/
|
|
|
|
|
.lock = &rtas_ibm_get_vpd_lock,
|
powerpc/rtas: improve function information lookups
The core RTAS support code and its clients perform two types of lookup
for RTAS firmware function information.
First, mapping a known function name to a token. The typical use case
invokes rtas_token() to retrieve the token value to pass to
rtas_call(). rtas_token() relies on of_get_property(), which performs
a linear search of the /rtas node's property list under a lock with
IRQs disabled.
Second, and less common: given a token value, looking up some
information about the function. The primary example is the sys_rtas
filter path, which linearly scans a small table to match the token to
a rtas_filter struct. Another use case to come is RTAS entry/exit
tracepoints, which will require efficient lookup of function names
from token values. Currently there is no general API for this.
We need something much like the existing rtas_filters table, but more
general and organized to facilitate efficient lookups.
Introduce:
* A new rtas_function type, aggregating function name, token,
and filter. Other function characteristics could be added in the
future.
* An array of rtas_function, where each element corresponds to a known
RTAS function. All information in the table is static save the token
values, which are derived from the device tree at boot. The array is
sorted by function name to allow binary search.
* A named constant for each known RTAS function, used to index the
function array. These also will be used in a client-facing API to be
added later.
* An xarray that maps valid tokens to rtas_function objects.
Fold the existing rtas_filter table into the new rtas_function array,
with the appropriate adjustments to block_rtas_call(). Remove
now-redundant fields from struct rtas_filter. Preserve the function of
the CONFIG_CPU_BIG_ENDIAN guard in the current filter table by
introducing a per-function flag that is set for the function entries
related to pseries LPAR migration. These have never had working users
via sys_rtas on ppc64le; see commit de0f7349a0dd ("powerpc/rtas:
prevent suspend-related sys_rtas use on LE").
Convert rtas_token() to use a lockless binary search on the function
table. Fall back to the old behavior for lookups against names that
are not known to be RTAS functions, but issue a warning. rtas_token()
is for function names; it is not a general facility for accessing
arbitrary properties of the /rtas node. All known misuses of
rtas_token() have been converted to more appropriate of_ APIs in
preceding changes.
Signed-off-by: Nathan Lynch <nathanl@linux.ibm.com>
Signed-off-by: Michael Ellerman <mpe@ellerman.id.au>
Link: https://lore.kernel.org/r/20230125-b4-powerpc-rtas-queue-v3-8-26929c8cce78@linux.ibm.com
2023-02-10 12:41:56 -06:00
|
|
|
|
},
|
|
|
|
|
[RTAS_FNIDX__IBM_GET_XIVE] = {
|
|
|
|
|
.name = "ibm,get-xive",
|
|
|
|
|
},
|
|
|
|
|
[RTAS_FNIDX__IBM_INT_OFF] = {
|
|
|
|
|
.name = "ibm,int-off",
|
|
|
|
|
},
|
|
|
|
|
[RTAS_FNIDX__IBM_INT_ON] = {
|
|
|
|
|
.name = "ibm,int-on",
|
|
|
|
|
},
|
|
|
|
|
[RTAS_FNIDX__IBM_IO_QUIESCE_ACK] = {
|
|
|
|
|
.name = "ibm,io-quiesce-ack",
|
|
|
|
|
},
|
|
|
|
|
[RTAS_FNIDX__IBM_LPAR_PERFTOOLS] = {
|
|
|
|
|
.name = "ibm,lpar-perftools",
|
|
|
|
|
.filter = &(const struct rtas_filter) {
|
|
|
|
|
.buf_idx1 = 2, .size_idx1 = 3,
|
|
|
|
|
.buf_idx2 = -1, .size_idx2 = -1,
|
|
|
|
|
},
|
powerpc/rtas: Facilitate high-level call sequences
On RTAS platforms there is a general restriction that the OS must not
enter RTAS on more than one CPU at a time. This low-level
serialization requirement is satisfied by holding a spin
lock (rtas_lock) across most RTAS function invocations.
However, some pseries RTAS functions require multiple successive calls
to complete a logical operation. Beginning a new call sequence for such a
function may disrupt any other sequences of that function already in
progress. Safe and reliable use of these functions effectively
requires higher-level serialization beyond what is already done at the
level of RTAS entry and exit.
Where a sequence-based RTAS function is invoked only through
sys_rtas(), with no in-kernel users, there is no issue as far as the
kernel is concerned. User space is responsible for appropriately
serializing its call sequences. (Whether user space code actually
takes measures to prevent sequence interleaving is another matter.)
Examples of such functions currently include ibm,platform-dump and
ibm,get-vpd.
But where a sequence-based RTAS function has both user space and
in-kernel uesrs, there is a hazard. Even if the in-kernel call sites
of such a function serialize their sequences correctly, a user of
sys_rtas() can invoke the same function at any time, potentially
disrupting a sequence in progress.
So in order to prevent disruption of kernel-based RTAS call sequences,
they must serialize not only with themselves but also with sys_rtas()
users, somehow. Preferably without adding more function-specific hacks
to sys_rtas(). This is a prerequisite for adding an in-kernel call
sequence of ibm,get-vpd, which is in a change to follow.
Note that it has never been feasible for the kernel to prevent
sys_rtas()-based sequences from being disrupted because control
returns to user space on every call. sys_rtas()-based users of these
functions have always been, and continue to be, responsible for
coordinating their call sequences with other users, even those which
may invoke the RTAS functions through less direct means than
sys_rtas(). This is an unavoidable consequence of exposing
sequence-based RTAS functions through sys_rtas().
* Add an optional mutex member to struct rtas_function.
* Statically define a mutex for each RTAS function with known call
sequence serialization requirements, and assign its address to the
.lock member of the corresponding function table entry, along with
justifying commentary.
* In sys_rtas(), if the table entry for the RTAS function being
called has a populated lock member, acquire it before taking
rtas_lock and entering RTAS.
* Kernel-based RTAS call sequences are expected to access the
appropriate mutex explicitly by name. For example, a user of the
ibm,activate-firmware RTAS function would do:
int token = rtas_function_token(RTAS_FN_IBM_ACTIVATE_FIRMWARE);
int fwrc;
mutex_lock(&rtas_ibm_activate_firmware_lock);
do {
fwrc = rtas_call(token, 0, 1, NULL);
} while (rtas_busy_delay(fwrc));
mutex_unlock(&rtas_ibm_activate_firmware_lock);
There should be no perceivable change introduced here except that
concurrent callers of the same RTAS function via sys_rtas() may block
on a mutex instead of spinning on rtas_lock.
Signed-off-by: Nathan Lynch <nathanl@linux.ibm.com>
Signed-off-by: Michael Ellerman <mpe@ellerman.id.au>
Link: https://msgid.link/20231212-papr-sys_rtas-vs-lockdown-v6-6-e9eafd0c8c6c@linux.ibm.com
2023-12-12 11:01:53 -06:00
|
|
|
|
/*
|
|
|
|
|
* PAPR+ v2.13 R1–7.3.26–6 says the OS should allow
|
|
|
|
|
* only one call sequence in progress at a time.
|
|
|
|
|
*/
|
|
|
|
|
.lock = &rtas_ibm_lpar_perftools_lock,
|
powerpc/rtas: improve function information lookups
The core RTAS support code and its clients perform two types of lookup
for RTAS firmware function information.
First, mapping a known function name to a token. The typical use case
invokes rtas_token() to retrieve the token value to pass to
rtas_call(). rtas_token() relies on of_get_property(), which performs
a linear search of the /rtas node's property list under a lock with
IRQs disabled.
Second, and less common: given a token value, looking up some
information about the function. The primary example is the sys_rtas
filter path, which linearly scans a small table to match the token to
a rtas_filter struct. Another use case to come is RTAS entry/exit
tracepoints, which will require efficient lookup of function names
from token values. Currently there is no general API for this.
We need something much like the existing rtas_filters table, but more
general and organized to facilitate efficient lookups.
Introduce:
* A new rtas_function type, aggregating function name, token,
and filter. Other function characteristics could be added in the
future.
* An array of rtas_function, where each element corresponds to a known
RTAS function. All information in the table is static save the token
values, which are derived from the device tree at boot. The array is
sorted by function name to allow binary search.
* A named constant for each known RTAS function, used to index the
function array. These also will be used in a client-facing API to be
added later.
* An xarray that maps valid tokens to rtas_function objects.
Fold the existing rtas_filter table into the new rtas_function array,
with the appropriate adjustments to block_rtas_call(). Remove
now-redundant fields from struct rtas_filter. Preserve the function of
the CONFIG_CPU_BIG_ENDIAN guard in the current filter table by
introducing a per-function flag that is set for the function entries
related to pseries LPAR migration. These have never had working users
via sys_rtas on ppc64le; see commit de0f7349a0dd ("powerpc/rtas:
prevent suspend-related sys_rtas use on LE").
Convert rtas_token() to use a lockless binary search on the function
table. Fall back to the old behavior for lookups against names that
are not known to be RTAS functions, but issue a warning. rtas_token()
is for function names; it is not a general facility for accessing
arbitrary properties of the /rtas node. All known misuses of
rtas_token() have been converted to more appropriate of_ APIs in
preceding changes.
Signed-off-by: Nathan Lynch <nathanl@linux.ibm.com>
Signed-off-by: Michael Ellerman <mpe@ellerman.id.au>
Link: https://lore.kernel.org/r/20230125-b4-powerpc-rtas-queue-v3-8-26929c8cce78@linux.ibm.com
2023-02-10 12:41:56 -06:00
|
|
|
|
},
|
|
|
|
|
[RTAS_FNIDX__IBM_MANAGE_FLASH_IMAGE] = {
|
|
|
|
|
.name = "ibm,manage-flash-image",
|
|
|
|
|
},
|
|
|
|
|
[RTAS_FNIDX__IBM_MANAGE_STORAGE_PRESERVATION] = {
|
|
|
|
|
.name = "ibm,manage-storage-preservation",
|
|
|
|
|
},
|
|
|
|
|
[RTAS_FNIDX__IBM_NMI_INTERLOCK] = {
|
|
|
|
|
.name = "ibm,nmi-interlock",
|
|
|
|
|
},
|
|
|
|
|
[RTAS_FNIDX__IBM_NMI_REGISTER] = {
|
|
|
|
|
.name = "ibm,nmi-register",
|
|
|
|
|
},
|
|
|
|
|
[RTAS_FNIDX__IBM_OPEN_ERRINJCT] = {
|
|
|
|
|
.name = "ibm,open-errinjct",
|
|
|
|
|
.filter = &(const struct rtas_filter) {
|
|
|
|
|
.buf_idx1 = -1, .size_idx1 = -1,
|
|
|
|
|
.buf_idx2 = -1, .size_idx2 = -1,
|
|
|
|
|
},
|
|
|
|
|
},
|
|
|
|
|
[RTAS_FNIDX__IBM_OPEN_SRIOV_ALLOW_UNFREEZE] = {
|
|
|
|
|
.name = "ibm,open-sriov-allow-unfreeze",
|
|
|
|
|
},
|
|
|
|
|
[RTAS_FNIDX__IBM_OPEN_SRIOV_MAP_PE_NUMBER] = {
|
|
|
|
|
.name = "ibm,open-sriov-map-pe-number",
|
|
|
|
|
},
|
|
|
|
|
[RTAS_FNIDX__IBM_OS_TERM] = {
|
|
|
|
|
.name = "ibm,os-term",
|
|
|
|
|
},
|
|
|
|
|
[RTAS_FNIDX__IBM_PARTNER_CONTROL] = {
|
|
|
|
|
.name = "ibm,partner-control",
|
|
|
|
|
},
|
|
|
|
|
[RTAS_FNIDX__IBM_PHYSICAL_ATTESTATION] = {
|
|
|
|
|
.name = "ibm,physical-attestation",
|
|
|
|
|
.filter = &(const struct rtas_filter) {
|
|
|
|
|
.buf_idx1 = 0, .size_idx1 = 1,
|
|
|
|
|
.buf_idx2 = -1, .size_idx2 = -1,
|
|
|
|
|
},
|
powerpc/rtas: Facilitate high-level call sequences
On RTAS platforms there is a general restriction that the OS must not
enter RTAS on more than one CPU at a time. This low-level
serialization requirement is satisfied by holding a spin
lock (rtas_lock) across most RTAS function invocations.
However, some pseries RTAS functions require multiple successive calls
to complete a logical operation. Beginning a new call sequence for such a
function may disrupt any other sequences of that function already in
progress. Safe and reliable use of these functions effectively
requires higher-level serialization beyond what is already done at the
level of RTAS entry and exit.
Where a sequence-based RTAS function is invoked only through
sys_rtas(), with no in-kernel users, there is no issue as far as the
kernel is concerned. User space is responsible for appropriately
serializing its call sequences. (Whether user space code actually
takes measures to prevent sequence interleaving is another matter.)
Examples of such functions currently include ibm,platform-dump and
ibm,get-vpd.
But where a sequence-based RTAS function has both user space and
in-kernel uesrs, there is a hazard. Even if the in-kernel call sites
of such a function serialize their sequences correctly, a user of
sys_rtas() can invoke the same function at any time, potentially
disrupting a sequence in progress.
So in order to prevent disruption of kernel-based RTAS call sequences,
they must serialize not only with themselves but also with sys_rtas()
users, somehow. Preferably without adding more function-specific hacks
to sys_rtas(). This is a prerequisite for adding an in-kernel call
sequence of ibm,get-vpd, which is in a change to follow.
Note that it has never been feasible for the kernel to prevent
sys_rtas()-based sequences from being disrupted because control
returns to user space on every call. sys_rtas()-based users of these
functions have always been, and continue to be, responsible for
coordinating their call sequences with other users, even those which
may invoke the RTAS functions through less direct means than
sys_rtas(). This is an unavoidable consequence of exposing
sequence-based RTAS functions through sys_rtas().
* Add an optional mutex member to struct rtas_function.
* Statically define a mutex for each RTAS function with known call
sequence serialization requirements, and assign its address to the
.lock member of the corresponding function table entry, along with
justifying commentary.
* In sys_rtas(), if the table entry for the RTAS function being
called has a populated lock member, acquire it before taking
rtas_lock and entering RTAS.
* Kernel-based RTAS call sequences are expected to access the
appropriate mutex explicitly by name. For example, a user of the
ibm,activate-firmware RTAS function would do:
int token = rtas_function_token(RTAS_FN_IBM_ACTIVATE_FIRMWARE);
int fwrc;
mutex_lock(&rtas_ibm_activate_firmware_lock);
do {
fwrc = rtas_call(token, 0, 1, NULL);
} while (rtas_busy_delay(fwrc));
mutex_unlock(&rtas_ibm_activate_firmware_lock);
There should be no perceivable change introduced here except that
concurrent callers of the same RTAS function via sys_rtas() may block
on a mutex instead of spinning on rtas_lock.
Signed-off-by: Nathan Lynch <nathanl@linux.ibm.com>
Signed-off-by: Michael Ellerman <mpe@ellerman.id.au>
Link: https://msgid.link/20231212-papr-sys_rtas-vs-lockdown-v6-6-e9eafd0c8c6c@linux.ibm.com
2023-12-12 11:01:53 -06:00
|
|
|
|
/*
|
|
|
|
|
* This follows a sequence-based pattern similar to
|
|
|
|
|
* ibm,get-vpd et al. Since PAPR+ restricts
|
|
|
|
|
* interleaving call sequences for other functions of
|
|
|
|
|
* this style, assume the restriction applies here,
|
|
|
|
|
* even though it's not explicit in the spec.
|
|
|
|
|
*/
|
|
|
|
|
.lock = &rtas_ibm_physical_attestation_lock,
|
powerpc/rtas: improve function information lookups
The core RTAS support code and its clients perform two types of lookup
for RTAS firmware function information.
First, mapping a known function name to a token. The typical use case
invokes rtas_token() to retrieve the token value to pass to
rtas_call(). rtas_token() relies on of_get_property(), which performs
a linear search of the /rtas node's property list under a lock with
IRQs disabled.
Second, and less common: given a token value, looking up some
information about the function. The primary example is the sys_rtas
filter path, which linearly scans a small table to match the token to
a rtas_filter struct. Another use case to come is RTAS entry/exit
tracepoints, which will require efficient lookup of function names
from token values. Currently there is no general API for this.
We need something much like the existing rtas_filters table, but more
general and organized to facilitate efficient lookups.
Introduce:
* A new rtas_function type, aggregating function name, token,
and filter. Other function characteristics could be added in the
future.
* An array of rtas_function, where each element corresponds to a known
RTAS function. All information in the table is static save the token
values, which are derived from the device tree at boot. The array is
sorted by function name to allow binary search.
* A named constant for each known RTAS function, used to index the
function array. These also will be used in a client-facing API to be
added later.
* An xarray that maps valid tokens to rtas_function objects.
Fold the existing rtas_filter table into the new rtas_function array,
with the appropriate adjustments to block_rtas_call(). Remove
now-redundant fields from struct rtas_filter. Preserve the function of
the CONFIG_CPU_BIG_ENDIAN guard in the current filter table by
introducing a per-function flag that is set for the function entries
related to pseries LPAR migration. These have never had working users
via sys_rtas on ppc64le; see commit de0f7349a0dd ("powerpc/rtas:
prevent suspend-related sys_rtas use on LE").
Convert rtas_token() to use a lockless binary search on the function
table. Fall back to the old behavior for lookups against names that
are not known to be RTAS functions, but issue a warning. rtas_token()
is for function names; it is not a general facility for accessing
arbitrary properties of the /rtas node. All known misuses of
rtas_token() have been converted to more appropriate of_ APIs in
preceding changes.
Signed-off-by: Nathan Lynch <nathanl@linux.ibm.com>
Signed-off-by: Michael Ellerman <mpe@ellerman.id.au>
Link: https://lore.kernel.org/r/20230125-b4-powerpc-rtas-queue-v3-8-26929c8cce78@linux.ibm.com
2023-02-10 12:41:56 -06:00
|
|
|
|
},
|
|
|
|
|
[RTAS_FNIDX__IBM_PLATFORM_DUMP] = {
|
|
|
|
|
.name = "ibm,platform-dump",
|
|
|
|
|
.filter = &(const struct rtas_filter) {
|
|
|
|
|
.buf_idx1 = 4, .size_idx1 = 5,
|
|
|
|
|
.buf_idx2 = -1, .size_idx2 = -1,
|
|
|
|
|
},
|
powerpc/rtas: Facilitate high-level call sequences
On RTAS platforms there is a general restriction that the OS must not
enter RTAS on more than one CPU at a time. This low-level
serialization requirement is satisfied by holding a spin
lock (rtas_lock) across most RTAS function invocations.
However, some pseries RTAS functions require multiple successive calls
to complete a logical operation. Beginning a new call sequence for such a
function may disrupt any other sequences of that function already in
progress. Safe and reliable use of these functions effectively
requires higher-level serialization beyond what is already done at the
level of RTAS entry and exit.
Where a sequence-based RTAS function is invoked only through
sys_rtas(), with no in-kernel users, there is no issue as far as the
kernel is concerned. User space is responsible for appropriately
serializing its call sequences. (Whether user space code actually
takes measures to prevent sequence interleaving is another matter.)
Examples of such functions currently include ibm,platform-dump and
ibm,get-vpd.
But where a sequence-based RTAS function has both user space and
in-kernel uesrs, there is a hazard. Even if the in-kernel call sites
of such a function serialize their sequences correctly, a user of
sys_rtas() can invoke the same function at any time, potentially
disrupting a sequence in progress.
So in order to prevent disruption of kernel-based RTAS call sequences,
they must serialize not only with themselves but also with sys_rtas()
users, somehow. Preferably without adding more function-specific hacks
to sys_rtas(). This is a prerequisite for adding an in-kernel call
sequence of ibm,get-vpd, which is in a change to follow.
Note that it has never been feasible for the kernel to prevent
sys_rtas()-based sequences from being disrupted because control
returns to user space on every call. sys_rtas()-based users of these
functions have always been, and continue to be, responsible for
coordinating their call sequences with other users, even those which
may invoke the RTAS functions through less direct means than
sys_rtas(). This is an unavoidable consequence of exposing
sequence-based RTAS functions through sys_rtas().
* Add an optional mutex member to struct rtas_function.
* Statically define a mutex for each RTAS function with known call
sequence serialization requirements, and assign its address to the
.lock member of the corresponding function table entry, along with
justifying commentary.
* In sys_rtas(), if the table entry for the RTAS function being
called has a populated lock member, acquire it before taking
rtas_lock and entering RTAS.
* Kernel-based RTAS call sequences are expected to access the
appropriate mutex explicitly by name. For example, a user of the
ibm,activate-firmware RTAS function would do:
int token = rtas_function_token(RTAS_FN_IBM_ACTIVATE_FIRMWARE);
int fwrc;
mutex_lock(&rtas_ibm_activate_firmware_lock);
do {
fwrc = rtas_call(token, 0, 1, NULL);
} while (rtas_busy_delay(fwrc));
mutex_unlock(&rtas_ibm_activate_firmware_lock);
There should be no perceivable change introduced here except that
concurrent callers of the same RTAS function via sys_rtas() may block
on a mutex instead of spinning on rtas_lock.
Signed-off-by: Nathan Lynch <nathanl@linux.ibm.com>
Signed-off-by: Michael Ellerman <mpe@ellerman.id.au>
Link: https://msgid.link/20231212-papr-sys_rtas-vs-lockdown-v6-6-e9eafd0c8c6c@linux.ibm.com
2023-12-12 11:01:53 -06:00
|
|
|
|
/*
|
|
|
|
|
* PAPR+ v2.13 7.3.3.4.1 indicates that concurrent
|
|
|
|
|
* sequences of ibm,platform-dump are allowed if they
|
|
|
|
|
* are operating on different dump tags. So leave the
|
|
|
|
|
* lock pointer unset for now. This may need
|
|
|
|
|
* reconsideration if kernel-internal users appear.
|
|
|
|
|
*/
|
powerpc/rtas: improve function information lookups
The core RTAS support code and its clients perform two types of lookup
for RTAS firmware function information.
First, mapping a known function name to a token. The typical use case
invokes rtas_token() to retrieve the token value to pass to
rtas_call(). rtas_token() relies on of_get_property(), which performs
a linear search of the /rtas node's property list under a lock with
IRQs disabled.
Second, and less common: given a token value, looking up some
information about the function. The primary example is the sys_rtas
filter path, which linearly scans a small table to match the token to
a rtas_filter struct. Another use case to come is RTAS entry/exit
tracepoints, which will require efficient lookup of function names
from token values. Currently there is no general API for this.
We need something much like the existing rtas_filters table, but more
general and organized to facilitate efficient lookups.
Introduce:
* A new rtas_function type, aggregating function name, token,
and filter. Other function characteristics could be added in the
future.
* An array of rtas_function, where each element corresponds to a known
RTAS function. All information in the table is static save the token
values, which are derived from the device tree at boot. The array is
sorted by function name to allow binary search.
* A named constant for each known RTAS function, used to index the
function array. These also will be used in a client-facing API to be
added later.
* An xarray that maps valid tokens to rtas_function objects.
Fold the existing rtas_filter table into the new rtas_function array,
with the appropriate adjustments to block_rtas_call(). Remove
now-redundant fields from struct rtas_filter. Preserve the function of
the CONFIG_CPU_BIG_ENDIAN guard in the current filter table by
introducing a per-function flag that is set for the function entries
related to pseries LPAR migration. These have never had working users
via sys_rtas on ppc64le; see commit de0f7349a0dd ("powerpc/rtas:
prevent suspend-related sys_rtas use on LE").
Convert rtas_token() to use a lockless binary search on the function
table. Fall back to the old behavior for lookups against names that
are not known to be RTAS functions, but issue a warning. rtas_token()
is for function names; it is not a general facility for accessing
arbitrary properties of the /rtas node. All known misuses of
rtas_token() have been converted to more appropriate of_ APIs in
preceding changes.
Signed-off-by: Nathan Lynch <nathanl@linux.ibm.com>
Signed-off-by: Michael Ellerman <mpe@ellerman.id.au>
Link: https://lore.kernel.org/r/20230125-b4-powerpc-rtas-queue-v3-8-26929c8cce78@linux.ibm.com
2023-02-10 12:41:56 -06:00
|
|
|
|
},
|
|
|
|
|
[RTAS_FNIDX__IBM_POWER_OFF_UPS] = {
|
|
|
|
|
.name = "ibm,power-off-ups",
|
|
|
|
|
},
|
|
|
|
|
[RTAS_FNIDX__IBM_QUERY_INTERRUPT_SOURCE_NUMBER] = {
|
|
|
|
|
.name = "ibm,query-interrupt-source-number",
|
|
|
|
|
},
|
|
|
|
|
[RTAS_FNIDX__IBM_QUERY_PE_DMA_WINDOW] = {
|
|
|
|
|
.name = "ibm,query-pe-dma-window",
|
|
|
|
|
},
|
|
|
|
|
[RTAS_FNIDX__IBM_READ_PCI_CONFIG] = {
|
|
|
|
|
.name = "ibm,read-pci-config",
|
|
|
|
|
},
|
|
|
|
|
[RTAS_FNIDX__IBM_READ_SLOT_RESET_STATE] = {
|
|
|
|
|
.name = "ibm,read-slot-reset-state",
|
|
|
|
|
.filter = &(const struct rtas_filter) {
|
|
|
|
|
.buf_idx1 = -1, .size_idx1 = -1,
|
|
|
|
|
.buf_idx2 = -1, .size_idx2 = -1,
|
|
|
|
|
},
|
|
|
|
|
},
|
|
|
|
|
[RTAS_FNIDX__IBM_READ_SLOT_RESET_STATE2] = {
|
|
|
|
|
.name = "ibm,read-slot-reset-state2",
|
|
|
|
|
},
|
|
|
|
|
[RTAS_FNIDX__IBM_REMOVE_PE_DMA_WINDOW] = {
|
|
|
|
|
.name = "ibm,remove-pe-dma-window",
|
|
|
|
|
},
|
2024-02-22 16:19:14 -06:00
|
|
|
|
[RTAS_FNIDX__IBM_RESET_PE_DMA_WINDOW] = {
|
|
|
|
|
/*
|
|
|
|
|
* Note: PAPR+ v2.13 7.3.31.4.1 spells this as
|
|
|
|
|
* "ibm,reset-pe-dma-windows" (plural), but RTAS
|
|
|
|
|
* implementations use the singular form in practice.
|
|
|
|
|
*/
|
|
|
|
|
.name = "ibm,reset-pe-dma-window",
|
powerpc/rtas: improve function information lookups
The core RTAS support code and its clients perform two types of lookup
for RTAS firmware function information.
First, mapping a known function name to a token. The typical use case
invokes rtas_token() to retrieve the token value to pass to
rtas_call(). rtas_token() relies on of_get_property(), which performs
a linear search of the /rtas node's property list under a lock with
IRQs disabled.
Second, and less common: given a token value, looking up some
information about the function. The primary example is the sys_rtas
filter path, which linearly scans a small table to match the token to
a rtas_filter struct. Another use case to come is RTAS entry/exit
tracepoints, which will require efficient lookup of function names
from token values. Currently there is no general API for this.
We need something much like the existing rtas_filters table, but more
general and organized to facilitate efficient lookups.
Introduce:
* A new rtas_function type, aggregating function name, token,
and filter. Other function characteristics could be added in the
future.
* An array of rtas_function, where each element corresponds to a known
RTAS function. All information in the table is static save the token
values, which are derived from the device tree at boot. The array is
sorted by function name to allow binary search.
* A named constant for each known RTAS function, used to index the
function array. These also will be used in a client-facing API to be
added later.
* An xarray that maps valid tokens to rtas_function objects.
Fold the existing rtas_filter table into the new rtas_function array,
with the appropriate adjustments to block_rtas_call(). Remove
now-redundant fields from struct rtas_filter. Preserve the function of
the CONFIG_CPU_BIG_ENDIAN guard in the current filter table by
introducing a per-function flag that is set for the function entries
related to pseries LPAR migration. These have never had working users
via sys_rtas on ppc64le; see commit de0f7349a0dd ("powerpc/rtas:
prevent suspend-related sys_rtas use on LE").
Convert rtas_token() to use a lockless binary search on the function
table. Fall back to the old behavior for lookups against names that
are not known to be RTAS functions, but issue a warning. rtas_token()
is for function names; it is not a general facility for accessing
arbitrary properties of the /rtas node. All known misuses of
rtas_token() have been converted to more appropriate of_ APIs in
preceding changes.
Signed-off-by: Nathan Lynch <nathanl@linux.ibm.com>
Signed-off-by: Michael Ellerman <mpe@ellerman.id.au>
Link: https://lore.kernel.org/r/20230125-b4-powerpc-rtas-queue-v3-8-26929c8cce78@linux.ibm.com
2023-02-10 12:41:56 -06:00
|
|
|
|
},
|
|
|
|
|
[RTAS_FNIDX__IBM_SCAN_LOG_DUMP] = {
|
|
|
|
|
.name = "ibm,scan-log-dump",
|
|
|
|
|
.filter = &(const struct rtas_filter) {
|
|
|
|
|
.buf_idx1 = 0, .size_idx1 = 1,
|
|
|
|
|
.buf_idx2 = -1, .size_idx2 = -1,
|
|
|
|
|
},
|
|
|
|
|
},
|
|
|
|
|
[RTAS_FNIDX__IBM_SET_DYNAMIC_INDICATOR] = {
|
|
|
|
|
.name = "ibm,set-dynamic-indicator",
|
|
|
|
|
.filter = &(const struct rtas_filter) {
|
|
|
|
|
.buf_idx1 = 2, .size_idx1 = -1,
|
|
|
|
|
.buf_idx2 = -1, .size_idx2 = -1,
|
|
|
|
|
},
|
powerpc/rtas: Facilitate high-level call sequences
On RTAS platforms there is a general restriction that the OS must not
enter RTAS on more than one CPU at a time. This low-level
serialization requirement is satisfied by holding a spin
lock (rtas_lock) across most RTAS function invocations.
However, some pseries RTAS functions require multiple successive calls
to complete a logical operation. Beginning a new call sequence for such a
function may disrupt any other sequences of that function already in
progress. Safe and reliable use of these functions effectively
requires higher-level serialization beyond what is already done at the
level of RTAS entry and exit.
Where a sequence-based RTAS function is invoked only through
sys_rtas(), with no in-kernel users, there is no issue as far as the
kernel is concerned. User space is responsible for appropriately
serializing its call sequences. (Whether user space code actually
takes measures to prevent sequence interleaving is another matter.)
Examples of such functions currently include ibm,platform-dump and
ibm,get-vpd.
But where a sequence-based RTAS function has both user space and
in-kernel uesrs, there is a hazard. Even if the in-kernel call sites
of such a function serialize their sequences correctly, a user of
sys_rtas() can invoke the same function at any time, potentially
disrupting a sequence in progress.
So in order to prevent disruption of kernel-based RTAS call sequences,
they must serialize not only with themselves but also with sys_rtas()
users, somehow. Preferably without adding more function-specific hacks
to sys_rtas(). This is a prerequisite for adding an in-kernel call
sequence of ibm,get-vpd, which is in a change to follow.
Note that it has never been feasible for the kernel to prevent
sys_rtas()-based sequences from being disrupted because control
returns to user space on every call. sys_rtas()-based users of these
functions have always been, and continue to be, responsible for
coordinating their call sequences with other users, even those which
may invoke the RTAS functions through less direct means than
sys_rtas(). This is an unavoidable consequence of exposing
sequence-based RTAS functions through sys_rtas().
* Add an optional mutex member to struct rtas_function.
* Statically define a mutex for each RTAS function with known call
sequence serialization requirements, and assign its address to the
.lock member of the corresponding function table entry, along with
justifying commentary.
* In sys_rtas(), if the table entry for the RTAS function being
called has a populated lock member, acquire it before taking
rtas_lock and entering RTAS.
* Kernel-based RTAS call sequences are expected to access the
appropriate mutex explicitly by name. For example, a user of the
ibm,activate-firmware RTAS function would do:
int token = rtas_function_token(RTAS_FN_IBM_ACTIVATE_FIRMWARE);
int fwrc;
mutex_lock(&rtas_ibm_activate_firmware_lock);
do {
fwrc = rtas_call(token, 0, 1, NULL);
} while (rtas_busy_delay(fwrc));
mutex_unlock(&rtas_ibm_activate_firmware_lock);
There should be no perceivable change introduced here except that
concurrent callers of the same RTAS function via sys_rtas() may block
on a mutex instead of spinning on rtas_lock.
Signed-off-by: Nathan Lynch <nathanl@linux.ibm.com>
Signed-off-by: Michael Ellerman <mpe@ellerman.id.au>
Link: https://msgid.link/20231212-papr-sys_rtas-vs-lockdown-v6-6-e9eafd0c8c6c@linux.ibm.com
2023-12-12 11:01:53 -06:00
|
|
|
|
/*
|
|
|
|
|
* PAPR+ v2.13 R1–7.3.18–3 says the OS must not call
|
|
|
|
|
* this function with different inputs until a
|
|
|
|
|
* non-retry status has been returned.
|
|
|
|
|
*/
|
|
|
|
|
.lock = &rtas_ibm_set_dynamic_indicator_lock,
|
powerpc/rtas: improve function information lookups
The core RTAS support code and its clients perform two types of lookup
for RTAS firmware function information.
First, mapping a known function name to a token. The typical use case
invokes rtas_token() to retrieve the token value to pass to
rtas_call(). rtas_token() relies on of_get_property(), which performs
a linear search of the /rtas node's property list under a lock with
IRQs disabled.
Second, and less common: given a token value, looking up some
information about the function. The primary example is the sys_rtas
filter path, which linearly scans a small table to match the token to
a rtas_filter struct. Another use case to come is RTAS entry/exit
tracepoints, which will require efficient lookup of function names
from token values. Currently there is no general API for this.
We need something much like the existing rtas_filters table, but more
general and organized to facilitate efficient lookups.
Introduce:
* A new rtas_function type, aggregating function name, token,
and filter. Other function characteristics could be added in the
future.
* An array of rtas_function, where each element corresponds to a known
RTAS function. All information in the table is static save the token
values, which are derived from the device tree at boot. The array is
sorted by function name to allow binary search.
* A named constant for each known RTAS function, used to index the
function array. These also will be used in a client-facing API to be
added later.
* An xarray that maps valid tokens to rtas_function objects.
Fold the existing rtas_filter table into the new rtas_function array,
with the appropriate adjustments to block_rtas_call(). Remove
now-redundant fields from struct rtas_filter. Preserve the function of
the CONFIG_CPU_BIG_ENDIAN guard in the current filter table by
introducing a per-function flag that is set for the function entries
related to pseries LPAR migration. These have never had working users
via sys_rtas on ppc64le; see commit de0f7349a0dd ("powerpc/rtas:
prevent suspend-related sys_rtas use on LE").
Convert rtas_token() to use a lockless binary search on the function
table. Fall back to the old behavior for lookups against names that
are not known to be RTAS functions, but issue a warning. rtas_token()
is for function names; it is not a general facility for accessing
arbitrary properties of the /rtas node. All known misuses of
rtas_token() have been converted to more appropriate of_ APIs in
preceding changes.
Signed-off-by: Nathan Lynch <nathanl@linux.ibm.com>
Signed-off-by: Michael Ellerman <mpe@ellerman.id.au>
Link: https://lore.kernel.org/r/20230125-b4-powerpc-rtas-queue-v3-8-26929c8cce78@linux.ibm.com
2023-02-10 12:41:56 -06:00
|
|
|
|
},
|
|
|
|
|
[RTAS_FNIDX__IBM_SET_EEH_OPTION] = {
|
|
|
|
|
.name = "ibm,set-eeh-option",
|
|
|
|
|
.filter = &(const struct rtas_filter) {
|
|
|
|
|
.buf_idx1 = -1, .size_idx1 = -1,
|
|
|
|
|
.buf_idx2 = -1, .size_idx2 = -1,
|
|
|
|
|
},
|
|
|
|
|
},
|
|
|
|
|
[RTAS_FNIDX__IBM_SET_SLOT_RESET] = {
|
|
|
|
|
.name = "ibm,set-slot-reset",
|
|
|
|
|
},
|
|
|
|
|
[RTAS_FNIDX__IBM_SET_SYSTEM_PARAMETER] = {
|
|
|
|
|
.name = "ibm,set-system-parameter",
|
|
|
|
|
.filter = &(const struct rtas_filter) {
|
|
|
|
|
.buf_idx1 = 1, .size_idx1 = -1,
|
|
|
|
|
.buf_idx2 = -1, .size_idx2 = -1,
|
|
|
|
|
},
|
|
|
|
|
},
|
|
|
|
|
[RTAS_FNIDX__IBM_SET_XIVE] = {
|
|
|
|
|
.name = "ibm,set-xive",
|
|
|
|
|
},
|
|
|
|
|
[RTAS_FNIDX__IBM_SLOT_ERROR_DETAIL] = {
|
|
|
|
|
.name = "ibm,slot-error-detail",
|
|
|
|
|
},
|
|
|
|
|
[RTAS_FNIDX__IBM_SUSPEND_ME] = {
|
|
|
|
|
.name = "ibm,suspend-me",
|
|
|
|
|
.banned_for_syscall_on_le = true,
|
|
|
|
|
.filter = &(const struct rtas_filter) {
|
|
|
|
|
.buf_idx1 = -1, .size_idx1 = -1,
|
|
|
|
|
.buf_idx2 = -1, .size_idx2 = -1,
|
|
|
|
|
},
|
|
|
|
|
},
|
|
|
|
|
[RTAS_FNIDX__IBM_TUNE_DMA_PARMS] = {
|
|
|
|
|
.name = "ibm,tune-dma-parms",
|
|
|
|
|
},
|
|
|
|
|
[RTAS_FNIDX__IBM_UPDATE_FLASH_64_AND_REBOOT] = {
|
|
|
|
|
.name = "ibm,update-flash-64-and-reboot",
|
|
|
|
|
},
|
|
|
|
|
[RTAS_FNIDX__IBM_UPDATE_NODES] = {
|
|
|
|
|
.name = "ibm,update-nodes",
|
|
|
|
|
.banned_for_syscall_on_le = true,
|
|
|
|
|
.filter = &(const struct rtas_filter) {
|
|
|
|
|
.buf_idx1 = 0, .size_idx1 = -1,
|
|
|
|
|
.buf_idx2 = -1, .size_idx2 = -1,
|
|
|
|
|
.fixed_size = 4096,
|
|
|
|
|
},
|
|
|
|
|
},
|
|
|
|
|
[RTAS_FNIDX__IBM_UPDATE_PROPERTIES] = {
|
|
|
|
|
.name = "ibm,update-properties",
|
|
|
|
|
.banned_for_syscall_on_le = true,
|
|
|
|
|
.filter = &(const struct rtas_filter) {
|
|
|
|
|
.buf_idx1 = 0, .size_idx1 = -1,
|
|
|
|
|
.buf_idx2 = -1, .size_idx2 = -1,
|
|
|
|
|
.fixed_size = 4096,
|
|
|
|
|
},
|
|
|
|
|
},
|
|
|
|
|
[RTAS_FNIDX__IBM_VALIDATE_FLASH_IMAGE] = {
|
|
|
|
|
.name = "ibm,validate-flash-image",
|
|
|
|
|
},
|
|
|
|
|
[RTAS_FNIDX__IBM_WRITE_PCI_CONFIG] = {
|
|
|
|
|
.name = "ibm,write-pci-config",
|
|
|
|
|
},
|
|
|
|
|
[RTAS_FNIDX__NVRAM_FETCH] = {
|
|
|
|
|
.name = "nvram-fetch",
|
|
|
|
|
},
|
|
|
|
|
[RTAS_FNIDX__NVRAM_STORE] = {
|
|
|
|
|
.name = "nvram-store",
|
|
|
|
|
},
|
|
|
|
|
[RTAS_FNIDX__POWER_OFF] = {
|
|
|
|
|
.name = "power-off",
|
|
|
|
|
},
|
|
|
|
|
[RTAS_FNIDX__PUT_TERM_CHAR] = {
|
|
|
|
|
.name = "put-term-char",
|
|
|
|
|
},
|
|
|
|
|
[RTAS_FNIDX__QUERY_CPU_STOPPED_STATE] = {
|
|
|
|
|
.name = "query-cpu-stopped-state",
|
|
|
|
|
},
|
|
|
|
|
[RTAS_FNIDX__READ_PCI_CONFIG] = {
|
|
|
|
|
.name = "read-pci-config",
|
|
|
|
|
},
|
|
|
|
|
[RTAS_FNIDX__RTAS_LAST_ERROR] = {
|
|
|
|
|
.name = "rtas-last-error",
|
|
|
|
|
},
|
|
|
|
|
[RTAS_FNIDX__SET_INDICATOR] = {
|
|
|
|
|
.name = "set-indicator",
|
|
|
|
|
.filter = &(const struct rtas_filter) {
|
|
|
|
|
.buf_idx1 = -1, .size_idx1 = -1,
|
|
|
|
|
.buf_idx2 = -1, .size_idx2 = -1,
|
|
|
|
|
},
|
|
|
|
|
},
|
|
|
|
|
[RTAS_FNIDX__SET_POWER_LEVEL] = {
|
|
|
|
|
.name = "set-power-level",
|
|
|
|
|
.filter = &(const struct rtas_filter) {
|
|
|
|
|
.buf_idx1 = -1, .size_idx1 = -1,
|
|
|
|
|
.buf_idx2 = -1, .size_idx2 = -1,
|
|
|
|
|
},
|
|
|
|
|
},
|
|
|
|
|
[RTAS_FNIDX__SET_TIME_FOR_POWER_ON] = {
|
|
|
|
|
.name = "set-time-for-power-on",
|
|
|
|
|
.filter = &(const struct rtas_filter) {
|
|
|
|
|
.buf_idx1 = -1, .size_idx1 = -1,
|
|
|
|
|
.buf_idx2 = -1, .size_idx2 = -1,
|
|
|
|
|
},
|
|
|
|
|
},
|
|
|
|
|
[RTAS_FNIDX__SET_TIME_OF_DAY] = {
|
|
|
|
|
.name = "set-time-of-day",
|
|
|
|
|
.filter = &(const struct rtas_filter) {
|
|
|
|
|
.buf_idx1 = -1, .size_idx1 = -1,
|
|
|
|
|
.buf_idx2 = -1, .size_idx2 = -1,
|
|
|
|
|
},
|
|
|
|
|
},
|
|
|
|
|
[RTAS_FNIDX__START_CPU] = {
|
|
|
|
|
.name = "start-cpu",
|
|
|
|
|
},
|
|
|
|
|
[RTAS_FNIDX__STOP_SELF] = {
|
|
|
|
|
.name = "stop-self",
|
|
|
|
|
},
|
|
|
|
|
[RTAS_FNIDX__SYSTEM_REBOOT] = {
|
|
|
|
|
.name = "system-reboot",
|
|
|
|
|
},
|
|
|
|
|
[RTAS_FNIDX__THAW_TIME_BASE] = {
|
|
|
|
|
.name = "thaw-time-base",
|
|
|
|
|
},
|
|
|
|
|
[RTAS_FNIDX__WRITE_PCI_CONFIG] = {
|
|
|
|
|
.name = "write-pci-config",
|
|
|
|
|
},
|
|
|
|
|
};
|
|
|
|
|
|
2023-12-12 11:01:49 -06:00
|
|
|
|
#define for_each_rtas_function(funcp) \
|
|
|
|
|
for (funcp = &rtas_function_table[0]; \
|
|
|
|
|
funcp < &rtas_function_table[ARRAY_SIZE(rtas_function_table)]; \
|
|
|
|
|
++funcp)
|
|
|
|
|
|
2023-03-06 15:33:45 -06:00
|
|
|
|
/*
|
|
|
|
|
* Nearly all RTAS calls need to be serialized. All uses of the
|
|
|
|
|
* default rtas_args block must hold rtas_lock.
|
|
|
|
|
*
|
|
|
|
|
* Exceptions to the RTAS serialization requirement (e.g. stop-self)
|
|
|
|
|
* must use a separate rtas_args structure.
|
|
|
|
|
*/
|
|
|
|
|
static DEFINE_RAW_SPINLOCK(rtas_lock);
|
|
|
|
|
static struct rtas_args rtas_args;
|
|
|
|
|
|
2023-02-10 12:42:07 -06:00
|
|
|
|
/**
|
|
|
|
|
* rtas_function_token() - RTAS function token lookup.
|
|
|
|
|
* @handle: Function handle, e.g. RTAS_FN_EVENT_SCAN.
|
|
|
|
|
*
|
|
|
|
|
* Context: Any context.
|
|
|
|
|
* Return: the token value for the function if implemented by this platform,
|
|
|
|
|
* otherwise RTAS_UNKNOWN_SERVICE.
|
|
|
|
|
*/
|
|
|
|
|
s32 rtas_function_token(const rtas_fn_handle_t handle)
|
|
|
|
|
{
|
|
|
|
|
const size_t index = handle.index;
|
|
|
|
|
const bool out_of_bounds = index >= ARRAY_SIZE(rtas_function_table);
|
|
|
|
|
|
|
|
|
|
if (WARN_ONCE(out_of_bounds, "invalid function index %zu", index))
|
|
|
|
|
return RTAS_UNKNOWN_SERVICE;
|
|
|
|
|
/*
|
|
|
|
|
* Various drivers attempt token lookups on non-RTAS
|
|
|
|
|
* platforms.
|
|
|
|
|
*/
|
|
|
|
|
if (!rtas.dev)
|
|
|
|
|
return RTAS_UNKNOWN_SERVICE;
|
|
|
|
|
|
|
|
|
|
return rtas_function_table[index].token;
|
|
|
|
|
}
|
|
|
|
|
EXPORT_SYMBOL_GPL(rtas_function_token);
|
|
|
|
|
|
powerpc/rtas: improve function information lookups
The core RTAS support code and its clients perform two types of lookup
for RTAS firmware function information.
First, mapping a known function name to a token. The typical use case
invokes rtas_token() to retrieve the token value to pass to
rtas_call(). rtas_token() relies on of_get_property(), which performs
a linear search of the /rtas node's property list under a lock with
IRQs disabled.
Second, and less common: given a token value, looking up some
information about the function. The primary example is the sys_rtas
filter path, which linearly scans a small table to match the token to
a rtas_filter struct. Another use case to come is RTAS entry/exit
tracepoints, which will require efficient lookup of function names
from token values. Currently there is no general API for this.
We need something much like the existing rtas_filters table, but more
general and organized to facilitate efficient lookups.
Introduce:
* A new rtas_function type, aggregating function name, token,
and filter. Other function characteristics could be added in the
future.
* An array of rtas_function, where each element corresponds to a known
RTAS function. All information in the table is static save the token
values, which are derived from the device tree at boot. The array is
sorted by function name to allow binary search.
* A named constant for each known RTAS function, used to index the
function array. These also will be used in a client-facing API to be
added later.
* An xarray that maps valid tokens to rtas_function objects.
Fold the existing rtas_filter table into the new rtas_function array,
with the appropriate adjustments to block_rtas_call(). Remove
now-redundant fields from struct rtas_filter. Preserve the function of
the CONFIG_CPU_BIG_ENDIAN guard in the current filter table by
introducing a per-function flag that is set for the function entries
related to pseries LPAR migration. These have never had working users
via sys_rtas on ppc64le; see commit de0f7349a0dd ("powerpc/rtas:
prevent suspend-related sys_rtas use on LE").
Convert rtas_token() to use a lockless binary search on the function
table. Fall back to the old behavior for lookups against names that
are not known to be RTAS functions, but issue a warning. rtas_token()
is for function names; it is not a general facility for accessing
arbitrary properties of the /rtas node. All known misuses of
rtas_token() have been converted to more appropriate of_ APIs in
preceding changes.
Signed-off-by: Nathan Lynch <nathanl@linux.ibm.com>
Signed-off-by: Michael Ellerman <mpe@ellerman.id.au>
Link: https://lore.kernel.org/r/20230125-b4-powerpc-rtas-queue-v3-8-26929c8cce78@linux.ibm.com
2023-02-10 12:41:56 -06:00
|
|
|
|
static int rtas_function_cmp(const void *a, const void *b)
|
|
|
|
|
{
|
|
|
|
|
const struct rtas_function *f1 = a;
|
|
|
|
|
const struct rtas_function *f2 = b;
|
|
|
|
|
|
|
|
|
|
return strcmp(f1->name, f2->name);
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
/*
|
|
|
|
|
* Boot-time initialization of the function table needs the lookup to
|
|
|
|
|
* return a non-const-qualified object. Use rtas_name_to_function()
|
|
|
|
|
* in all other contexts.
|
|
|
|
|
*/
|
|
|
|
|
static struct rtas_function *__rtas_name_to_function(const char *name)
|
|
|
|
|
{
|
|
|
|
|
const struct rtas_function key = {
|
|
|
|
|
.name = name,
|
|
|
|
|
};
|
|
|
|
|
struct rtas_function *found;
|
|
|
|
|
|
|
|
|
|
found = bsearch(&key, rtas_function_table, ARRAY_SIZE(rtas_function_table),
|
|
|
|
|
sizeof(rtas_function_table[0]), rtas_function_cmp);
|
|
|
|
|
|
|
|
|
|
return found;
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
static const struct rtas_function *rtas_name_to_function(const char *name)
|
|
|
|
|
{
|
|
|
|
|
return __rtas_name_to_function(name);
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
static DEFINE_XARRAY(rtas_token_to_function_xarray);
|
|
|
|
|
|
|
|
|
|
static int __init rtas_token_to_function_xarray_init(void)
|
|
|
|
|
{
|
2023-12-12 11:01:49 -06:00
|
|
|
|
const struct rtas_function *func;
|
powerpc/rtas: improve function information lookups
The core RTAS support code and its clients perform two types of lookup
for RTAS firmware function information.
First, mapping a known function name to a token. The typical use case
invokes rtas_token() to retrieve the token value to pass to
rtas_call(). rtas_token() relies on of_get_property(), which performs
a linear search of the /rtas node's property list under a lock with
IRQs disabled.
Second, and less common: given a token value, looking up some
information about the function. The primary example is the sys_rtas
filter path, which linearly scans a small table to match the token to
a rtas_filter struct. Another use case to come is RTAS entry/exit
tracepoints, which will require efficient lookup of function names
from token values. Currently there is no general API for this.
We need something much like the existing rtas_filters table, but more
general and organized to facilitate efficient lookups.
Introduce:
* A new rtas_function type, aggregating function name, token,
and filter. Other function characteristics could be added in the
future.
* An array of rtas_function, where each element corresponds to a known
RTAS function. All information in the table is static save the token
values, which are derived from the device tree at boot. The array is
sorted by function name to allow binary search.
* A named constant for each known RTAS function, used to index the
function array. These also will be used in a client-facing API to be
added later.
* An xarray that maps valid tokens to rtas_function objects.
Fold the existing rtas_filter table into the new rtas_function array,
with the appropriate adjustments to block_rtas_call(). Remove
now-redundant fields from struct rtas_filter. Preserve the function of
the CONFIG_CPU_BIG_ENDIAN guard in the current filter table by
introducing a per-function flag that is set for the function entries
related to pseries LPAR migration. These have never had working users
via sys_rtas on ppc64le; see commit de0f7349a0dd ("powerpc/rtas:
prevent suspend-related sys_rtas use on LE").
Convert rtas_token() to use a lockless binary search on the function
table. Fall back to the old behavior for lookups against names that
are not known to be RTAS functions, but issue a warning. rtas_token()
is for function names; it is not a general facility for accessing
arbitrary properties of the /rtas node. All known misuses of
rtas_token() have been converted to more appropriate of_ APIs in
preceding changes.
Signed-off-by: Nathan Lynch <nathanl@linux.ibm.com>
Signed-off-by: Michael Ellerman <mpe@ellerman.id.au>
Link: https://lore.kernel.org/r/20230125-b4-powerpc-rtas-queue-v3-8-26929c8cce78@linux.ibm.com
2023-02-10 12:41:56 -06:00
|
|
|
|
int err = 0;
|
|
|
|
|
|
2023-12-12 11:01:49 -06:00
|
|
|
|
for_each_rtas_function(func) {
|
powerpc/rtas: improve function information lookups
The core RTAS support code and its clients perform two types of lookup
for RTAS firmware function information.
First, mapping a known function name to a token. The typical use case
invokes rtas_token() to retrieve the token value to pass to
rtas_call(). rtas_token() relies on of_get_property(), which performs
a linear search of the /rtas node's property list under a lock with
IRQs disabled.
Second, and less common: given a token value, looking up some
information about the function. The primary example is the sys_rtas
filter path, which linearly scans a small table to match the token to
a rtas_filter struct. Another use case to come is RTAS entry/exit
tracepoints, which will require efficient lookup of function names
from token values. Currently there is no general API for this.
We need something much like the existing rtas_filters table, but more
general and organized to facilitate efficient lookups.
Introduce:
* A new rtas_function type, aggregating function name, token,
and filter. Other function characteristics could be added in the
future.
* An array of rtas_function, where each element corresponds to a known
RTAS function. All information in the table is static save the token
values, which are derived from the device tree at boot. The array is
sorted by function name to allow binary search.
* A named constant for each known RTAS function, used to index the
function array. These also will be used in a client-facing API to be
added later.
* An xarray that maps valid tokens to rtas_function objects.
Fold the existing rtas_filter table into the new rtas_function array,
with the appropriate adjustments to block_rtas_call(). Remove
now-redundant fields from struct rtas_filter. Preserve the function of
the CONFIG_CPU_BIG_ENDIAN guard in the current filter table by
introducing a per-function flag that is set for the function entries
related to pseries LPAR migration. These have never had working users
via sys_rtas on ppc64le; see commit de0f7349a0dd ("powerpc/rtas:
prevent suspend-related sys_rtas use on LE").
Convert rtas_token() to use a lockless binary search on the function
table. Fall back to the old behavior for lookups against names that
are not known to be RTAS functions, but issue a warning. rtas_token()
is for function names; it is not a general facility for accessing
arbitrary properties of the /rtas node. All known misuses of
rtas_token() have been converted to more appropriate of_ APIs in
preceding changes.
Signed-off-by: Nathan Lynch <nathanl@linux.ibm.com>
Signed-off-by: Michael Ellerman <mpe@ellerman.id.au>
Link: https://lore.kernel.org/r/20230125-b4-powerpc-rtas-queue-v3-8-26929c8cce78@linux.ibm.com
2023-02-10 12:41:56 -06:00
|
|
|
|
const s32 token = func->token;
|
|
|
|
|
|
|
|
|
|
if (token == RTAS_UNKNOWN_SERVICE)
|
|
|
|
|
continue;
|
|
|
|
|
|
|
|
|
|
err = xa_err(xa_store(&rtas_token_to_function_xarray,
|
|
|
|
|
token, (void *)func, GFP_KERNEL));
|
|
|
|
|
if (err)
|
|
|
|
|
break;
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
return err;
|
|
|
|
|
}
|
|
|
|
|
arch_initcall(rtas_token_to_function_xarray_init);
|
|
|
|
|
|
2023-12-12 11:01:48 -06:00
|
|
|
|
/*
|
|
|
|
|
* For use by sys_rtas(), where the token value is provided by user
|
|
|
|
|
* space and we don't want to warn on failed lookups.
|
|
|
|
|
*/
|
|
|
|
|
static const struct rtas_function *rtas_token_to_function_untrusted(s32 token)
|
|
|
|
|
{
|
|
|
|
|
return xa_load(&rtas_token_to_function_xarray, token);
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
/*
|
|
|
|
|
* Reverse lookup for deriving the function descriptor from a
|
|
|
|
|
* known-good token value in contexts where the former is not already
|
|
|
|
|
* available. @token must be valid, e.g. derived from the result of a
|
|
|
|
|
* prior lookup against the function table.
|
|
|
|
|
*/
|
powerpc/rtas: improve function information lookups
The core RTAS support code and its clients perform two types of lookup
for RTAS firmware function information.
First, mapping a known function name to a token. The typical use case
invokes rtas_token() to retrieve the token value to pass to
rtas_call(). rtas_token() relies on of_get_property(), which performs
a linear search of the /rtas node's property list under a lock with
IRQs disabled.
Second, and less common: given a token value, looking up some
information about the function. The primary example is the sys_rtas
filter path, which linearly scans a small table to match the token to
a rtas_filter struct. Another use case to come is RTAS entry/exit
tracepoints, which will require efficient lookup of function names
from token values. Currently there is no general API for this.
We need something much like the existing rtas_filters table, but more
general and organized to facilitate efficient lookups.
Introduce:
* A new rtas_function type, aggregating function name, token,
and filter. Other function characteristics could be added in the
future.
* An array of rtas_function, where each element corresponds to a known
RTAS function. All information in the table is static save the token
values, which are derived from the device tree at boot. The array is
sorted by function name to allow binary search.
* A named constant for each known RTAS function, used to index the
function array. These also will be used in a client-facing API to be
added later.
* An xarray that maps valid tokens to rtas_function objects.
Fold the existing rtas_filter table into the new rtas_function array,
with the appropriate adjustments to block_rtas_call(). Remove
now-redundant fields from struct rtas_filter. Preserve the function of
the CONFIG_CPU_BIG_ENDIAN guard in the current filter table by
introducing a per-function flag that is set for the function entries
related to pseries LPAR migration. These have never had working users
via sys_rtas on ppc64le; see commit de0f7349a0dd ("powerpc/rtas:
prevent suspend-related sys_rtas use on LE").
Convert rtas_token() to use a lockless binary search on the function
table. Fall back to the old behavior for lookups against names that
are not known to be RTAS functions, but issue a warning. rtas_token()
is for function names; it is not a general facility for accessing
arbitrary properties of the /rtas node. All known misuses of
rtas_token() have been converted to more appropriate of_ APIs in
preceding changes.
Signed-off-by: Nathan Lynch <nathanl@linux.ibm.com>
Signed-off-by: Michael Ellerman <mpe@ellerman.id.au>
Link: https://lore.kernel.org/r/20230125-b4-powerpc-rtas-queue-v3-8-26929c8cce78@linux.ibm.com
2023-02-10 12:41:56 -06:00
|
|
|
|
static const struct rtas_function *rtas_token_to_function(s32 token)
|
|
|
|
|
{
|
|
|
|
|
const struct rtas_function *func;
|
|
|
|
|
|
|
|
|
|
if (WARN_ONCE(token < 0, "invalid token %d", token))
|
|
|
|
|
return NULL;
|
|
|
|
|
|
2023-12-12 11:01:48 -06:00
|
|
|
|
func = rtas_token_to_function_untrusted(token);
|
2023-12-12 11:01:50 -06:00
|
|
|
|
if (func)
|
|
|
|
|
return func;
|
|
|
|
|
/*
|
|
|
|
|
* Fall back to linear scan in case the reverse mapping hasn't
|
|
|
|
|
* been initialized yet.
|
|
|
|
|
*/
|
|
|
|
|
if (xa_empty(&rtas_token_to_function_xarray)) {
|
|
|
|
|
for_each_rtas_function(func) {
|
|
|
|
|
if (func->token == token)
|
|
|
|
|
return func;
|
|
|
|
|
}
|
|
|
|
|
}
|
powerpc/rtas: improve function information lookups
The core RTAS support code and its clients perform two types of lookup
for RTAS firmware function information.
First, mapping a known function name to a token. The typical use case
invokes rtas_token() to retrieve the token value to pass to
rtas_call(). rtas_token() relies on of_get_property(), which performs
a linear search of the /rtas node's property list under a lock with
IRQs disabled.
Second, and less common: given a token value, looking up some
information about the function. The primary example is the sys_rtas
filter path, which linearly scans a small table to match the token to
a rtas_filter struct. Another use case to come is RTAS entry/exit
tracepoints, which will require efficient lookup of function names
from token values. Currently there is no general API for this.
We need something much like the existing rtas_filters table, but more
general and organized to facilitate efficient lookups.
Introduce:
* A new rtas_function type, aggregating function name, token,
and filter. Other function characteristics could be added in the
future.
* An array of rtas_function, where each element corresponds to a known
RTAS function. All information in the table is static save the token
values, which are derived from the device tree at boot. The array is
sorted by function name to allow binary search.
* A named constant for each known RTAS function, used to index the
function array. These also will be used in a client-facing API to be
added later.
* An xarray that maps valid tokens to rtas_function objects.
Fold the existing rtas_filter table into the new rtas_function array,
with the appropriate adjustments to block_rtas_call(). Remove
now-redundant fields from struct rtas_filter. Preserve the function of
the CONFIG_CPU_BIG_ENDIAN guard in the current filter table by
introducing a per-function flag that is set for the function entries
related to pseries LPAR migration. These have never had working users
via sys_rtas on ppc64le; see commit de0f7349a0dd ("powerpc/rtas:
prevent suspend-related sys_rtas use on LE").
Convert rtas_token() to use a lockless binary search on the function
table. Fall back to the old behavior for lookups against names that
are not known to be RTAS functions, but issue a warning. rtas_token()
is for function names; it is not a general facility for accessing
arbitrary properties of the /rtas node. All known misuses of
rtas_token() have been converted to more appropriate of_ APIs in
preceding changes.
Signed-off-by: Nathan Lynch <nathanl@linux.ibm.com>
Signed-off-by: Michael Ellerman <mpe@ellerman.id.au>
Link: https://lore.kernel.org/r/20230125-b4-powerpc-rtas-queue-v3-8-26929c8cce78@linux.ibm.com
2023-02-10 12:41:56 -06:00
|
|
|
|
|
2023-12-12 11:01:50 -06:00
|
|
|
|
WARN_ONCE(true, "unexpected failed lookup for token %d", token);
|
|
|
|
|
return NULL;
|
powerpc/rtas: improve function information lookups
The core RTAS support code and its clients perform two types of lookup
for RTAS firmware function information.
First, mapping a known function name to a token. The typical use case
invokes rtas_token() to retrieve the token value to pass to
rtas_call(). rtas_token() relies on of_get_property(), which performs
a linear search of the /rtas node's property list under a lock with
IRQs disabled.
Second, and less common: given a token value, looking up some
information about the function. The primary example is the sys_rtas
filter path, which linearly scans a small table to match the token to
a rtas_filter struct. Another use case to come is RTAS entry/exit
tracepoints, which will require efficient lookup of function names
from token values. Currently there is no general API for this.
We need something much like the existing rtas_filters table, but more
general and organized to facilitate efficient lookups.
Introduce:
* A new rtas_function type, aggregating function name, token,
and filter. Other function characteristics could be added in the
future.
* An array of rtas_function, where each element corresponds to a known
RTAS function. All information in the table is static save the token
values, which are derived from the device tree at boot. The array is
sorted by function name to allow binary search.
* A named constant for each known RTAS function, used to index the
function array. These also will be used in a client-facing API to be
added later.
* An xarray that maps valid tokens to rtas_function objects.
Fold the existing rtas_filter table into the new rtas_function array,
with the appropriate adjustments to block_rtas_call(). Remove
now-redundant fields from struct rtas_filter. Preserve the function of
the CONFIG_CPU_BIG_ENDIAN guard in the current filter table by
introducing a per-function flag that is set for the function entries
related to pseries LPAR migration. These have never had working users
via sys_rtas on ppc64le; see commit de0f7349a0dd ("powerpc/rtas:
prevent suspend-related sys_rtas use on LE").
Convert rtas_token() to use a lockless binary search on the function
table. Fall back to the old behavior for lookups against names that
are not known to be RTAS functions, but issue a warning. rtas_token()
is for function names; it is not a general facility for accessing
arbitrary properties of the /rtas node. All known misuses of
rtas_token() have been converted to more appropriate of_ APIs in
preceding changes.
Signed-off-by: Nathan Lynch <nathanl@linux.ibm.com>
Signed-off-by: Michael Ellerman <mpe@ellerman.id.au>
Link: https://lore.kernel.org/r/20230125-b4-powerpc-rtas-queue-v3-8-26929c8cce78@linux.ibm.com
2023-02-10 12:41:56 -06:00
|
|
|
|
}
|
|
|
|
|
|
2015-11-24 22:26:12 +11:00
|
|
|
|
/* This is here deliberately so it's only used in this file */
|
|
|
|
|
void enter_rtas(unsigned long);
|
|
|
|
|
|
2023-02-10 12:41:59 -06:00
|
|
|
|
static void __do_enter_rtas(struct rtas_args *args)
|
2021-06-18 01:51:03 +10:00
|
|
|
|
{
|
2023-02-10 12:41:59 -06:00
|
|
|
|
enter_rtas(__pa(args));
|
|
|
|
|
srr_regs_clobbered(); /* rtas uses SRRs, invalidate */
|
|
|
|
|
}
|
powerpc/rtas: Keep MSR[RI] set when calling RTAS
RTAS runs in real mode (MSR[DR] and MSR[IR] unset) and in 32-bit big
endian mode (MSR[SF,LE] unset).
The change in MSR is done in enter_rtas() in a relatively complex way,
since the MSR value could be hardcoded.
Furthermore, a panic has been reported when hitting the watchdog interrupt
while running in RTAS, this leads to the following stack trace:
watchdog: CPU 24 Hard LOCKUP
watchdog: CPU 24 TB:997512652051031, last heartbeat TB:997504470175378 (15980ms ago)
...
Supported: No, Unreleased kernel
CPU: 24 PID: 87504 Comm: drmgr Kdump: loaded Tainted: G E X 5.14.21-150400.71.1.bz196362_2-default #1 SLE15-SP4 (unreleased) 0d821077ef4faa8dfaf370efb5fdca1fa35f4e2c
NIP: 000000001fb41050 LR: 000000001fb4104c CTR: 0000000000000000
REGS: c00000000fc33d60 TRAP: 0100 Tainted: G E X (5.14.21-150400.71.1.bz196362_2-default)
MSR: 8000000002981000 <SF,VEC,VSX,ME> CR: 48800002 XER: 20040020
CFAR: 000000000000011c IRQMASK: 1
GPR00: 0000000000000003 ffffffffffffffff 0000000000000001 00000000000050dc
GPR04: 000000001ffb6100 0000000000000020 0000000000000001 000000001fb09010
GPR08: 0000000020000000 0000000000000000 0000000000000000 0000000000000000
GPR12: 80040000072a40a8 c00000000ff8b680 0000000000000007 0000000000000034
GPR16: 000000001fbf6e94 000000001fbf6d84 000000001fbd1db0 000000001fb3f008
GPR20: 000000001fb41018 ffffffffffffffff 000000000000017f fffffffffffff68f
GPR24: 000000001fb18fe8 000000001fb3e000 000000001fb1adc0 000000001fb1cf40
GPR28: 000000001fb26000 000000001fb460f0 000000001fb17f18 000000001fb17000
NIP [000000001fb41050] 0x1fb41050
LR [000000001fb4104c] 0x1fb4104c
Call Trace:
Instruction dump:
XXXXXXXX XXXXXXXX XXXXXXXX XXXXXXXX XXXXXXXX XXXXXXXX XXXXXXXX XXXXXXXX
XXXXXXXX XXXXXXXX XXXXXXXX XXXXXXXX XXXXXXXX XXXXXXXX XXXXXXXX XXXXXXXX
Oops: Unrecoverable System Reset, sig: 6 [#1]
LE PAGE_SIZE=64K MMU=Hash SMP NR_CPUS=2048 NUMA pSeries
...
Supported: No, Unreleased kernel
CPU: 24 PID: 87504 Comm: drmgr Kdump: loaded Tainted: G E X 5.14.21-150400.71.1.bz196362_2-default #1 SLE15-SP4 (unreleased) 0d821077ef4faa8dfaf370efb5fdca1fa35f4e2c
NIP: 000000001fb41050 LR: 000000001fb4104c CTR: 0000000000000000
REGS: c00000000fc33d60 TRAP: 0100 Tainted: G E X (5.14.21-150400.71.1.bz196362_2-default)
MSR: 8000000002981000 <SF,VEC,VSX,ME> CR: 48800002 XER: 20040020
CFAR: 000000000000011c IRQMASK: 1
GPR00: 0000000000000003 ffffffffffffffff 0000000000000001 00000000000050dc
GPR04: 000000001ffb6100 0000000000000020 0000000000000001 000000001fb09010
GPR08: 0000000020000000 0000000000000000 0000000000000000 0000000000000000
GPR12: 80040000072a40a8 c00000000ff8b680 0000000000000007 0000000000000034
GPR16: 000000001fbf6e94 000000001fbf6d84 000000001fbd1db0 000000001fb3f008
GPR20: 000000001fb41018 ffffffffffffffff 000000000000017f fffffffffffff68f
GPR24: 000000001fb18fe8 000000001fb3e000 000000001fb1adc0 000000001fb1cf40
GPR28: 000000001fb26000 000000001fb460f0 000000001fb17f18 000000001fb17000
NIP [000000001fb41050] 0x1fb41050
LR [000000001fb4104c] 0x1fb4104c
Call Trace:
Instruction dump:
XXXXXXXX XXXXXXXX XXXXXXXX XXXXXXXX XXXXXXXX XXXXXXXX XXXXXXXX XXXXXXXX
XXXXXXXX XXXXXXXX XXXXXXXX XXXXXXXX XXXXXXXX XXXXXXXX XXXXXXXX XXXXXXXX
---[ end trace 3ddec07f638c34a2 ]---
This happens because MSR[RI] is unset when entering RTAS but there is no
valid reason to not set it here.
RTAS is expected to be called with MSR[RI] as specified in PAPR+ section
"7.2.1 Machine State":
R1–7.2.1–9. If called with MSR[RI] equal to 1, then RTAS must protect
its own critical regions from recursion by setting the MSR[RI] bit to
0 when in the critical regions.
Fixing this by reviewing the way MSR is compute before calling RTAS. Now a
hardcoded value meaning real mode, 32 bits big endian mode and Recoverable
Interrupt is loaded. In the case MSR[S] is set, it will remain set while
entering RTAS as only urfid can unset it (thanks Fabiano).
In addition a check is added in do_enter_rtas() to detect calls made with
MSR[RI] unset, as we are forcing it on later.
This patch has been tested on the following machines:
Power KVM Guest
P8 S822L (host Ubuntu kernel 5.11.0-49-generic)
PowerVM LPAR
P8 9119-MME (FW860.A1)
p9 9008-22L (FW950.00)
P10 9080-HEX (FW1010.00)
Suggested-by: Nicholas Piggin <npiggin@gmail.com>
Signed-off-by: Laurent Dufour <ldufour@linux.ibm.com>
Signed-off-by: Michael Ellerman <mpe@ellerman.id.au>
Link: https://lore.kernel.org/r/20220504101244.12107-1-ldufour@linux.ibm.com
2022-05-04 12:12:44 +02:00
|
|
|
|
|
2023-02-10 12:41:59 -06:00
|
|
|
|
static void __do_enter_rtas_trace(struct rtas_args *args)
|
|
|
|
|
{
|
2023-12-12 11:01:55 -06:00
|
|
|
|
const struct rtas_function *func = rtas_token_to_function(be32_to_cpu(args->token));
|
2023-03-06 15:33:45 -06:00
|
|
|
|
|
2023-02-10 12:41:59 -06:00
|
|
|
|
/*
|
2023-12-12 11:01:55 -06:00
|
|
|
|
* If there is a per-function lock, it must be held by the
|
|
|
|
|
* caller.
|
2023-02-10 12:41:59 -06:00
|
|
|
|
*/
|
2023-12-12 11:01:55 -06:00
|
|
|
|
if (func->lock)
|
|
|
|
|
lockdep_assert_held(func->lock);
|
2023-02-10 12:41:59 -06:00
|
|
|
|
|
2023-12-12 11:01:55 -06:00
|
|
|
|
if (args == &rtas_args)
|
|
|
|
|
lockdep_assert_held(&rtas_lock);
|
2023-02-10 12:41:59 -06:00
|
|
|
|
|
2023-12-12 11:01:55 -06:00
|
|
|
|
trace_rtas_input(args, func->name);
|
2023-02-10 12:41:59 -06:00
|
|
|
|
trace_rtas_ll_entry(args);
|
|
|
|
|
|
|
|
|
|
__do_enter_rtas(args);
|
|
|
|
|
|
|
|
|
|
trace_rtas_ll_exit(args);
|
2023-12-12 11:01:55 -06:00
|
|
|
|
trace_rtas_output(args, func->name);
|
2023-02-10 12:41:59 -06:00
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
static void do_enter_rtas(struct rtas_args *args)
|
|
|
|
|
{
|
|
|
|
|
const unsigned long msr = mfmsr();
|
|
|
|
|
/*
|
|
|
|
|
* Situations where we want to skip any active tracepoints for
|
|
|
|
|
* safety reasons:
|
|
|
|
|
*
|
|
|
|
|
* 1. The last code executed on an offline CPU as it stops,
|
|
|
|
|
* i.e. we're about to call stop-self. The tracepoints'
|
|
|
|
|
* function name lookup uses xarray, which uses RCU, which
|
|
|
|
|
* isn't valid to call on an offline CPU. Any events
|
|
|
|
|
* emitted on an offline CPU will be discarded anyway.
|
|
|
|
|
*
|
|
|
|
|
* 2. In real mode, as when invoking ibm,nmi-interlock from
|
|
|
|
|
* the pseries MCE handler. We cannot count on trace
|
|
|
|
|
* buffers or the entries in rtas_token_to_function_xarray
|
|
|
|
|
* to be contained in the RMO.
|
|
|
|
|
*/
|
|
|
|
|
const unsigned long mask = MSR_IR | MSR_DR;
|
|
|
|
|
const bool can_trace = likely(cpu_online(raw_smp_processor_id()) &&
|
|
|
|
|
(msr & mask) == mask);
|
powerpc/rtas: Keep MSR[RI] set when calling RTAS
RTAS runs in real mode (MSR[DR] and MSR[IR] unset) and in 32-bit big
endian mode (MSR[SF,LE] unset).
The change in MSR is done in enter_rtas() in a relatively complex way,
since the MSR value could be hardcoded.
Furthermore, a panic has been reported when hitting the watchdog interrupt
while running in RTAS, this leads to the following stack trace:
watchdog: CPU 24 Hard LOCKUP
watchdog: CPU 24 TB:997512652051031, last heartbeat TB:997504470175378 (15980ms ago)
...
Supported: No, Unreleased kernel
CPU: 24 PID: 87504 Comm: drmgr Kdump: loaded Tainted: G E X 5.14.21-150400.71.1.bz196362_2-default #1 SLE15-SP4 (unreleased) 0d821077ef4faa8dfaf370efb5fdca1fa35f4e2c
NIP: 000000001fb41050 LR: 000000001fb4104c CTR: 0000000000000000
REGS: c00000000fc33d60 TRAP: 0100 Tainted: G E X (5.14.21-150400.71.1.bz196362_2-default)
MSR: 8000000002981000 <SF,VEC,VSX,ME> CR: 48800002 XER: 20040020
CFAR: 000000000000011c IRQMASK: 1
GPR00: 0000000000000003 ffffffffffffffff 0000000000000001 00000000000050dc
GPR04: 000000001ffb6100 0000000000000020 0000000000000001 000000001fb09010
GPR08: 0000000020000000 0000000000000000 0000000000000000 0000000000000000
GPR12: 80040000072a40a8 c00000000ff8b680 0000000000000007 0000000000000034
GPR16: 000000001fbf6e94 000000001fbf6d84 000000001fbd1db0 000000001fb3f008
GPR20: 000000001fb41018 ffffffffffffffff 000000000000017f fffffffffffff68f
GPR24: 000000001fb18fe8 000000001fb3e000 000000001fb1adc0 000000001fb1cf40
GPR28: 000000001fb26000 000000001fb460f0 000000001fb17f18 000000001fb17000
NIP [000000001fb41050] 0x1fb41050
LR [000000001fb4104c] 0x1fb4104c
Call Trace:
Instruction dump:
XXXXXXXX XXXXXXXX XXXXXXXX XXXXXXXX XXXXXXXX XXXXXXXX XXXXXXXX XXXXXXXX
XXXXXXXX XXXXXXXX XXXXXXXX XXXXXXXX XXXXXXXX XXXXXXXX XXXXXXXX XXXXXXXX
Oops: Unrecoverable System Reset, sig: 6 [#1]
LE PAGE_SIZE=64K MMU=Hash SMP NR_CPUS=2048 NUMA pSeries
...
Supported: No, Unreleased kernel
CPU: 24 PID: 87504 Comm: drmgr Kdump: loaded Tainted: G E X 5.14.21-150400.71.1.bz196362_2-default #1 SLE15-SP4 (unreleased) 0d821077ef4faa8dfaf370efb5fdca1fa35f4e2c
NIP: 000000001fb41050 LR: 000000001fb4104c CTR: 0000000000000000
REGS: c00000000fc33d60 TRAP: 0100 Tainted: G E X (5.14.21-150400.71.1.bz196362_2-default)
MSR: 8000000002981000 <SF,VEC,VSX,ME> CR: 48800002 XER: 20040020
CFAR: 000000000000011c IRQMASK: 1
GPR00: 0000000000000003 ffffffffffffffff 0000000000000001 00000000000050dc
GPR04: 000000001ffb6100 0000000000000020 0000000000000001 000000001fb09010
GPR08: 0000000020000000 0000000000000000 0000000000000000 0000000000000000
GPR12: 80040000072a40a8 c00000000ff8b680 0000000000000007 0000000000000034
GPR16: 000000001fbf6e94 000000001fbf6d84 000000001fbd1db0 000000001fb3f008
GPR20: 000000001fb41018 ffffffffffffffff 000000000000017f fffffffffffff68f
GPR24: 000000001fb18fe8 000000001fb3e000 000000001fb1adc0 000000001fb1cf40
GPR28: 000000001fb26000 000000001fb460f0 000000001fb17f18 000000001fb17000
NIP [000000001fb41050] 0x1fb41050
LR [000000001fb4104c] 0x1fb4104c
Call Trace:
Instruction dump:
XXXXXXXX XXXXXXXX XXXXXXXX XXXXXXXX XXXXXXXX XXXXXXXX XXXXXXXX XXXXXXXX
XXXXXXXX XXXXXXXX XXXXXXXX XXXXXXXX XXXXXXXX XXXXXXXX XXXXXXXX XXXXXXXX
---[ end trace 3ddec07f638c34a2 ]---
This happens because MSR[RI] is unset when entering RTAS but there is no
valid reason to not set it here.
RTAS is expected to be called with MSR[RI] as specified in PAPR+ section
"7.2.1 Machine State":
R1–7.2.1–9. If called with MSR[RI] equal to 1, then RTAS must protect
its own critical regions from recursion by setting the MSR[RI] bit to
0 when in the critical regions.
Fixing this by reviewing the way MSR is compute before calling RTAS. Now a
hardcoded value meaning real mode, 32 bits big endian mode and Recoverable
Interrupt is loaded. In the case MSR[S] is set, it will remain set while
entering RTAS as only urfid can unset it (thanks Fabiano).
In addition a check is added in do_enter_rtas() to detect calls made with
MSR[RI] unset, as we are forcing it on later.
This patch has been tested on the following machines:
Power KVM Guest
P8 S822L (host Ubuntu kernel 5.11.0-49-generic)
PowerVM LPAR
P8 9119-MME (FW860.A1)
p9 9008-22L (FW950.00)
P10 9080-HEX (FW1010.00)
Suggested-by: Nicholas Piggin <npiggin@gmail.com>
Signed-off-by: Laurent Dufour <ldufour@linux.ibm.com>
Signed-off-by: Michael Ellerman <mpe@ellerman.id.au>
Link: https://lore.kernel.org/r/20220504101244.12107-1-ldufour@linux.ibm.com
2022-05-04 12:12:44 +02:00
|
|
|
|
/*
|
|
|
|
|
* Make sure MSR[RI] is currently enabled as it will be forced later
|
|
|
|
|
* in enter_rtas.
|
|
|
|
|
*/
|
|
|
|
|
BUG_ON(!(msr & MSR_RI));
|
|
|
|
|
|
2022-03-08 23:50:37 +10:00
|
|
|
|
BUG_ON(!irqs_disabled());
|
|
|
|
|
|
|
|
|
|
hard_irq_disable(); /* Ensure MSR[EE] is disabled on PPC64 */
|
|
|
|
|
|
2023-02-10 12:41:59 -06:00
|
|
|
|
if (can_trace)
|
|
|
|
|
__do_enter_rtas_trace(args);
|
|
|
|
|
else
|
|
|
|
|
__do_enter_rtas(args);
|
2021-06-18 01:51:03 +10:00
|
|
|
|
}
|
|
|
|
|
|
2023-01-24 08:04:47 -06:00
|
|
|
|
struct rtas_t rtas;
|
|
|
|
|
|
2005-04-16 15:20:36 -07:00
|
|
|
|
DEFINE_SPINLOCK(rtas_data_buf_lock);
|
2023-01-24 08:04:46 -06:00
|
|
|
|
EXPORT_SYMBOL_GPL(rtas_data_buf_lock);
|
2006-06-23 18:20:11 +10:00
|
|
|
|
|
2023-02-10 12:41:54 -06:00
|
|
|
|
char rtas_data_buf[RTAS_DATA_BUF_SIZE] __aligned(SZ_4K);
|
2023-01-24 08:04:46 -06:00
|
|
|
|
EXPORT_SYMBOL_GPL(rtas_data_buf);
|
2006-06-23 18:20:11 +10:00
|
|
|
|
|
2005-04-16 15:20:36 -07:00
|
|
|
|
unsigned long rtas_rmo_buf;
|
|
|
|
|
|
2005-11-03 14:41:19 +11:00
|
|
|
|
/*
|
|
|
|
|
* If non-NULL, this gets called when the kernel terminates.
|
|
|
|
|
* This is done like this so rtas_flash can be a module.
|
|
|
|
|
*/
|
|
|
|
|
void (*rtas_flash_term_hook)(int);
|
2023-01-24 08:04:46 -06:00
|
|
|
|
EXPORT_SYMBOL_GPL(rtas_flash_term_hook);
|
2005-11-03 14:41:19 +11:00
|
|
|
|
|
2005-10-26 17:05:24 +10:00
|
|
|
|
/*
|
|
|
|
|
* call_rtas_display_status and call_rtas_display_status_delay
|
|
|
|
|
* are designed only for very early low-level debugging, which
|
|
|
|
|
* is why the token is hard-coded to 10.
|
|
|
|
|
*/
|
2013-08-07 02:01:31 +10:00
|
|
|
|
static void call_rtas_display_status(unsigned char c)
|
2005-04-16 15:20:36 -07:00
|
|
|
|
{
|
2023-01-24 08:04:48 -06:00
|
|
|
|
unsigned long flags;
|
2005-04-16 15:20:36 -07:00
|
|
|
|
|
|
|
|
|
if (!rtas.base)
|
|
|
|
|
return;
|
|
|
|
|
|
2023-01-24 08:04:48 -06:00
|
|
|
|
raw_spin_lock_irqsave(&rtas_lock, flags);
|
2023-01-24 08:04:47 -06:00
|
|
|
|
rtas_call_unlocked(&rtas_args, 10, 1, 1, NULL, c);
|
2023-01-24 08:04:48 -06:00
|
|
|
|
raw_spin_unlock_irqrestore(&rtas_lock, flags);
|
2005-04-16 15:20:36 -07:00
|
|
|
|
}
|
|
|
|
|
|
2006-01-11 11:54:09 +11:00
|
|
|
|
static void call_rtas_display_status_delay(char c)
|
2005-04-16 15:20:36 -07:00
|
|
|
|
{
|
|
|
|
|
static int pending_newline = 0; /* did last write end with unprinted newline? */
|
|
|
|
|
static int width = 16;
|
|
|
|
|
|
2023-11-06 07:42:58 -06:00
|
|
|
|
if (c == '\n') {
|
2005-04-16 15:20:36 -07:00
|
|
|
|
while (width-- > 0)
|
|
|
|
|
call_rtas_display_status(' ');
|
|
|
|
|
width = 16;
|
2005-11-07 16:41:59 +11:00
|
|
|
|
mdelay(500);
|
2005-04-16 15:20:36 -07:00
|
|
|
|
pending_newline = 1;
|
|
|
|
|
} else {
|
|
|
|
|
if (pending_newline) {
|
|
|
|
|
call_rtas_display_status('\r');
|
|
|
|
|
call_rtas_display_status('\n');
|
2023-11-06 07:42:58 -06:00
|
|
|
|
}
|
2005-04-16 15:20:36 -07:00
|
|
|
|
pending_newline = 0;
|
|
|
|
|
if (width--) {
|
|
|
|
|
call_rtas_display_status(c);
|
|
|
|
|
udelay(10000);
|
|
|
|
|
}
|
|
|
|
|
}
|
|
|
|
|
}
|
|
|
|
|
|
2006-06-23 18:20:16 +10:00
|
|
|
|
void __init udbg_init_rtas_panel(void)
|
2006-01-11 11:54:09 +11:00
|
|
|
|
{
|
|
|
|
|
udbg_putc = call_rtas_display_status_delay;
|
|
|
|
|
}
|
|
|
|
|
|
2006-06-23 18:20:16 +10:00
|
|
|
|
#ifdef CONFIG_UDBG_RTAS_CONSOLE
|
|
|
|
|
|
|
|
|
|
/* If you think you're dying before early_init_dt_scan_rtas() does its
|
|
|
|
|
* work, you can hard code the token values for your firmware here and
|
|
|
|
|
* hardcode rtas.base/entry etc.
|
|
|
|
|
*/
|
|
|
|
|
static unsigned int rtas_putchar_token = RTAS_UNKNOWN_SERVICE;
|
|
|
|
|
static unsigned int rtas_getchar_token = RTAS_UNKNOWN_SERVICE;
|
|
|
|
|
|
|
|
|
|
static void udbg_rtascon_putc(char c)
|
|
|
|
|
{
|
|
|
|
|
int tries;
|
|
|
|
|
|
|
|
|
|
if (!rtas.base)
|
|
|
|
|
return;
|
|
|
|
|
|
|
|
|
|
/* Add CRs before LFs */
|
|
|
|
|
if (c == '\n')
|
|
|
|
|
udbg_rtascon_putc('\r');
|
|
|
|
|
|
|
|
|
|
/* if there is more than one character to be displayed, wait a bit */
|
|
|
|
|
for (tries = 0; tries < 16; tries++) {
|
|
|
|
|
if (rtas_call(rtas_putchar_token, 1, 1, NULL, c) == 0)
|
|
|
|
|
break;
|
|
|
|
|
udelay(1000);
|
|
|
|
|
}
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
static int udbg_rtascon_getc_poll(void)
|
|
|
|
|
{
|
|
|
|
|
int c;
|
|
|
|
|
|
|
|
|
|
if (!rtas.base)
|
|
|
|
|
return -1;
|
|
|
|
|
|
|
|
|
|
if (rtas_call(rtas_getchar_token, 0, 2, &c))
|
|
|
|
|
return -1;
|
|
|
|
|
|
|
|
|
|
return c;
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
static int udbg_rtascon_getc(void)
|
|
|
|
|
{
|
|
|
|
|
int c;
|
|
|
|
|
|
|
|
|
|
while ((c = udbg_rtascon_getc_poll()) == -1)
|
|
|
|
|
;
|
|
|
|
|
|
|
|
|
|
return c;
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
void __init udbg_init_rtas_console(void)
|
|
|
|
|
{
|
|
|
|
|
udbg_putc = udbg_rtascon_putc;
|
|
|
|
|
udbg_getc = udbg_rtascon_getc;
|
|
|
|
|
udbg_getc_poll = udbg_rtascon_getc_poll;
|
|
|
|
|
}
|
|
|
|
|
#endif /* CONFIG_UDBG_RTAS_CONSOLE */
|
|
|
|
|
|
2005-10-26 17:05:24 +10:00
|
|
|
|
void rtas_progress(char *s, unsigned short hex)
|
2005-06-23 09:43:28 +10:00
|
|
|
|
{
|
|
|
|
|
struct device_node *root;
|
2006-07-12 15:35:54 +10:00
|
|
|
|
int width;
|
2013-08-07 02:01:29 +10:00
|
|
|
|
const __be32 *p;
|
2005-06-23 09:43:28 +10:00
|
|
|
|
char *os;
|
|
|
|
|
static int display_character, set_indicator;
|
2006-07-12 15:35:54 +10:00
|
|
|
|
static int display_width, display_lines, form_feed;
|
2007-02-17 20:11:19 +01:00
|
|
|
|
static const int *row_width;
|
2005-06-23 09:43:28 +10:00
|
|
|
|
static DEFINE_SPINLOCK(progress_lock);
|
2005-06-23 16:09:41 +10:00
|
|
|
|
static int current_line;
|
2005-06-23 09:43:28 +10:00
|
|
|
|
static int pending_newline = 0; /* did last write end with unprinted newline? */
|
|
|
|
|
|
|
|
|
|
if (!rtas.base)
|
|
|
|
|
return;
|
|
|
|
|
|
2005-06-23 16:09:41 +10:00
|
|
|
|
if (display_width == 0) {
|
|
|
|
|
display_width = 0x10;
|
2007-04-24 13:50:55 +10:00
|
|
|
|
if ((root = of_find_node_by_path("/rtas"))) {
|
2007-04-03 22:26:41 +10:00
|
|
|
|
if ((p = of_get_property(root,
|
2005-06-23 16:09:41 +10:00
|
|
|
|
"ibm,display-line-length", NULL)))
|
2013-08-07 02:01:29 +10:00
|
|
|
|
display_width = be32_to_cpu(*p);
|
2007-04-03 22:26:41 +10:00
|
|
|
|
if ((p = of_get_property(root,
|
2005-06-23 16:09:41 +10:00
|
|
|
|
"ibm,form-feed", NULL)))
|
2013-08-07 02:01:29 +10:00
|
|
|
|
form_feed = be32_to_cpu(*p);
|
2007-04-03 22:26:41 +10:00
|
|
|
|
if ((p = of_get_property(root,
|
2005-06-23 16:09:41 +10:00
|
|
|
|
"ibm,display-number-of-lines", NULL)))
|
2013-08-07 02:01:29 +10:00
|
|
|
|
display_lines = be32_to_cpu(*p);
|
2007-04-03 22:26:41 +10:00
|
|
|
|
row_width = of_get_property(root,
|
2005-06-23 16:09:41 +10:00
|
|
|
|
"ibm,display-truncation-length", NULL);
|
2007-04-24 13:50:55 +10:00
|
|
|
|
of_node_put(root);
|
2005-06-23 16:09:41 +10:00
|
|
|
|
}
|
2023-02-10 12:42:08 -06:00
|
|
|
|
display_character = rtas_function_token(RTAS_FN_DISPLAY_CHARACTER);
|
|
|
|
|
set_indicator = rtas_function_token(RTAS_FN_SET_INDICATOR);
|
2005-06-23 09:43:28 +10:00
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
if (display_character == RTAS_UNKNOWN_SERVICE) {
|
|
|
|
|
/* use hex display if available */
|
|
|
|
|
if (set_indicator != RTAS_UNKNOWN_SERVICE)
|
|
|
|
|
rtas_call(set_indicator, 3, 1, NULL, 6, 0, hex);
|
|
|
|
|
return;
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
spin_lock(&progress_lock);
|
|
|
|
|
|
|
|
|
|
/*
|
|
|
|
|
* Last write ended with newline, but we didn't print it since
|
|
|
|
|
* it would just clear the bottom line of output. Print it now
|
|
|
|
|
* instead.
|
|
|
|
|
*
|
2005-06-23 16:09:41 +10:00
|
|
|
|
* If no newline is pending and form feed is supported, clear the
|
|
|
|
|
* display with a form feed; otherwise, print a CR to start output
|
|
|
|
|
* at the beginning of the line.
|
2005-06-23 09:43:28 +10:00
|
|
|
|
*/
|
|
|
|
|
if (pending_newline) {
|
|
|
|
|
rtas_call(display_character, 1, 1, NULL, '\r');
|
|
|
|
|
rtas_call(display_character, 1, 1, NULL, '\n');
|
|
|
|
|
pending_newline = 0;
|
|
|
|
|
} else {
|
2005-06-23 16:09:41 +10:00
|
|
|
|
current_line = 0;
|
|
|
|
|
if (form_feed)
|
|
|
|
|
rtas_call(display_character, 1, 1, NULL,
|
|
|
|
|
(char)form_feed);
|
|
|
|
|
else
|
|
|
|
|
rtas_call(display_character, 1, 1, NULL, '\r');
|
2005-06-23 09:43:28 +10:00
|
|
|
|
}
|
2023-11-06 07:42:58 -06:00
|
|
|
|
|
2005-06-23 16:09:41 +10:00
|
|
|
|
if (row_width)
|
|
|
|
|
width = row_width[current_line];
|
|
|
|
|
else
|
|
|
|
|
width = display_width;
|
2005-06-23 09:43:28 +10:00
|
|
|
|
os = s;
|
|
|
|
|
while (*os) {
|
|
|
|
|
if (*os == '\n' || *os == '\r') {
|
|
|
|
|
/* If newline is the last character, save it
|
|
|
|
|
* until next call to avoid bumping up the
|
|
|
|
|
* display output.
|
|
|
|
|
*/
|
|
|
|
|
if (*os == '\n' && !os[1]) {
|
|
|
|
|
pending_newline = 1;
|
2005-06-23 16:09:41 +10:00
|
|
|
|
current_line++;
|
|
|
|
|
if (current_line > display_lines-1)
|
|
|
|
|
current_line = display_lines-1;
|
2005-06-23 09:43:28 +10:00
|
|
|
|
spin_unlock(&progress_lock);
|
|
|
|
|
return;
|
|
|
|
|
}
|
2023-11-06 07:42:58 -06:00
|
|
|
|
|
2005-06-23 09:43:28 +10:00
|
|
|
|
/* RTAS wants CR-LF, not just LF */
|
2023-11-06 07:42:58 -06:00
|
|
|
|
|
2005-06-23 09:43:28 +10:00
|
|
|
|
if (*os == '\n') {
|
|
|
|
|
rtas_call(display_character, 1, 1, NULL, '\r');
|
|
|
|
|
rtas_call(display_character, 1, 1, NULL, '\n');
|
|
|
|
|
} else {
|
|
|
|
|
/* CR might be used to re-draw a line, so we'll
|
|
|
|
|
* leave it alone and not add LF.
|
|
|
|
|
*/
|
|
|
|
|
rtas_call(display_character, 1, 1, NULL, *os);
|
|
|
|
|
}
|
2023-11-06 07:42:58 -06:00
|
|
|
|
|
2005-06-23 16:09:41 +10:00
|
|
|
|
if (row_width)
|
|
|
|
|
width = row_width[current_line];
|
|
|
|
|
else
|
|
|
|
|
width = display_width;
|
2005-06-23 09:43:28 +10:00
|
|
|
|
} else {
|
|
|
|
|
width--;
|
|
|
|
|
rtas_call(display_character, 1, 1, NULL, *os);
|
|
|
|
|
}
|
2023-11-06 07:42:58 -06:00
|
|
|
|
|
2005-06-23 09:43:28 +10:00
|
|
|
|
os++;
|
2023-11-06 07:42:58 -06:00
|
|
|
|
|
2005-06-23 09:43:28 +10:00
|
|
|
|
/* if we overwrite the screen length */
|
|
|
|
|
if (width <= 0)
|
|
|
|
|
while ((*os != 0) && (*os != '\n') && (*os != '\r'))
|
|
|
|
|
os++;
|
|
|
|
|
}
|
2023-11-06 07:42:58 -06:00
|
|
|
|
|
2005-06-23 09:43:28 +10:00
|
|
|
|
spin_unlock(&progress_lock);
|
|
|
|
|
}
|
2023-01-24 08:04:46 -06:00
|
|
|
|
EXPORT_SYMBOL_GPL(rtas_progress); /* needed by rtas_flash module */
|
2005-06-23 09:43:28 +10:00
|
|
|
|
|
2005-10-26 17:05:24 +10:00
|
|
|
|
int rtas_token(const char *service)
|
2005-04-16 15:20:36 -07:00
|
|
|
|
{
|
powerpc/rtas: improve function information lookups
The core RTAS support code and its clients perform two types of lookup
for RTAS firmware function information.
First, mapping a known function name to a token. The typical use case
invokes rtas_token() to retrieve the token value to pass to
rtas_call(). rtas_token() relies on of_get_property(), which performs
a linear search of the /rtas node's property list under a lock with
IRQs disabled.
Second, and less common: given a token value, looking up some
information about the function. The primary example is the sys_rtas
filter path, which linearly scans a small table to match the token to
a rtas_filter struct. Another use case to come is RTAS entry/exit
tracepoints, which will require efficient lookup of function names
from token values. Currently there is no general API for this.
We need something much like the existing rtas_filters table, but more
general and organized to facilitate efficient lookups.
Introduce:
* A new rtas_function type, aggregating function name, token,
and filter. Other function characteristics could be added in the
future.
* An array of rtas_function, where each element corresponds to a known
RTAS function. All information in the table is static save the token
values, which are derived from the device tree at boot. The array is
sorted by function name to allow binary search.
* A named constant for each known RTAS function, used to index the
function array. These also will be used in a client-facing API to be
added later.
* An xarray that maps valid tokens to rtas_function objects.
Fold the existing rtas_filter table into the new rtas_function array,
with the appropriate adjustments to block_rtas_call(). Remove
now-redundant fields from struct rtas_filter. Preserve the function of
the CONFIG_CPU_BIG_ENDIAN guard in the current filter table by
introducing a per-function flag that is set for the function entries
related to pseries LPAR migration. These have never had working users
via sys_rtas on ppc64le; see commit de0f7349a0dd ("powerpc/rtas:
prevent suspend-related sys_rtas use on LE").
Convert rtas_token() to use a lockless binary search on the function
table. Fall back to the old behavior for lookups against names that
are not known to be RTAS functions, but issue a warning. rtas_token()
is for function names; it is not a general facility for accessing
arbitrary properties of the /rtas node. All known misuses of
rtas_token() have been converted to more appropriate of_ APIs in
preceding changes.
Signed-off-by: Nathan Lynch <nathanl@linux.ibm.com>
Signed-off-by: Michael Ellerman <mpe@ellerman.id.au>
Link: https://lore.kernel.org/r/20230125-b4-powerpc-rtas-queue-v3-8-26929c8cce78@linux.ibm.com
2023-02-10 12:41:56 -06:00
|
|
|
|
const struct rtas_function *func;
|
2013-08-07 02:01:29 +10:00
|
|
|
|
const __be32 *tokp;
|
powerpc/rtas: improve function information lookups
The core RTAS support code and its clients perform two types of lookup
for RTAS firmware function information.
First, mapping a known function name to a token. The typical use case
invokes rtas_token() to retrieve the token value to pass to
rtas_call(). rtas_token() relies on of_get_property(), which performs
a linear search of the /rtas node's property list under a lock with
IRQs disabled.
Second, and less common: given a token value, looking up some
information about the function. The primary example is the sys_rtas
filter path, which linearly scans a small table to match the token to
a rtas_filter struct. Another use case to come is RTAS entry/exit
tracepoints, which will require efficient lookup of function names
from token values. Currently there is no general API for this.
We need something much like the existing rtas_filters table, but more
general and organized to facilitate efficient lookups.
Introduce:
* A new rtas_function type, aggregating function name, token,
and filter. Other function characteristics could be added in the
future.
* An array of rtas_function, where each element corresponds to a known
RTAS function. All information in the table is static save the token
values, which are derived from the device tree at boot. The array is
sorted by function name to allow binary search.
* A named constant for each known RTAS function, used to index the
function array. These also will be used in a client-facing API to be
added later.
* An xarray that maps valid tokens to rtas_function objects.
Fold the existing rtas_filter table into the new rtas_function array,
with the appropriate adjustments to block_rtas_call(). Remove
now-redundant fields from struct rtas_filter. Preserve the function of
the CONFIG_CPU_BIG_ENDIAN guard in the current filter table by
introducing a per-function flag that is set for the function entries
related to pseries LPAR migration. These have never had working users
via sys_rtas on ppc64le; see commit de0f7349a0dd ("powerpc/rtas:
prevent suspend-related sys_rtas use on LE").
Convert rtas_token() to use a lockless binary search on the function
table. Fall back to the old behavior for lookups against names that
are not known to be RTAS functions, but issue a warning. rtas_token()
is for function names; it is not a general facility for accessing
arbitrary properties of the /rtas node. All known misuses of
rtas_token() have been converted to more appropriate of_ APIs in
preceding changes.
Signed-off-by: Nathan Lynch <nathanl@linux.ibm.com>
Signed-off-by: Michael Ellerman <mpe@ellerman.id.au>
Link: https://lore.kernel.org/r/20230125-b4-powerpc-rtas-queue-v3-8-26929c8cce78@linux.ibm.com
2023-02-10 12:41:56 -06:00
|
|
|
|
|
2005-10-26 17:05:24 +10:00
|
|
|
|
if (rtas.dev == NULL)
|
2005-04-16 15:20:36 -07:00
|
|
|
|
return RTAS_UNKNOWN_SERVICE;
|
powerpc/rtas: improve function information lookups
The core RTAS support code and its clients perform two types of lookup
for RTAS firmware function information.
First, mapping a known function name to a token. The typical use case
invokes rtas_token() to retrieve the token value to pass to
rtas_call(). rtas_token() relies on of_get_property(), which performs
a linear search of the /rtas node's property list under a lock with
IRQs disabled.
Second, and less common: given a token value, looking up some
information about the function. The primary example is the sys_rtas
filter path, which linearly scans a small table to match the token to
a rtas_filter struct. Another use case to come is RTAS entry/exit
tracepoints, which will require efficient lookup of function names
from token values. Currently there is no general API for this.
We need something much like the existing rtas_filters table, but more
general and organized to facilitate efficient lookups.
Introduce:
* A new rtas_function type, aggregating function name, token,
and filter. Other function characteristics could be added in the
future.
* An array of rtas_function, where each element corresponds to a known
RTAS function. All information in the table is static save the token
values, which are derived from the device tree at boot. The array is
sorted by function name to allow binary search.
* A named constant for each known RTAS function, used to index the
function array. These also will be used in a client-facing API to be
added later.
* An xarray that maps valid tokens to rtas_function objects.
Fold the existing rtas_filter table into the new rtas_function array,
with the appropriate adjustments to block_rtas_call(). Remove
now-redundant fields from struct rtas_filter. Preserve the function of
the CONFIG_CPU_BIG_ENDIAN guard in the current filter table by
introducing a per-function flag that is set for the function entries
related to pseries LPAR migration. These have never had working users
via sys_rtas on ppc64le; see commit de0f7349a0dd ("powerpc/rtas:
prevent suspend-related sys_rtas use on LE").
Convert rtas_token() to use a lockless binary search on the function
table. Fall back to the old behavior for lookups against names that
are not known to be RTAS functions, but issue a warning. rtas_token()
is for function names; it is not a general facility for accessing
arbitrary properties of the /rtas node. All known misuses of
rtas_token() have been converted to more appropriate of_ APIs in
preceding changes.
Signed-off-by: Nathan Lynch <nathanl@linux.ibm.com>
Signed-off-by: Michael Ellerman <mpe@ellerman.id.au>
Link: https://lore.kernel.org/r/20230125-b4-powerpc-rtas-queue-v3-8-26929c8cce78@linux.ibm.com
2023-02-10 12:41:56 -06:00
|
|
|
|
|
|
|
|
|
func = rtas_name_to_function(service);
|
|
|
|
|
if (func)
|
|
|
|
|
return func->token;
|
|
|
|
|
/*
|
|
|
|
|
* The caller is looking up a name that is not known to be an
|
|
|
|
|
* RTAS function. Either it's a function that needs to be
|
|
|
|
|
* added to the table, or they're misusing rtas_token() to
|
|
|
|
|
* access non-function properties of the /rtas node. Warn and
|
|
|
|
|
* fall back to the legacy behavior.
|
|
|
|
|
*/
|
|
|
|
|
WARN_ONCE(1, "unknown function `%s`, should it be added to rtas_function_table?\n",
|
|
|
|
|
service);
|
|
|
|
|
|
2007-04-03 22:26:41 +10:00
|
|
|
|
tokp = of_get_property(rtas.dev, service, NULL);
|
2013-08-07 02:01:29 +10:00
|
|
|
|
return tokp ? be32_to_cpu(*tokp) : RTAS_UNKNOWN_SERVICE;
|
2005-04-16 15:20:36 -07:00
|
|
|
|
}
|
2023-01-24 08:04:46 -06:00
|
|
|
|
EXPORT_SYMBOL_GPL(rtas_token);
|
2005-04-16 15:20:36 -07:00
|
|
|
|
|
2005-10-26 17:05:24 +10:00
|
|
|
|
#ifdef CONFIG_RTAS_ERROR_LOGGING
|
2022-11-18 09:07:44 -06:00
|
|
|
|
|
|
|
|
|
static u32 rtas_error_log_max __ro_after_init = RTAS_ERROR_LOG_MAX;
|
|
|
|
|
|
2005-04-16 15:20:36 -07:00
|
|
|
|
/*
|
|
|
|
|
* Return the firmware-specified size of the error log buffer
|
|
|
|
|
* for all rtas calls that require an error buffer argument.
|
|
|
|
|
* This includes 'check-exception' and 'rtas-last-error'.
|
|
|
|
|
*/
|
|
|
|
|
int rtas_get_error_log_max(void)
|
|
|
|
|
{
|
|
|
|
|
return rtas_error_log_max;
|
|
|
|
|
}
|
|
|
|
|
|
2022-11-18 09:07:44 -06:00
|
|
|
|
static void __init init_error_log_max(void)
|
|
|
|
|
{
|
|
|
|
|
static const char propname[] __initconst = "rtas-error-log-max";
|
|
|
|
|
u32 max;
|
|
|
|
|
|
|
|
|
|
if (of_property_read_u32(rtas.dev, propname, &max)) {
|
|
|
|
|
pr_warn("%s not found, using default of %u\n",
|
|
|
|
|
propname, RTAS_ERROR_LOG_MAX);
|
|
|
|
|
max = RTAS_ERROR_LOG_MAX;
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
if (max > RTAS_ERROR_LOG_MAX) {
|
|
|
|
|
pr_warn("%s = %u, clamping max error log size to %u\n",
|
|
|
|
|
propname, max, RTAS_ERROR_LOG_MAX);
|
|
|
|
|
max = RTAS_ERROR_LOG_MAX;
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
rtas_error_log_max = max;
|
|
|
|
|
}
|
|
|
|
|
|
2005-04-16 15:20:36 -07:00
|
|
|
|
|
2008-05-08 14:27:19 +10:00
|
|
|
|
static char rtas_err_buf[RTAS_ERROR_LOG_MAX];
|
2005-10-26 17:05:24 +10:00
|
|
|
|
|
2005-04-16 15:20:36 -07:00
|
|
|
|
/** Return a copy of the detailed error text associated with the
|
|
|
|
|
* most recent failed call to rtas. Because the error text
|
|
|
|
|
* might go stale if there are any other intervening rtas calls,
|
|
|
|
|
* this routine must be called atomically with whatever produced
|
2023-01-24 08:04:47 -06:00
|
|
|
|
* the error (i.e. with rtas_lock still held from the previous call).
|
2005-04-16 15:20:36 -07:00
|
|
|
|
*/
|
2005-10-26 17:05:24 +10:00
|
|
|
|
static char *__fetch_rtas_last_error(char *altbuf)
|
2005-04-16 15:20:36 -07:00
|
|
|
|
{
|
2023-02-10 12:42:08 -06:00
|
|
|
|
const s32 token = rtas_function_token(RTAS_FN_RTAS_LAST_ERROR);
|
2005-04-16 15:20:36 -07:00
|
|
|
|
struct rtas_args err_args, save_args;
|
|
|
|
|
u32 bufsz;
|
2005-10-26 17:05:24 +10:00
|
|
|
|
char *buf = NULL;
|
|
|
|
|
|
2023-03-06 15:33:45 -06:00
|
|
|
|
lockdep_assert_held(&rtas_lock);
|
|
|
|
|
|
2023-02-10 12:42:08 -06:00
|
|
|
|
if (token == -1)
|
2005-10-26 17:05:24 +10:00
|
|
|
|
return NULL;
|
2005-04-16 15:20:36 -07:00
|
|
|
|
|
|
|
|
|
bufsz = rtas_get_error_log_max();
|
|
|
|
|
|
2023-02-10 12:42:08 -06:00
|
|
|
|
err_args.token = cpu_to_be32(token);
|
2013-08-07 02:01:31 +10:00
|
|
|
|
err_args.nargs = cpu_to_be32(2);
|
|
|
|
|
err_args.nret = cpu_to_be32(1);
|
|
|
|
|
err_args.args[0] = cpu_to_be32(__pa(rtas_err_buf));
|
|
|
|
|
err_args.args[1] = cpu_to_be32(bufsz);
|
2005-04-16 15:20:36 -07:00
|
|
|
|
err_args.args[2] = 0;
|
|
|
|
|
|
2023-01-24 08:04:47 -06:00
|
|
|
|
save_args = rtas_args;
|
|
|
|
|
rtas_args = err_args;
|
2005-04-16 15:20:36 -07:00
|
|
|
|
|
2023-02-10 12:41:57 -06:00
|
|
|
|
do_enter_rtas(&rtas_args);
|
2005-04-16 15:20:36 -07:00
|
|
|
|
|
2023-01-24 08:04:47 -06:00
|
|
|
|
err_args = rtas_args;
|
|
|
|
|
rtas_args = save_args;
|
2005-04-16 15:20:36 -07:00
|
|
|
|
|
2005-10-26 17:05:24 +10:00
|
|
|
|
/* Log the error in the unlikely case that there was one. */
|
|
|
|
|
if (unlikely(err_args.args[2] == 0)) {
|
|
|
|
|
if (altbuf) {
|
|
|
|
|
buf = altbuf;
|
|
|
|
|
} else {
|
|
|
|
|
buf = rtas_err_buf;
|
2015-03-30 14:10:37 +11:00
|
|
|
|
if (slab_is_available())
|
2005-10-26 17:05:24 +10:00
|
|
|
|
buf = kmalloc(RTAS_ERROR_LOG_MAX, GFP_ATOMIC);
|
|
|
|
|
}
|
|
|
|
|
if (buf)
|
2023-03-06 15:33:41 -06:00
|
|
|
|
memmove(buf, rtas_err_buf, RTAS_ERROR_LOG_MAX);
|
2005-10-26 17:05:24 +10:00
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
return buf;
|
2005-04-16 15:20:36 -07:00
|
|
|
|
}
|
|
|
|
|
|
2005-10-26 17:05:24 +10:00
|
|
|
|
#define get_errorlog_buffer() kmalloc(RTAS_ERROR_LOG_MAX, GFP_KERNEL)
|
|
|
|
|
|
|
|
|
|
#else /* CONFIG_RTAS_ERROR_LOGGING */
|
|
|
|
|
#define __fetch_rtas_last_error(x) NULL
|
|
|
|
|
#define get_errorlog_buffer() NULL
|
2022-11-18 09:07:44 -06:00
|
|
|
|
static void __init init_error_log_max(void) {}
|
2005-10-26 17:05:24 +10:00
|
|
|
|
#endif
|
|
|
|
|
|
2015-12-16 21:01:42 +11:00
|
|
|
|
|
|
|
|
|
static void
|
|
|
|
|
va_rtas_call_unlocked(struct rtas_args *args, int token, int nargs, int nret,
|
|
|
|
|
va_list list)
|
|
|
|
|
{
|
|
|
|
|
int i;
|
|
|
|
|
|
|
|
|
|
args->token = cpu_to_be32(token);
|
|
|
|
|
args->nargs = cpu_to_be32(nargs);
|
|
|
|
|
args->nret = cpu_to_be32(nret);
|
|
|
|
|
args->rets = &(args->args[nargs]);
|
|
|
|
|
|
|
|
|
|
for (i = 0; i < nargs; ++i)
|
|
|
|
|
args->args[i] = cpu_to_be32(va_arg(list, __u32));
|
|
|
|
|
|
|
|
|
|
for (i = 0; i < nret; ++i)
|
|
|
|
|
args->rets[i] = 0;
|
|
|
|
|
|
2023-02-10 12:41:57 -06:00
|
|
|
|
do_enter_rtas(args);
|
2015-12-16 21:01:42 +11:00
|
|
|
|
}
|
|
|
|
|
|
2023-03-06 15:33:42 -06:00
|
|
|
|
/**
|
|
|
|
|
* rtas_call_unlocked() - Invoke an RTAS firmware function without synchronization.
|
|
|
|
|
* @args: RTAS parameter block to be used for the call, must obey RTAS addressing
|
|
|
|
|
* constraints.
|
|
|
|
|
* @token: Identifies the function being invoked.
|
|
|
|
|
* @nargs: Number of input parameters. Does not include token.
|
|
|
|
|
* @nret: Number of output parameters, including the call status.
|
|
|
|
|
* @....: List of @nargs input parameters.
|
|
|
|
|
*
|
|
|
|
|
* Invokes the RTAS function indicated by @token, which the caller
|
|
|
|
|
* should obtain via rtas_function_token().
|
|
|
|
|
*
|
|
|
|
|
* This function is similar to rtas_call(), but must be used with a
|
|
|
|
|
* limited set of RTAS calls specifically exempted from the general
|
|
|
|
|
* requirement that only one RTAS call may be in progress at any
|
|
|
|
|
* time. Examples include stop-self and ibm,nmi-interlock.
|
|
|
|
|
*/
|
2015-12-16 21:01:42 +11:00
|
|
|
|
void rtas_call_unlocked(struct rtas_args *args, int token, int nargs, int nret, ...)
|
|
|
|
|
{
|
|
|
|
|
va_list list;
|
|
|
|
|
|
|
|
|
|
va_start(list, nret);
|
|
|
|
|
va_rtas_call_unlocked(args, token, nargs, nret, list);
|
|
|
|
|
va_end(list);
|
|
|
|
|
}
|
|
|
|
|
|
2023-02-10 12:42:08 -06:00
|
|
|
|
static bool token_is_restricted_errinjct(s32 token)
|
|
|
|
|
{
|
|
|
|
|
return token == rtas_function_token(RTAS_FN_IBM_OPEN_ERRINJCT) ||
|
|
|
|
|
token == rtas_function_token(RTAS_FN_IBM_ERRINJCT);
|
|
|
|
|
}
|
2022-09-26 08:16:43 -05:00
|
|
|
|
|
2022-11-18 09:07:39 -06:00
|
|
|
|
/**
|
|
|
|
|
* rtas_call() - Invoke an RTAS firmware function.
|
|
|
|
|
* @token: Identifies the function being invoked.
|
|
|
|
|
* @nargs: Number of input parameters. Does not include token.
|
|
|
|
|
* @nret: Number of output parameters, including the call status.
|
|
|
|
|
* @outputs: Array of @nret output words.
|
|
|
|
|
* @....: List of @nargs input parameters.
|
|
|
|
|
*
|
|
|
|
|
* Invokes the RTAS function indicated by @token, which the caller
|
2023-02-10 12:42:07 -06:00
|
|
|
|
* should obtain via rtas_function_token().
|
2022-11-18 09:07:39 -06:00
|
|
|
|
*
|
|
|
|
|
* The @nargs and @nret arguments must match the number of input and
|
|
|
|
|
* output parameters specified for the RTAS function.
|
|
|
|
|
*
|
|
|
|
|
* rtas_call() returns RTAS status codes, not conventional Linux errno
|
|
|
|
|
* values. Callers must translate any failure to an appropriate errno
|
|
|
|
|
* in syscall context. Most callers of RTAS functions that can return
|
|
|
|
|
* -2 or 990x should use rtas_busy_delay() to correctly handle those
|
|
|
|
|
* statuses before calling again.
|
|
|
|
|
*
|
|
|
|
|
* The return value descriptions are adapted from 7.2.8 [RTAS] Return
|
|
|
|
|
* Codes of the PAPR and CHRP specifications.
|
|
|
|
|
*
|
|
|
|
|
* Context: Process context preferably, interrupt context if
|
|
|
|
|
* necessary. Acquires an internal spinlock and may perform
|
|
|
|
|
* GFP_ATOMIC slab allocation in error path. Unsafe for NMI
|
|
|
|
|
* context.
|
|
|
|
|
* Return:
|
|
|
|
|
* * 0 - RTAS function call succeeded.
|
|
|
|
|
* * -1 - RTAS function encountered a hardware or
|
|
|
|
|
* platform error, or the token is invalid,
|
|
|
|
|
* or the function is restricted by kernel policy.
|
|
|
|
|
* * -2 - Specs say "A necessary hardware device was busy,
|
|
|
|
|
* and the requested function could not be
|
|
|
|
|
* performed. The operation should be retried at
|
|
|
|
|
* a later time." This is misleading, at least with
|
|
|
|
|
* respect to current RTAS implementations. What it
|
|
|
|
|
* usually means in practice is that the function
|
|
|
|
|
* could not be completed while meeting RTAS's
|
|
|
|
|
* deadline for returning control to the OS (250us
|
|
|
|
|
* for PAPR/PowerVM, typically), but the call may be
|
|
|
|
|
* immediately reattempted to resume work on it.
|
|
|
|
|
* * -3 - Parameter error.
|
|
|
|
|
* * -7 - Unexpected state change.
|
|
|
|
|
* * 9000...9899 - Vendor-specific success codes.
|
|
|
|
|
* * 9900...9905 - Advisory extended delay. Caller should try
|
|
|
|
|
* again after ~10^x ms has elapsed, where x is
|
|
|
|
|
* the last digit of the status [0-5]. Again going
|
|
|
|
|
* beyond the PAPR text, 990x on PowerVM indicates
|
|
|
|
|
* contention for RTAS-internal resources. Other
|
|
|
|
|
* RTAS call sequences in progress should be
|
|
|
|
|
* allowed to complete before reattempting the
|
|
|
|
|
* call.
|
|
|
|
|
* * -9000 - Multi-level isolation error.
|
|
|
|
|
* * -9999...-9004 - Vendor-specific error codes.
|
|
|
|
|
* * Additional negative values - Function-specific error.
|
|
|
|
|
* * Additional positive values - Function-specific success.
|
|
|
|
|
*/
|
2005-04-16 15:20:36 -07:00
|
|
|
|
int rtas_call(int token, int nargs, int nret, int *outputs, ...)
|
|
|
|
|
{
|
2023-03-06 15:33:45 -06:00
|
|
|
|
struct pin_cookie cookie;
|
2005-04-16 15:20:36 -07:00
|
|
|
|
va_list list;
|
2005-10-26 17:05:24 +10:00
|
|
|
|
int i;
|
2023-01-24 08:04:48 -06:00
|
|
|
|
unsigned long flags;
|
2023-01-24 08:04:47 -06:00
|
|
|
|
struct rtas_args *args;
|
2005-10-26 17:05:24 +10:00
|
|
|
|
char *buff_copy = NULL;
|
2005-04-16 15:20:36 -07:00
|
|
|
|
int ret;
|
|
|
|
|
|
2006-06-23 18:20:10 +10:00
|
|
|
|
if (!rtas.entry || token == RTAS_UNKNOWN_SERVICE)
|
2005-04-16 15:20:36 -07:00
|
|
|
|
return -1;
|
|
|
|
|
|
2023-02-10 12:42:08 -06:00
|
|
|
|
if (token_is_restricted_errinjct(token)) {
|
2022-09-26 08:16:43 -05:00
|
|
|
|
/*
|
|
|
|
|
* It would be nicer to not discard the error value
|
|
|
|
|
* from security_locked_down(), but callers expect an
|
|
|
|
|
* RTAS status, not an errno.
|
|
|
|
|
*/
|
|
|
|
|
if (security_locked_down(LOCKDOWN_RTAS_ERROR_INJECTION))
|
|
|
|
|
return -1;
|
|
|
|
|
}
|
|
|
|
|
|
2022-03-08 23:50:46 +10:00
|
|
|
|
if ((mfmsr() & (MSR_IR|MSR_DR)) != (MSR_IR|MSR_DR)) {
|
|
|
|
|
WARN_ON_ONCE(1);
|
|
|
|
|
return -1;
|
|
|
|
|
}
|
|
|
|
|
|
2023-01-24 08:04:48 -06:00
|
|
|
|
raw_spin_lock_irqsave(&rtas_lock, flags);
|
2023-03-06 15:33:45 -06:00
|
|
|
|
cookie = lockdep_pin_lock(&rtas_lock);
|
|
|
|
|
|
2015-12-16 21:01:42 +11:00
|
|
|
|
/* We use the global rtas args buffer */
|
2023-01-24 08:04:47 -06:00
|
|
|
|
args = &rtas_args;
|
2005-04-16 15:20:36 -07:00
|
|
|
|
|
|
|
|
|
va_start(list, outputs);
|
2023-01-24 08:04:47 -06:00
|
|
|
|
va_rtas_call_unlocked(args, token, nargs, nret, list);
|
2005-04-16 15:20:36 -07:00
|
|
|
|
va_end(list);
|
|
|
|
|
|
|
|
|
|
/* A -1 return code indicates that the last command couldn't
|
|
|
|
|
be completed due to a hardware error. */
|
2023-01-24 08:04:47 -06:00
|
|
|
|
if (be32_to_cpu(args->rets[0]) == -1)
|
2005-10-26 17:05:24 +10:00
|
|
|
|
buff_copy = __fetch_rtas_last_error(NULL);
|
2005-04-16 15:20:36 -07:00
|
|
|
|
|
|
|
|
|
if (nret > 1 && outputs != NULL)
|
|
|
|
|
for (i = 0; i < nret-1; ++i)
|
2023-01-24 08:04:47 -06:00
|
|
|
|
outputs[i] = be32_to_cpu(args->rets[i + 1]);
|
|
|
|
|
ret = (nret > 0) ? be32_to_cpu(args->rets[0]) : 0;
|
2005-04-16 15:20:36 -07:00
|
|
|
|
|
2023-03-06 15:33:45 -06:00
|
|
|
|
lockdep_unpin_lock(&rtas_lock, cookie);
|
2023-01-24 08:04:48 -06:00
|
|
|
|
raw_spin_unlock_irqrestore(&rtas_lock, flags);
|
2005-04-16 15:20:36 -07:00
|
|
|
|
|
|
|
|
|
if (buff_copy) {
|
|
|
|
|
log_error(buff_copy, ERR_TYPE_RTAS_LOG, 0);
|
2015-03-30 14:10:37 +11:00
|
|
|
|
if (slab_is_available())
|
2005-04-16 15:20:36 -07:00
|
|
|
|
kfree(buff_copy);
|
|
|
|
|
}
|
|
|
|
|
return ret;
|
|
|
|
|
}
|
2023-01-24 08:04:46 -06:00
|
|
|
|
EXPORT_SYMBOL_GPL(rtas_call);
|
2005-04-16 15:20:36 -07:00
|
|
|
|
|
2021-11-17 00:02:59 -06:00
|
|
|
|
/**
|
|
|
|
|
* rtas_busy_delay_time() - From an RTAS status value, calculate the
|
|
|
|
|
* suggested delay time in milliseconds.
|
|
|
|
|
*
|
|
|
|
|
* @status: a value returned from rtas_call() or similar APIs which return
|
|
|
|
|
* the status of a RTAS function call.
|
|
|
|
|
*
|
|
|
|
|
* Context: Any context.
|
|
|
|
|
*
|
|
|
|
|
* Return:
|
|
|
|
|
* * 100000 - If @status is 9905.
|
|
|
|
|
* * 10000 - If @status is 9904.
|
|
|
|
|
* * 1000 - If @status is 9903.
|
|
|
|
|
* * 100 - If @status is 9902.
|
|
|
|
|
* * 10 - If @status is 9901.
|
|
|
|
|
* * 1 - If @status is either 9900 or -2. This is "wrong" for -2, but
|
|
|
|
|
* some callers depend on this behavior, and the worst outcome
|
|
|
|
|
* is that they will delay for longer than necessary.
|
|
|
|
|
* * 0 - If @status is not a busy or extended delay value.
|
2005-04-16 15:20:36 -07:00
|
|
|
|
*/
|
2006-06-05 16:31:48 -05:00
|
|
|
|
unsigned int rtas_busy_delay_time(int status)
|
2005-04-16 15:20:36 -07:00
|
|
|
|
{
|
2006-06-05 16:31:48 -05:00
|
|
|
|
int order;
|
|
|
|
|
unsigned int ms = 0;
|
|
|
|
|
|
|
|
|
|
if (status == RTAS_BUSY) {
|
|
|
|
|
ms = 1;
|
2015-07-22 18:56:47 +02:00
|
|
|
|
} else if (status >= RTAS_EXTENDED_DELAY_MIN &&
|
|
|
|
|
status <= RTAS_EXTENDED_DELAY_MAX) {
|
|
|
|
|
order = status - RTAS_EXTENDED_DELAY_MIN;
|
2006-06-05 16:31:48 -05:00
|
|
|
|
for (ms = 1; order > 0; order--)
|
|
|
|
|
ms *= 10;
|
|
|
|
|
}
|
2005-04-16 15:20:36 -07:00
|
|
|
|
|
2006-06-05 16:31:48 -05:00
|
|
|
|
return ms;
|
|
|
|
|
}
|
2005-04-16 15:20:36 -07:00
|
|
|
|
|
powerpc/rtas: handle extended delays safely in early boot
Some code that runs early in boot calls RTAS functions that can return
-2 or 990x statuses, which mean the caller should retry. An example is
pSeries_cmo_feature_init(), which invokes ibm,get-system-parameter but
treats these benign statuses as errors instead of retrying.
pSeries_cmo_feature_init() and similar code should be made to retry
until they succeed or receive a real error, using the usual pattern:
do {
rc = rtas_call(token, etc...);
} while (rtas_busy_delay(rc));
But rtas_busy_delay() will perform a timed sleep on any 990x
status. This isn't safe so early in boot, before the CPU scheduler and
timer subsystem have initialized.
The -2 RTAS status is much more likely to occur during single-threaded
boot than 990x in practice, at least on PowerVM. This is because -2
usually means that RTAS made progress but exhausted its self-imposed
timeslice, while 990x is associated with concurrent requests from the
OS causing internal contention. Regardless, according to the language
in PAPR, the OS should be prepared to handle either type of status at
any time.
Add a fallback path to rtas_busy_delay() to handle this as safely as
possible, performing a small delay on 990x. Include a counter to
detect retry loops that aren't making progress and bail out. Add __ref
to rtas_busy_delay() since it now conditionally calls an __init
function.
This was found by inspection and I'm not aware of any real
failures. However, the implementation of rtas_busy_delay() before
commit 38f7b7067dae ("powerpc/rtas: rtas_busy_delay() improvements")
was not susceptible to this problem, so let's treat this as a
regression.
Signed-off-by: Nathan Lynch <nathanl@linux.ibm.com>
Fixes: 38f7b7067dae ("powerpc/rtas: rtas_busy_delay() improvements")
Signed-off-by: Michael Ellerman <mpe@ellerman.id.au>
Link: https://lore.kernel.org/r/20230125-b4-powerpc-rtas-queue-v3-1-26929c8cce78@linux.ibm.com
2023-02-10 12:41:49 -06:00
|
|
|
|
/*
|
|
|
|
|
* Early boot fallback for rtas_busy_delay().
|
|
|
|
|
*/
|
|
|
|
|
static bool __init rtas_busy_delay_early(int status)
|
|
|
|
|
{
|
|
|
|
|
static size_t successive_ext_delays __initdata;
|
|
|
|
|
bool retry;
|
|
|
|
|
|
|
|
|
|
switch (status) {
|
|
|
|
|
case RTAS_EXTENDED_DELAY_MIN...RTAS_EXTENDED_DELAY_MAX:
|
|
|
|
|
/*
|
|
|
|
|
* In the unlikely case that we receive an extended
|
|
|
|
|
* delay status in early boot, the OS is probably not
|
|
|
|
|
* the cause, and there's nothing we can do to clear
|
|
|
|
|
* the condition. Best we can do is delay for a bit
|
|
|
|
|
* and hope it's transient. Lie to the caller if it
|
|
|
|
|
* seems like we're stuck in a retry loop.
|
|
|
|
|
*/
|
|
|
|
|
mdelay(1);
|
|
|
|
|
retry = true;
|
|
|
|
|
successive_ext_delays += 1;
|
|
|
|
|
if (successive_ext_delays > 1000) {
|
|
|
|
|
pr_err("too many extended delays, giving up\n");
|
|
|
|
|
dump_stack();
|
|
|
|
|
retry = false;
|
|
|
|
|
successive_ext_delays = 0;
|
|
|
|
|
}
|
|
|
|
|
break;
|
|
|
|
|
case RTAS_BUSY:
|
|
|
|
|
retry = true;
|
|
|
|
|
successive_ext_delays = 0;
|
|
|
|
|
break;
|
|
|
|
|
default:
|
|
|
|
|
retry = false;
|
|
|
|
|
successive_ext_delays = 0;
|
|
|
|
|
break;
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
return retry;
|
|
|
|
|
}
|
|
|
|
|
|
powerpc/rtas: rtas_busy_delay() improvements
Generally RTAS cannot block, and in PAPR it is required to return control
to the OS within a few tens of microseconds. In order to support operations
which may take longer to complete, many RTAS primitives can return
intermediate -2 ("busy") or 990x ("extended delay") values, which indicate
that the OS should reattempt the same call with the same arguments at some
point in the future.
Current versions of PAPR are less than clear about this, but the intended
meanings of these values in more detail are:
RTAS_BUSY (-2): RTAS has suspended a potentially long-running operation in
order to meet its latency obligation and give the OS the opportunity to
perform other work. RTAS can resume making progress as soon as the OS
reattempts the call.
RTAS_EXTENDED_DELAY_{MIN...MAX} (9900-9905): RTAS must wait for an external
event to occur or for internal contention to resolve before it can complete
the requested operation. The value encodes a non-binding hint as to roughly
how long the OS should wait before calling again, but the OS is allowed to
reattempt the call sooner or even immediately.
Linux of course must take its own CPU scheduling obligations into account
when handling these statuses; e.g. a task which receives an RTAS_BUSY
status should check whether to reschedule before it attempts the RTAS call
again to avoid starving other tasks.
rtas_busy_delay() is a helper function that "consumes" a busy or extended
delay status. Common usage:
int rc;
do {
rc = rtas_call(rtas_token("some-function"), ...);
} while (rtas_busy_delay(rc));
/* convert rc to Linux error value, etc */
If rc is a busy or extended delay status, the caller can rely on
rtas_busy_delay() to perform an appropriate sleep or reschedule and return
nonzero. Other statuses are handled normally by the caller.
The current implementation of rtas_busy_delay() both oversleeps and
overuses the CPU:
* It performs msleep() for all 990x and even when no delay is
suggested (-2), but this is understood to actually sleep for two jiffies
minimum in practice (20ms with HZ=100). 9900 (1ms) and 9901 (10ms)
appear to be the most common extended delay statuses, and the
oversleeping measurably lengthens DLPAR operations, which perform
many RTAS calls.
* It does not sleep on 990x unless need_resched() is true, causing code
like the loop above to needlessly retry, wasting CPU time.
Alter the logic to align better with the intended meanings:
* When passed RTAS_BUSY, perform cond_resched() and return without
sleeping. The caller should reattempt immediately
* Always sleep when passed an extended delay status, using usleep_range()
for precise shorter sleeps. Limit the sleep time to one second even
though there are higher architected values.
Change rtas_busy_delay()'s return type to bool to better reflect its usage,
and add kernel-doc.
rtas_busy_delay_time() is unchanged, even though it "incorrectly" returns 1
for RTAS_BUSY. There are users of that API with open-coded delay loops in
sensitive contexts that will have to be taken on an individual basis.
Brief results for addition and removal of 5GB memory on a small P9 PowerVM
partition follow. Load was generated with stress-ng --cpu N. For add,
elapsed time is greatly reduced without significant change in the number of
RTAS calls or time spent on CPU. For remove, elapsed time is modestly
reduced, with significant reductions in RTAS calls and time spent on CPU.
With no competing workload (- before, + after):
Performance counter stats for 'bash -c echo "memory add count 20" > /sys/kernel/dlpar' (10 runs):
- 1,935 probe:rtas_call # 0.003 M/sec ( +- 0.22% )
- 609.99 msec task-clock # 0.183 CPUs utilized ( +- 0.19% )
+ 1,956 probe:rtas_call # 0.003 M/sec ( +- 0.17% )
+ 618.56 msec task-clock # 0.278 CPUs utilized ( +- 0.11% )
- 3.3322 +- 0.0670 seconds time elapsed ( +- 2.01% )
+ 2.2222 +- 0.0416 seconds time elapsed ( +- 1.87% )
Performance counter stats for 'bash -c echo "memory remove count 20" > /sys/kernel/dlpar' (10 runs):
- 6,224 probe:rtas_call # 0.008 M/sec ( +- 2.57% )
- 750.36 msec task-clock # 0.190 CPUs utilized ( +- 2.01% )
+ 843 probe:rtas_call # 0.003 M/sec ( +- 0.12% )
+ 250.66 msec task-clock # 0.068 CPUs utilized ( +- 0.17% )
- 3.9394 +- 0.0890 seconds time elapsed ( +- 2.26% )
+ 3.678 +- 0.113 seconds time elapsed ( +- 3.07% )
With all CPUs 100% busy (- before, + after):
Performance counter stats for 'bash -c echo "memory add count 20" > /sys/kernel/dlpar' (10 runs):
- 2,979 probe:rtas_call # 0.003 M/sec ( +- 0.12% )
- 1,096.62 msec task-clock # 0.105 CPUs utilized ( +- 0.10% )
+ 2,981 probe:rtas_call # 0.003 M/sec ( +- 0.22% )
+ 1,095.26 msec task-clock # 0.154 CPUs utilized ( +- 0.21% )
- 10.476 +- 0.104 seconds time elapsed ( +- 1.00% )
+ 7.1124 +- 0.0865 seconds time elapsed ( +- 1.22% )
Performance counter stats for 'bash -c echo "memory remove count 20" > /sys/kernel/dlpar' (10 runs):
- 2,702 probe:rtas_call # 0.004 M/sec ( +- 4.00% )
- 722.71 msec task-clock # 0.067 CPUs utilized ( +- 2.41% )
+ 1,246 probe:rtas_call # 0.003 M/sec ( +- 0.25% )
+ 487.73 msec task-clock # 0.049 CPUs utilized ( +- 0.20% )
- 10.829 +- 0.163 seconds time elapsed ( +- 1.51% )
+ 9.9887 +- 0.0866 seconds time elapsed ( +- 0.87% )
Signed-off-by: Nathan Lynch <nathanl@linux.ibm.com>
Signed-off-by: Michael Ellerman <mpe@ellerman.id.au>
Link: https://lore.kernel.org/r/20211117060259.957178-2-nathanl@linux.ibm.com
2021-11-17 00:02:58 -06:00
|
|
|
|
/**
|
|
|
|
|
* rtas_busy_delay() - helper for RTAS busy and extended delay statuses
|
|
|
|
|
*
|
|
|
|
|
* @status: a value returned from rtas_call() or similar APIs which return
|
|
|
|
|
* the status of a RTAS function call.
|
|
|
|
|
*
|
|
|
|
|
* Context: Process context. May sleep or schedule.
|
|
|
|
|
*
|
|
|
|
|
* Return:
|
|
|
|
|
* * true - @status is RTAS_BUSY or an extended delay hint. The
|
|
|
|
|
* caller may assume that the CPU has been yielded if necessary,
|
|
|
|
|
* and that an appropriate delay for @status has elapsed.
|
|
|
|
|
* Generally the caller should reattempt the RTAS call which
|
|
|
|
|
* yielded @status.
|
|
|
|
|
*
|
|
|
|
|
* * false - @status is not @RTAS_BUSY nor an extended delay hint. The
|
|
|
|
|
* caller is responsible for handling @status.
|
|
|
|
|
*/
|
powerpc/rtas: handle extended delays safely in early boot
Some code that runs early in boot calls RTAS functions that can return
-2 or 990x statuses, which mean the caller should retry. An example is
pSeries_cmo_feature_init(), which invokes ibm,get-system-parameter but
treats these benign statuses as errors instead of retrying.
pSeries_cmo_feature_init() and similar code should be made to retry
until they succeed or receive a real error, using the usual pattern:
do {
rc = rtas_call(token, etc...);
} while (rtas_busy_delay(rc));
But rtas_busy_delay() will perform a timed sleep on any 990x
status. This isn't safe so early in boot, before the CPU scheduler and
timer subsystem have initialized.
The -2 RTAS status is much more likely to occur during single-threaded
boot than 990x in practice, at least on PowerVM. This is because -2
usually means that RTAS made progress but exhausted its self-imposed
timeslice, while 990x is associated with concurrent requests from the
OS causing internal contention. Regardless, according to the language
in PAPR, the OS should be prepared to handle either type of status at
any time.
Add a fallback path to rtas_busy_delay() to handle this as safely as
possible, performing a small delay on 990x. Include a counter to
detect retry loops that aren't making progress and bail out. Add __ref
to rtas_busy_delay() since it now conditionally calls an __init
function.
This was found by inspection and I'm not aware of any real
failures. However, the implementation of rtas_busy_delay() before
commit 38f7b7067dae ("powerpc/rtas: rtas_busy_delay() improvements")
was not susceptible to this problem, so let's treat this as a
regression.
Signed-off-by: Nathan Lynch <nathanl@linux.ibm.com>
Fixes: 38f7b7067dae ("powerpc/rtas: rtas_busy_delay() improvements")
Signed-off-by: Michael Ellerman <mpe@ellerman.id.au>
Link: https://lore.kernel.org/r/20230125-b4-powerpc-rtas-queue-v3-1-26929c8cce78@linux.ibm.com
2023-02-10 12:41:49 -06:00
|
|
|
|
bool __ref rtas_busy_delay(int status)
|
2006-06-05 16:31:48 -05:00
|
|
|
|
{
|
|
|
|
|
unsigned int ms;
|
powerpc/rtas: rtas_busy_delay() improvements
Generally RTAS cannot block, and in PAPR it is required to return control
to the OS within a few tens of microseconds. In order to support operations
which may take longer to complete, many RTAS primitives can return
intermediate -2 ("busy") or 990x ("extended delay") values, which indicate
that the OS should reattempt the same call with the same arguments at some
point in the future.
Current versions of PAPR are less than clear about this, but the intended
meanings of these values in more detail are:
RTAS_BUSY (-2): RTAS has suspended a potentially long-running operation in
order to meet its latency obligation and give the OS the opportunity to
perform other work. RTAS can resume making progress as soon as the OS
reattempts the call.
RTAS_EXTENDED_DELAY_{MIN...MAX} (9900-9905): RTAS must wait for an external
event to occur or for internal contention to resolve before it can complete
the requested operation. The value encodes a non-binding hint as to roughly
how long the OS should wait before calling again, but the OS is allowed to
reattempt the call sooner or even immediately.
Linux of course must take its own CPU scheduling obligations into account
when handling these statuses; e.g. a task which receives an RTAS_BUSY
status should check whether to reschedule before it attempts the RTAS call
again to avoid starving other tasks.
rtas_busy_delay() is a helper function that "consumes" a busy or extended
delay status. Common usage:
int rc;
do {
rc = rtas_call(rtas_token("some-function"), ...);
} while (rtas_busy_delay(rc));
/* convert rc to Linux error value, etc */
If rc is a busy or extended delay status, the caller can rely on
rtas_busy_delay() to perform an appropriate sleep or reschedule and return
nonzero. Other statuses are handled normally by the caller.
The current implementation of rtas_busy_delay() both oversleeps and
overuses the CPU:
* It performs msleep() for all 990x and even when no delay is
suggested (-2), but this is understood to actually sleep for two jiffies
minimum in practice (20ms with HZ=100). 9900 (1ms) and 9901 (10ms)
appear to be the most common extended delay statuses, and the
oversleeping measurably lengthens DLPAR operations, which perform
many RTAS calls.
* It does not sleep on 990x unless need_resched() is true, causing code
like the loop above to needlessly retry, wasting CPU time.
Alter the logic to align better with the intended meanings:
* When passed RTAS_BUSY, perform cond_resched() and return without
sleeping. The caller should reattempt immediately
* Always sleep when passed an extended delay status, using usleep_range()
for precise shorter sleeps. Limit the sleep time to one second even
though there are higher architected values.
Change rtas_busy_delay()'s return type to bool to better reflect its usage,
and add kernel-doc.
rtas_busy_delay_time() is unchanged, even though it "incorrectly" returns 1
for RTAS_BUSY. There are users of that API with open-coded delay loops in
sensitive contexts that will have to be taken on an individual basis.
Brief results for addition and removal of 5GB memory on a small P9 PowerVM
partition follow. Load was generated with stress-ng --cpu N. For add,
elapsed time is greatly reduced without significant change in the number of
RTAS calls or time spent on CPU. For remove, elapsed time is modestly
reduced, with significant reductions in RTAS calls and time spent on CPU.
With no competing workload (- before, + after):
Performance counter stats for 'bash -c echo "memory add count 20" > /sys/kernel/dlpar' (10 runs):
- 1,935 probe:rtas_call # 0.003 M/sec ( +- 0.22% )
- 609.99 msec task-clock # 0.183 CPUs utilized ( +- 0.19% )
+ 1,956 probe:rtas_call # 0.003 M/sec ( +- 0.17% )
+ 618.56 msec task-clock # 0.278 CPUs utilized ( +- 0.11% )
- 3.3322 +- 0.0670 seconds time elapsed ( +- 2.01% )
+ 2.2222 +- 0.0416 seconds time elapsed ( +- 1.87% )
Performance counter stats for 'bash -c echo "memory remove count 20" > /sys/kernel/dlpar' (10 runs):
- 6,224 probe:rtas_call # 0.008 M/sec ( +- 2.57% )
- 750.36 msec task-clock # 0.190 CPUs utilized ( +- 2.01% )
+ 843 probe:rtas_call # 0.003 M/sec ( +- 0.12% )
+ 250.66 msec task-clock # 0.068 CPUs utilized ( +- 0.17% )
- 3.9394 +- 0.0890 seconds time elapsed ( +- 2.26% )
+ 3.678 +- 0.113 seconds time elapsed ( +- 3.07% )
With all CPUs 100% busy (- before, + after):
Performance counter stats for 'bash -c echo "memory add count 20" > /sys/kernel/dlpar' (10 runs):
- 2,979 probe:rtas_call # 0.003 M/sec ( +- 0.12% )
- 1,096.62 msec task-clock # 0.105 CPUs utilized ( +- 0.10% )
+ 2,981 probe:rtas_call # 0.003 M/sec ( +- 0.22% )
+ 1,095.26 msec task-clock # 0.154 CPUs utilized ( +- 0.21% )
- 10.476 +- 0.104 seconds time elapsed ( +- 1.00% )
+ 7.1124 +- 0.0865 seconds time elapsed ( +- 1.22% )
Performance counter stats for 'bash -c echo "memory remove count 20" > /sys/kernel/dlpar' (10 runs):
- 2,702 probe:rtas_call # 0.004 M/sec ( +- 4.00% )
- 722.71 msec task-clock # 0.067 CPUs utilized ( +- 2.41% )
+ 1,246 probe:rtas_call # 0.003 M/sec ( +- 0.25% )
+ 487.73 msec task-clock # 0.049 CPUs utilized ( +- 0.20% )
- 10.829 +- 0.163 seconds time elapsed ( +- 1.51% )
+ 9.9887 +- 0.0866 seconds time elapsed ( +- 0.87% )
Signed-off-by: Nathan Lynch <nathanl@linux.ibm.com>
Signed-off-by: Michael Ellerman <mpe@ellerman.id.au>
Link: https://lore.kernel.org/r/20211117060259.957178-2-nathanl@linux.ibm.com
2021-11-17 00:02:58 -06:00
|
|
|
|
bool ret;
|
|
|
|
|
|
powerpc/rtas: handle extended delays safely in early boot
Some code that runs early in boot calls RTAS functions that can return
-2 or 990x statuses, which mean the caller should retry. An example is
pSeries_cmo_feature_init(), which invokes ibm,get-system-parameter but
treats these benign statuses as errors instead of retrying.
pSeries_cmo_feature_init() and similar code should be made to retry
until they succeed or receive a real error, using the usual pattern:
do {
rc = rtas_call(token, etc...);
} while (rtas_busy_delay(rc));
But rtas_busy_delay() will perform a timed sleep on any 990x
status. This isn't safe so early in boot, before the CPU scheduler and
timer subsystem have initialized.
The -2 RTAS status is much more likely to occur during single-threaded
boot than 990x in practice, at least on PowerVM. This is because -2
usually means that RTAS made progress but exhausted its self-imposed
timeslice, while 990x is associated with concurrent requests from the
OS causing internal contention. Regardless, according to the language
in PAPR, the OS should be prepared to handle either type of status at
any time.
Add a fallback path to rtas_busy_delay() to handle this as safely as
possible, performing a small delay on 990x. Include a counter to
detect retry loops that aren't making progress and bail out. Add __ref
to rtas_busy_delay() since it now conditionally calls an __init
function.
This was found by inspection and I'm not aware of any real
failures. However, the implementation of rtas_busy_delay() before
commit 38f7b7067dae ("powerpc/rtas: rtas_busy_delay() improvements")
was not susceptible to this problem, so let's treat this as a
regression.
Signed-off-by: Nathan Lynch <nathanl@linux.ibm.com>
Fixes: 38f7b7067dae ("powerpc/rtas: rtas_busy_delay() improvements")
Signed-off-by: Michael Ellerman <mpe@ellerman.id.au>
Link: https://lore.kernel.org/r/20230125-b4-powerpc-rtas-queue-v3-1-26929c8cce78@linux.ibm.com
2023-02-10 12:41:49 -06:00
|
|
|
|
/*
|
|
|
|
|
* Can't do timed sleeps before timekeeping is up.
|
|
|
|
|
*/
|
|
|
|
|
if (system_state < SYSTEM_SCHEDULING)
|
|
|
|
|
return rtas_busy_delay_early(status);
|
|
|
|
|
|
powerpc/rtas: rtas_busy_delay() improvements
Generally RTAS cannot block, and in PAPR it is required to return control
to the OS within a few tens of microseconds. In order to support operations
which may take longer to complete, many RTAS primitives can return
intermediate -2 ("busy") or 990x ("extended delay") values, which indicate
that the OS should reattempt the same call with the same arguments at some
point in the future.
Current versions of PAPR are less than clear about this, but the intended
meanings of these values in more detail are:
RTAS_BUSY (-2): RTAS has suspended a potentially long-running operation in
order to meet its latency obligation and give the OS the opportunity to
perform other work. RTAS can resume making progress as soon as the OS
reattempts the call.
RTAS_EXTENDED_DELAY_{MIN...MAX} (9900-9905): RTAS must wait for an external
event to occur or for internal contention to resolve before it can complete
the requested operation. The value encodes a non-binding hint as to roughly
how long the OS should wait before calling again, but the OS is allowed to
reattempt the call sooner or even immediately.
Linux of course must take its own CPU scheduling obligations into account
when handling these statuses; e.g. a task which receives an RTAS_BUSY
status should check whether to reschedule before it attempts the RTAS call
again to avoid starving other tasks.
rtas_busy_delay() is a helper function that "consumes" a busy or extended
delay status. Common usage:
int rc;
do {
rc = rtas_call(rtas_token("some-function"), ...);
} while (rtas_busy_delay(rc));
/* convert rc to Linux error value, etc */
If rc is a busy or extended delay status, the caller can rely on
rtas_busy_delay() to perform an appropriate sleep or reschedule and return
nonzero. Other statuses are handled normally by the caller.
The current implementation of rtas_busy_delay() both oversleeps and
overuses the CPU:
* It performs msleep() for all 990x and even when no delay is
suggested (-2), but this is understood to actually sleep for two jiffies
minimum in practice (20ms with HZ=100). 9900 (1ms) and 9901 (10ms)
appear to be the most common extended delay statuses, and the
oversleeping measurably lengthens DLPAR operations, which perform
many RTAS calls.
* It does not sleep on 990x unless need_resched() is true, causing code
like the loop above to needlessly retry, wasting CPU time.
Alter the logic to align better with the intended meanings:
* When passed RTAS_BUSY, perform cond_resched() and return without
sleeping. The caller should reattempt immediately
* Always sleep when passed an extended delay status, using usleep_range()
for precise shorter sleeps. Limit the sleep time to one second even
though there are higher architected values.
Change rtas_busy_delay()'s return type to bool to better reflect its usage,
and add kernel-doc.
rtas_busy_delay_time() is unchanged, even though it "incorrectly" returns 1
for RTAS_BUSY. There are users of that API with open-coded delay loops in
sensitive contexts that will have to be taken on an individual basis.
Brief results for addition and removal of 5GB memory on a small P9 PowerVM
partition follow. Load was generated with stress-ng --cpu N. For add,
elapsed time is greatly reduced without significant change in the number of
RTAS calls or time spent on CPU. For remove, elapsed time is modestly
reduced, with significant reductions in RTAS calls and time spent on CPU.
With no competing workload (- before, + after):
Performance counter stats for 'bash -c echo "memory add count 20" > /sys/kernel/dlpar' (10 runs):
- 1,935 probe:rtas_call # 0.003 M/sec ( +- 0.22% )
- 609.99 msec task-clock # 0.183 CPUs utilized ( +- 0.19% )
+ 1,956 probe:rtas_call # 0.003 M/sec ( +- 0.17% )
+ 618.56 msec task-clock # 0.278 CPUs utilized ( +- 0.11% )
- 3.3322 +- 0.0670 seconds time elapsed ( +- 2.01% )
+ 2.2222 +- 0.0416 seconds time elapsed ( +- 1.87% )
Performance counter stats for 'bash -c echo "memory remove count 20" > /sys/kernel/dlpar' (10 runs):
- 6,224 probe:rtas_call # 0.008 M/sec ( +- 2.57% )
- 750.36 msec task-clock # 0.190 CPUs utilized ( +- 2.01% )
+ 843 probe:rtas_call # 0.003 M/sec ( +- 0.12% )
+ 250.66 msec task-clock # 0.068 CPUs utilized ( +- 0.17% )
- 3.9394 +- 0.0890 seconds time elapsed ( +- 2.26% )
+ 3.678 +- 0.113 seconds time elapsed ( +- 3.07% )
With all CPUs 100% busy (- before, + after):
Performance counter stats for 'bash -c echo "memory add count 20" > /sys/kernel/dlpar' (10 runs):
- 2,979 probe:rtas_call # 0.003 M/sec ( +- 0.12% )
- 1,096.62 msec task-clock # 0.105 CPUs utilized ( +- 0.10% )
+ 2,981 probe:rtas_call # 0.003 M/sec ( +- 0.22% )
+ 1,095.26 msec task-clock # 0.154 CPUs utilized ( +- 0.21% )
- 10.476 +- 0.104 seconds time elapsed ( +- 1.00% )
+ 7.1124 +- 0.0865 seconds time elapsed ( +- 1.22% )
Performance counter stats for 'bash -c echo "memory remove count 20" > /sys/kernel/dlpar' (10 runs):
- 2,702 probe:rtas_call # 0.004 M/sec ( +- 4.00% )
- 722.71 msec task-clock # 0.067 CPUs utilized ( +- 2.41% )
+ 1,246 probe:rtas_call # 0.003 M/sec ( +- 0.25% )
+ 487.73 msec task-clock # 0.049 CPUs utilized ( +- 0.20% )
- 10.829 +- 0.163 seconds time elapsed ( +- 1.51% )
+ 9.9887 +- 0.0866 seconds time elapsed ( +- 0.87% )
Signed-off-by: Nathan Lynch <nathanl@linux.ibm.com>
Signed-off-by: Michael Ellerman <mpe@ellerman.id.au>
Link: https://lore.kernel.org/r/20211117060259.957178-2-nathanl@linux.ibm.com
2021-11-17 00:02:58 -06:00
|
|
|
|
switch (status) {
|
|
|
|
|
case RTAS_EXTENDED_DELAY_MIN...RTAS_EXTENDED_DELAY_MAX:
|
|
|
|
|
ret = true;
|
|
|
|
|
ms = rtas_busy_delay_time(status);
|
|
|
|
|
/*
|
|
|
|
|
* The extended delay hint can be as high as 100 seconds.
|
|
|
|
|
* Surely any function returning such a status is either
|
|
|
|
|
* buggy or isn't going to be significantly slowed by us
|
|
|
|
|
* polling at 1HZ. Clamp the sleep time to one second.
|
|
|
|
|
*/
|
|
|
|
|
ms = clamp(ms, 1U, 1000U);
|
|
|
|
|
/*
|
|
|
|
|
* The delay hint is an order-of-magnitude suggestion, not
|
|
|
|
|
* a minimum. It is fine, possibly even advantageous, for
|
|
|
|
|
* us to pause for less time than hinted. For small values,
|
|
|
|
|
* use usleep_range() to ensure we don't sleep much longer
|
|
|
|
|
* than actually needed.
|
|
|
|
|
*
|
|
|
|
|
* See Documentation/timers/timers-howto.rst for
|
|
|
|
|
* explanation of the threshold used here. In effect we use
|
|
|
|
|
* usleep_range() for 9900 and 9901, msleep() for
|
|
|
|
|
* 9902-9905.
|
|
|
|
|
*/
|
|
|
|
|
if (ms <= 20)
|
|
|
|
|
usleep_range(ms * 100, ms * 1000);
|
|
|
|
|
else
|
|
|
|
|
msleep(ms);
|
|
|
|
|
break;
|
|
|
|
|
case RTAS_BUSY:
|
|
|
|
|
ret = true;
|
|
|
|
|
/*
|
|
|
|
|
* We should call again immediately if there's no other
|
|
|
|
|
* work to do.
|
|
|
|
|
*/
|
|
|
|
|
cond_resched();
|
|
|
|
|
break;
|
|
|
|
|
default:
|
|
|
|
|
ret = false;
|
|
|
|
|
/*
|
|
|
|
|
* Not a busy or extended delay status; the caller should
|
|
|
|
|
* handle @status itself. Ensure we warn on misuses in
|
|
|
|
|
* atomic context regardless.
|
|
|
|
|
*/
|
|
|
|
|
might_sleep();
|
|
|
|
|
break;
|
|
|
|
|
}
|
2005-04-16 15:20:36 -07:00
|
|
|
|
|
powerpc/rtas: rtas_busy_delay() improvements
Generally RTAS cannot block, and in PAPR it is required to return control
to the OS within a few tens of microseconds. In order to support operations
which may take longer to complete, many RTAS primitives can return
intermediate -2 ("busy") or 990x ("extended delay") values, which indicate
that the OS should reattempt the same call with the same arguments at some
point in the future.
Current versions of PAPR are less than clear about this, but the intended
meanings of these values in more detail are:
RTAS_BUSY (-2): RTAS has suspended a potentially long-running operation in
order to meet its latency obligation and give the OS the opportunity to
perform other work. RTAS can resume making progress as soon as the OS
reattempts the call.
RTAS_EXTENDED_DELAY_{MIN...MAX} (9900-9905): RTAS must wait for an external
event to occur or for internal contention to resolve before it can complete
the requested operation. The value encodes a non-binding hint as to roughly
how long the OS should wait before calling again, but the OS is allowed to
reattempt the call sooner or even immediately.
Linux of course must take its own CPU scheduling obligations into account
when handling these statuses; e.g. a task which receives an RTAS_BUSY
status should check whether to reschedule before it attempts the RTAS call
again to avoid starving other tasks.
rtas_busy_delay() is a helper function that "consumes" a busy or extended
delay status. Common usage:
int rc;
do {
rc = rtas_call(rtas_token("some-function"), ...);
} while (rtas_busy_delay(rc));
/* convert rc to Linux error value, etc */
If rc is a busy or extended delay status, the caller can rely on
rtas_busy_delay() to perform an appropriate sleep or reschedule and return
nonzero. Other statuses are handled normally by the caller.
The current implementation of rtas_busy_delay() both oversleeps and
overuses the CPU:
* It performs msleep() for all 990x and even when no delay is
suggested (-2), but this is understood to actually sleep for two jiffies
minimum in practice (20ms with HZ=100). 9900 (1ms) and 9901 (10ms)
appear to be the most common extended delay statuses, and the
oversleeping measurably lengthens DLPAR operations, which perform
many RTAS calls.
* It does not sleep on 990x unless need_resched() is true, causing code
like the loop above to needlessly retry, wasting CPU time.
Alter the logic to align better with the intended meanings:
* When passed RTAS_BUSY, perform cond_resched() and return without
sleeping. The caller should reattempt immediately
* Always sleep when passed an extended delay status, using usleep_range()
for precise shorter sleeps. Limit the sleep time to one second even
though there are higher architected values.
Change rtas_busy_delay()'s return type to bool to better reflect its usage,
and add kernel-doc.
rtas_busy_delay_time() is unchanged, even though it "incorrectly" returns 1
for RTAS_BUSY. There are users of that API with open-coded delay loops in
sensitive contexts that will have to be taken on an individual basis.
Brief results for addition and removal of 5GB memory on a small P9 PowerVM
partition follow. Load was generated with stress-ng --cpu N. For add,
elapsed time is greatly reduced without significant change in the number of
RTAS calls or time spent on CPU. For remove, elapsed time is modestly
reduced, with significant reductions in RTAS calls and time spent on CPU.
With no competing workload (- before, + after):
Performance counter stats for 'bash -c echo "memory add count 20" > /sys/kernel/dlpar' (10 runs):
- 1,935 probe:rtas_call # 0.003 M/sec ( +- 0.22% )
- 609.99 msec task-clock # 0.183 CPUs utilized ( +- 0.19% )
+ 1,956 probe:rtas_call # 0.003 M/sec ( +- 0.17% )
+ 618.56 msec task-clock # 0.278 CPUs utilized ( +- 0.11% )
- 3.3322 +- 0.0670 seconds time elapsed ( +- 2.01% )
+ 2.2222 +- 0.0416 seconds time elapsed ( +- 1.87% )
Performance counter stats for 'bash -c echo "memory remove count 20" > /sys/kernel/dlpar' (10 runs):
- 6,224 probe:rtas_call # 0.008 M/sec ( +- 2.57% )
- 750.36 msec task-clock # 0.190 CPUs utilized ( +- 2.01% )
+ 843 probe:rtas_call # 0.003 M/sec ( +- 0.12% )
+ 250.66 msec task-clock # 0.068 CPUs utilized ( +- 0.17% )
- 3.9394 +- 0.0890 seconds time elapsed ( +- 2.26% )
+ 3.678 +- 0.113 seconds time elapsed ( +- 3.07% )
With all CPUs 100% busy (- before, + after):
Performance counter stats for 'bash -c echo "memory add count 20" > /sys/kernel/dlpar' (10 runs):
- 2,979 probe:rtas_call # 0.003 M/sec ( +- 0.12% )
- 1,096.62 msec task-clock # 0.105 CPUs utilized ( +- 0.10% )
+ 2,981 probe:rtas_call # 0.003 M/sec ( +- 0.22% )
+ 1,095.26 msec task-clock # 0.154 CPUs utilized ( +- 0.21% )
- 10.476 +- 0.104 seconds time elapsed ( +- 1.00% )
+ 7.1124 +- 0.0865 seconds time elapsed ( +- 1.22% )
Performance counter stats for 'bash -c echo "memory remove count 20" > /sys/kernel/dlpar' (10 runs):
- 2,702 probe:rtas_call # 0.004 M/sec ( +- 4.00% )
- 722.71 msec task-clock # 0.067 CPUs utilized ( +- 2.41% )
+ 1,246 probe:rtas_call # 0.003 M/sec ( +- 0.25% )
+ 487.73 msec task-clock # 0.049 CPUs utilized ( +- 0.20% )
- 10.829 +- 0.163 seconds time elapsed ( +- 1.51% )
+ 9.9887 +- 0.0866 seconds time elapsed ( +- 0.87% )
Signed-off-by: Nathan Lynch <nathanl@linux.ibm.com>
Signed-off-by: Michael Ellerman <mpe@ellerman.id.au>
Link: https://lore.kernel.org/r/20211117060259.957178-2-nathanl@linux.ibm.com
2021-11-17 00:02:58 -06:00
|
|
|
|
return ret;
|
2005-04-16 15:20:36 -07:00
|
|
|
|
}
|
2023-01-24 08:04:46 -06:00
|
|
|
|
EXPORT_SYMBOL_GPL(rtas_busy_delay);
|
2005-04-16 15:20:36 -07:00
|
|
|
|
|
2023-08-18 16:59:07 +05:30
|
|
|
|
int rtas_error_rc(int rtas_rc)
|
2005-04-16 15:20:36 -07:00
|
|
|
|
{
|
|
|
|
|
int rc;
|
|
|
|
|
|
|
|
|
|
switch (rtas_rc) {
|
2023-08-18 16:59:07 +05:30
|
|
|
|
case RTAS_HARDWARE_ERROR: /* Hardware Error */
|
|
|
|
|
rc = -EIO;
|
|
|
|
|
break;
|
|
|
|
|
case RTAS_INVALID_PARAMETER: /* Bad indicator/domain/etc */
|
|
|
|
|
rc = -EINVAL;
|
|
|
|
|
break;
|
|
|
|
|
case -9000: /* Isolation error */
|
|
|
|
|
rc = -EFAULT;
|
|
|
|
|
break;
|
|
|
|
|
case -9001: /* Outstanding TCE/PTE */
|
|
|
|
|
rc = -EEXIST;
|
|
|
|
|
break;
|
|
|
|
|
case -9002: /* No usable slot */
|
|
|
|
|
rc = -ENODEV;
|
|
|
|
|
break;
|
|
|
|
|
default:
|
|
|
|
|
pr_err("%s: unexpected error %d\n", __func__, rtas_rc);
|
|
|
|
|
rc = -ERANGE;
|
|
|
|
|
break;
|
2005-04-16 15:20:36 -07:00
|
|
|
|
}
|
|
|
|
|
return rc;
|
|
|
|
|
}
|
2023-08-18 16:59:07 +05:30
|
|
|
|
EXPORT_SYMBOL_GPL(rtas_error_rc);
|
2005-04-16 15:20:36 -07:00
|
|
|
|
|
|
|
|
|
int rtas_get_power_level(int powerdomain, int *level)
|
|
|
|
|
{
|
2023-02-10 12:42:08 -06:00
|
|
|
|
int token = rtas_function_token(RTAS_FN_GET_POWER_LEVEL);
|
2005-04-16 15:20:36 -07:00
|
|
|
|
int rc;
|
|
|
|
|
|
|
|
|
|
if (token == RTAS_UNKNOWN_SERVICE)
|
|
|
|
|
return -ENOENT;
|
|
|
|
|
|
|
|
|
|
while ((rc = rtas_call(token, 1, 2, level, powerdomain)) == RTAS_BUSY)
|
|
|
|
|
udelay(1);
|
|
|
|
|
|
|
|
|
|
if (rc < 0)
|
|
|
|
|
return rtas_error_rc(rc);
|
|
|
|
|
return rc;
|
|
|
|
|
}
|
2023-01-24 08:04:46 -06:00
|
|
|
|
EXPORT_SYMBOL_GPL(rtas_get_power_level);
|
2005-04-16 15:20:36 -07:00
|
|
|
|
|
|
|
|
|
int rtas_set_power_level(int powerdomain, int level, int *setlevel)
|
|
|
|
|
{
|
2023-02-10 12:42:08 -06:00
|
|
|
|
int token = rtas_function_token(RTAS_FN_SET_POWER_LEVEL);
|
2005-04-16 15:20:36 -07:00
|
|
|
|
int rc;
|
|
|
|
|
|
|
|
|
|
if (token == RTAS_UNKNOWN_SERVICE)
|
|
|
|
|
return -ENOENT;
|
|
|
|
|
|
2006-06-05 16:31:48 -05:00
|
|
|
|
do {
|
2005-04-16 15:20:36 -07:00
|
|
|
|
rc = rtas_call(token, 2, 2, setlevel, powerdomain, level);
|
2006-06-05 16:31:48 -05:00
|
|
|
|
} while (rtas_busy_delay(rc));
|
2005-04-16 15:20:36 -07:00
|
|
|
|
|
|
|
|
|
if (rc < 0)
|
|
|
|
|
return rtas_error_rc(rc);
|
|
|
|
|
return rc;
|
|
|
|
|
}
|
2023-01-24 08:04:46 -06:00
|
|
|
|
EXPORT_SYMBOL_GPL(rtas_set_power_level);
|
2005-04-16 15:20:36 -07:00
|
|
|
|
|
|
|
|
|
int rtas_get_sensor(int sensor, int index, int *state)
|
|
|
|
|
{
|
2023-02-10 12:42:08 -06:00
|
|
|
|
int token = rtas_function_token(RTAS_FN_GET_SENSOR_STATE);
|
2005-04-16 15:20:36 -07:00
|
|
|
|
int rc;
|
|
|
|
|
|
|
|
|
|
if (token == RTAS_UNKNOWN_SERVICE)
|
|
|
|
|
return -ENOENT;
|
|
|
|
|
|
2006-06-05 16:31:48 -05:00
|
|
|
|
do {
|
2005-04-16 15:20:36 -07:00
|
|
|
|
rc = rtas_call(token, 2, 2, state, sensor, index);
|
2006-06-05 16:31:48 -05:00
|
|
|
|
} while (rtas_busy_delay(rc));
|
2005-04-16 15:20:36 -07:00
|
|
|
|
|
|
|
|
|
if (rc < 0)
|
|
|
|
|
return rtas_error_rc(rc);
|
|
|
|
|
return rc;
|
|
|
|
|
}
|
2023-01-24 08:04:46 -06:00
|
|
|
|
EXPORT_SYMBOL_GPL(rtas_get_sensor);
|
2005-04-16 15:20:36 -07:00
|
|
|
|
|
2015-07-17 12:46:58 +02:00
|
|
|
|
int rtas_get_sensor_fast(int sensor, int index, int *state)
|
|
|
|
|
{
|
2023-02-10 12:42:08 -06:00
|
|
|
|
int token = rtas_function_token(RTAS_FN_GET_SENSOR_STATE);
|
2015-07-17 12:46:58 +02:00
|
|
|
|
int rc;
|
|
|
|
|
|
|
|
|
|
if (token == RTAS_UNKNOWN_SERVICE)
|
|
|
|
|
return -ENOENT;
|
|
|
|
|
|
|
|
|
|
rc = rtas_call(token, 2, 2, state, sensor, index);
|
|
|
|
|
WARN_ON(rc == RTAS_BUSY || (rc >= RTAS_EXTENDED_DELAY_MIN &&
|
|
|
|
|
rc <= RTAS_EXTENDED_DELAY_MAX));
|
|
|
|
|
|
|
|
|
|
if (rc < 0)
|
|
|
|
|
return rtas_error_rc(rc);
|
|
|
|
|
return rc;
|
|
|
|
|
}
|
|
|
|
|
|
2008-12-11 09:14:25 +00:00
|
|
|
|
bool rtas_indicator_present(int token, int *maxindex)
|
|
|
|
|
{
|
|
|
|
|
int proplen, count, i;
|
|
|
|
|
const struct indicator_elem {
|
2013-08-07 02:01:29 +10:00
|
|
|
|
__be32 token;
|
|
|
|
|
__be32 maxindex;
|
2008-12-11 09:14:25 +00:00
|
|
|
|
} *indicators;
|
|
|
|
|
|
|
|
|
|
indicators = of_get_property(rtas.dev, "rtas-indicators", &proplen);
|
|
|
|
|
if (!indicators)
|
|
|
|
|
return false;
|
|
|
|
|
|
|
|
|
|
count = proplen / sizeof(struct indicator_elem);
|
|
|
|
|
|
|
|
|
|
for (i = 0; i < count; i++) {
|
2013-08-07 02:01:29 +10:00
|
|
|
|
if (__be32_to_cpu(indicators[i].token) != token)
|
2008-12-11 09:14:25 +00:00
|
|
|
|
continue;
|
|
|
|
|
if (maxindex)
|
2013-08-07 02:01:29 +10:00
|
|
|
|
*maxindex = __be32_to_cpu(indicators[i].maxindex);
|
2008-12-11 09:14:25 +00:00
|
|
|
|
return true;
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
return false;
|
|
|
|
|
}
|
|
|
|
|
|
2005-04-16 15:20:36 -07:00
|
|
|
|
int rtas_set_indicator(int indicator, int index, int new_value)
|
|
|
|
|
{
|
2023-02-10 12:42:08 -06:00
|
|
|
|
int token = rtas_function_token(RTAS_FN_SET_INDICATOR);
|
2005-04-16 15:20:36 -07:00
|
|
|
|
int rc;
|
|
|
|
|
|
|
|
|
|
if (token == RTAS_UNKNOWN_SERVICE)
|
|
|
|
|
return -ENOENT;
|
|
|
|
|
|
2006-06-05 16:31:48 -05:00
|
|
|
|
do {
|
2005-04-16 15:20:36 -07:00
|
|
|
|
rc = rtas_call(token, 3, 1, NULL, indicator, index, new_value);
|
2006-06-05 16:31:48 -05:00
|
|
|
|
} while (rtas_busy_delay(rc));
|
2005-04-16 15:20:36 -07:00
|
|
|
|
|
|
|
|
|
if (rc < 0)
|
|
|
|
|
return rtas_error_rc(rc);
|
|
|
|
|
return rc;
|
|
|
|
|
}
|
2023-01-24 08:04:46 -06:00
|
|
|
|
EXPORT_SYMBOL_GPL(rtas_set_indicator);
|
2005-04-16 15:20:36 -07:00
|
|
|
|
|
2006-07-27 14:29:00 -07:00
|
|
|
|
/*
|
|
|
|
|
* Ignoring RTAS extended delay
|
|
|
|
|
*/
|
|
|
|
|
int rtas_set_indicator_fast(int indicator, int index, int new_value)
|
|
|
|
|
{
|
2023-02-10 12:42:08 -06:00
|
|
|
|
int token = rtas_function_token(RTAS_FN_SET_INDICATOR);
|
2006-07-27 14:29:00 -07:00
|
|
|
|
int rc;
|
|
|
|
|
|
|
|
|
|
if (token == RTAS_UNKNOWN_SERVICE)
|
|
|
|
|
return -ENOENT;
|
|
|
|
|
|
|
|
|
|
rc = rtas_call(token, 3, 1, NULL, indicator, index, new_value);
|
|
|
|
|
|
2015-07-22 18:56:47 +02:00
|
|
|
|
WARN_ON(rc == RTAS_BUSY || (rc >= RTAS_EXTENDED_DELAY_MIN &&
|
|
|
|
|
rc <= RTAS_EXTENDED_DELAY_MAX));
|
2006-07-27 14:29:00 -07:00
|
|
|
|
|
|
|
|
|
if (rc < 0)
|
|
|
|
|
return rtas_error_rc(rc);
|
|
|
|
|
|
|
|
|
|
return rc;
|
|
|
|
|
}
|
|
|
|
|
|
2020-12-07 15:51:36 -06:00
|
|
|
|
/**
|
|
|
|
|
* rtas_ibm_suspend_me() - Call ibm,suspend-me to suspend the LPAR.
|
|
|
|
|
*
|
|
|
|
|
* @fw_status: RTAS call status will be placed here if not NULL.
|
|
|
|
|
*
|
|
|
|
|
* rtas_ibm_suspend_me() should be called only on a CPU which has
|
|
|
|
|
* received H_CONTINUE from the H_JOIN hcall. All other active CPUs
|
|
|
|
|
* should be waiting to return from H_JOIN.
|
|
|
|
|
*
|
|
|
|
|
* rtas_ibm_suspend_me() may suspend execution of the OS
|
|
|
|
|
* indefinitely. Callers should take appropriate measures upon return, such as
|
|
|
|
|
* resetting watchdog facilities.
|
|
|
|
|
*
|
|
|
|
|
* Callers may choose to retry this call if @fw_status is
|
|
|
|
|
* %RTAS_THREADS_ACTIVE.
|
|
|
|
|
*
|
|
|
|
|
* Return:
|
|
|
|
|
* 0 - The partition has resumed from suspend, possibly after
|
|
|
|
|
* migration to a different host.
|
|
|
|
|
* -ECANCELED - The operation was aborted.
|
|
|
|
|
* -EAGAIN - There were other CPUs not in H_JOIN at the time of the call.
|
|
|
|
|
* -EBUSY - Some other condition prevented the suspend from succeeding.
|
|
|
|
|
* -EIO - Hardware/platform error.
|
|
|
|
|
*/
|
|
|
|
|
int rtas_ibm_suspend_me(int *fw_status)
|
|
|
|
|
{
|
2023-02-10 12:42:08 -06:00
|
|
|
|
int token = rtas_function_token(RTAS_FN_IBM_SUSPEND_ME);
|
2020-12-07 15:51:36 -06:00
|
|
|
|
int fwrc;
|
|
|
|
|
int ret;
|
|
|
|
|
|
2023-02-10 12:42:08 -06:00
|
|
|
|
fwrc = rtas_call(token, 0, 1, NULL);
|
2020-12-07 15:51:36 -06:00
|
|
|
|
|
|
|
|
|
switch (fwrc) {
|
|
|
|
|
case 0:
|
|
|
|
|
ret = 0;
|
|
|
|
|
break;
|
|
|
|
|
case RTAS_SUSPEND_ABORTED:
|
|
|
|
|
ret = -ECANCELED;
|
|
|
|
|
break;
|
|
|
|
|
case RTAS_THREADS_ACTIVE:
|
|
|
|
|
ret = -EAGAIN;
|
|
|
|
|
break;
|
|
|
|
|
case RTAS_NOT_SUSPENDABLE:
|
|
|
|
|
case RTAS_OUTSTANDING_COPROC:
|
|
|
|
|
ret = -EBUSY;
|
|
|
|
|
break;
|
|
|
|
|
case -1:
|
|
|
|
|
default:
|
|
|
|
|
ret = -EIO;
|
|
|
|
|
break;
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
if (fw_status)
|
|
|
|
|
*fw_status = fwrc;
|
|
|
|
|
|
|
|
|
|
return ret;
|
|
|
|
|
}
|
|
|
|
|
|
2016-07-12 10:54:52 +10:00
|
|
|
|
void __noreturn rtas_restart(char *cmd)
|
2005-04-16 15:20:36 -07:00
|
|
|
|
{
|
2005-11-03 14:41:19 +11:00
|
|
|
|
if (rtas_flash_term_hook)
|
|
|
|
|
rtas_flash_term_hook(SYS_RESTART);
|
2022-11-18 09:07:46 -06:00
|
|
|
|
pr_emerg("system-reboot returned %d\n",
|
2023-02-10 12:42:08 -06:00
|
|
|
|
rtas_call(rtas_function_token(RTAS_FN_SYSTEM_REBOOT), 0, 1, NULL));
|
2005-04-16 15:20:36 -07:00
|
|
|
|
for (;;);
|
|
|
|
|
}
|
|
|
|
|
|
2005-10-26 17:05:24 +10:00
|
|
|
|
void rtas_power_off(void)
|
2005-04-16 15:20:36 -07:00
|
|
|
|
{
|
2005-11-03 14:41:19 +11:00
|
|
|
|
if (rtas_flash_term_hook)
|
|
|
|
|
rtas_flash_term_hook(SYS_POWER_OFF);
|
2005-04-16 15:20:36 -07:00
|
|
|
|
/* allow power on only with power button press */
|
2022-11-18 09:07:46 -06:00
|
|
|
|
pr_emerg("power-off returned %d\n",
|
2023-02-10 12:42:08 -06:00
|
|
|
|
rtas_call(rtas_function_token(RTAS_FN_POWER_OFF), 2, 1, NULL, -1, -1));
|
2005-04-16 15:20:36 -07:00
|
|
|
|
for (;;);
|
|
|
|
|
}
|
|
|
|
|
|
2016-07-12 10:54:52 +10:00
|
|
|
|
void __noreturn rtas_halt(void)
|
2005-04-16 15:20:36 -07:00
|
|
|
|
{
|
2005-11-03 14:41:19 +11:00
|
|
|
|
if (rtas_flash_term_hook)
|
|
|
|
|
rtas_flash_term_hook(SYS_HALT);
|
|
|
|
|
/* allow power on only with power button press */
|
2022-11-18 09:07:46 -06:00
|
|
|
|
pr_emerg("power-off returned %d\n",
|
2023-02-10 12:42:08 -06:00
|
|
|
|
rtas_call(rtas_function_token(RTAS_FN_POWER_OFF), 2, 1, NULL, -1, -1));
|
2005-11-03 14:41:19 +11:00
|
|
|
|
for (;;);
|
2005-04-16 15:20:36 -07:00
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
/* Must be in the RMO region, so we place it here */
|
|
|
|
|
static char rtas_os_term_buf[2048];
|
2023-02-10 12:42:08 -06:00
|
|
|
|
static bool ibm_extended_os_term;
|
2005-04-16 15:20:36 -07:00
|
|
|
|
|
2007-12-03 09:30:04 +11:00
|
|
|
|
void rtas_os_term(char *str)
|
2007-11-20 12:28:15 +11:00
|
|
|
|
{
|
2023-02-10 12:42:08 -06:00
|
|
|
|
s32 token = rtas_function_token(RTAS_FN_IBM_OS_TERM);
|
2023-06-09 12:44:04 +05:30
|
|
|
|
static struct rtas_args args;
|
2007-11-20 12:28:15 +11:00
|
|
|
|
int status;
|
2006-08-21 18:11:32 +02:00
|
|
|
|
|
powerpc/pseries: Call ibm,os-term if the ibm,extended-os-term is present
We have had issues in the past with ibm,os-term initiating shutdown of a
partition. This is confusing to the user, especially if panic_timeout is
non zero.
The temporary fix was to avoid calling ibm,os-term if a panic_timeout was set
and since we set it on every boot we basically never call ibm,os-term.
An extended version of ibm,os-term has since been implemented which gives us
the behaviour we want:
"When the platform supports extended ibm,os-term behavior, the return to the
RTAS will always occur unless there is a kernel assisted dump active as
initiated by an ibm,configure-kernel-dump call."
This patch checks for the ibm,extended-os-term property and calls ibm,os-term
if it exists.
Signed-off-by: Anton Blanchard <anton@samba.org>
Signed-off-by: Benjamin Herrenschmidt <benh@kernel.crashing.org>
2010-02-18 12:11:51 +00:00
|
|
|
|
/*
|
|
|
|
|
* Firmware with the ibm,extended-os-term property is guaranteed
|
|
|
|
|
* to always return from an ibm,os-term call. Earlier versions without
|
|
|
|
|
* this property may terminate the partition which we want to avoid
|
|
|
|
|
* since it interferes with panic_timeout.
|
|
|
|
|
*/
|
2023-02-10 12:42:08 -06:00
|
|
|
|
|
|
|
|
|
if (token == RTAS_UNKNOWN_SERVICE || !ibm_extended_os_term)
|
2005-04-16 15:20:36 -07:00
|
|
|
|
return;
|
|
|
|
|
|
2007-12-03 09:30:04 +11:00
|
|
|
|
snprintf(rtas_os_term_buf, 2048, "OS panic: %s", str);
|
|
|
|
|
|
2022-11-18 09:07:42 -06:00
|
|
|
|
/*
|
|
|
|
|
* Keep calling as long as RTAS returns a "try again" status,
|
|
|
|
|
* but don't use rtas_busy_delay(), which potentially
|
|
|
|
|
* schedules.
|
|
|
|
|
*/
|
2005-04-16 15:20:36 -07:00
|
|
|
|
do {
|
2023-06-09 12:44:04 +05:30
|
|
|
|
rtas_call_unlocked(&args, token, 1, 1, NULL, __pa(rtas_os_term_buf));
|
|
|
|
|
status = be32_to_cpu(args.rets[0]);
|
2022-11-18 09:07:42 -06:00
|
|
|
|
} while (rtas_busy_delay_time(status));
|
2005-04-16 15:20:36 -07:00
|
|
|
|
|
2006-06-05 16:31:48 -05:00
|
|
|
|
if (status != 0)
|
2022-11-18 09:07:46 -06:00
|
|
|
|
pr_emerg("ibm,os-term call failed %d\n", status);
|
2005-04-16 15:20:36 -07:00
|
|
|
|
}
|
|
|
|
|
|
2020-12-07 15:51:37 -06:00
|
|
|
|
/**
|
|
|
|
|
* rtas_activate_firmware() - Activate a new version of firmware.
|
|
|
|
|
*
|
2021-11-16 15:58:06 -06:00
|
|
|
|
* Context: This function may sleep.
|
|
|
|
|
*
|
2020-12-07 15:51:37 -06:00
|
|
|
|
* Activate a new version of partition firmware. The OS must call this
|
|
|
|
|
* after resuming from a partition hibernation or migration in order
|
|
|
|
|
* to maintain the ability to perform live firmware updates. It's not
|
|
|
|
|
* catastrophic for this method to be absent or to fail; just log the
|
|
|
|
|
* condition in that case.
|
|
|
|
|
*/
|
|
|
|
|
void rtas_activate_firmware(void)
|
|
|
|
|
{
|
2023-02-10 12:42:08 -06:00
|
|
|
|
int token = rtas_function_token(RTAS_FN_IBM_ACTIVATE_FIRMWARE);
|
2020-12-07 15:51:37 -06:00
|
|
|
|
int fwrc;
|
|
|
|
|
|
|
|
|
|
if (token == RTAS_UNKNOWN_SERVICE) {
|
|
|
|
|
pr_notice("ibm,activate-firmware method unavailable\n");
|
|
|
|
|
return;
|
|
|
|
|
}
|
|
|
|
|
|
2023-12-12 11:01:54 -06:00
|
|
|
|
mutex_lock(&rtas_ibm_activate_firmware_lock);
|
|
|
|
|
|
2020-12-07 15:51:37 -06:00
|
|
|
|
do {
|
|
|
|
|
fwrc = rtas_call(token, 0, 1, NULL);
|
|
|
|
|
} while (rtas_busy_delay(fwrc));
|
|
|
|
|
|
2023-12-12 11:01:54 -06:00
|
|
|
|
mutex_unlock(&rtas_ibm_activate_firmware_lock);
|
|
|
|
|
|
2020-12-07 15:51:37 -06:00
|
|
|
|
if (fwrc)
|
|
|
|
|
pr_err("ibm,activate-firmware failed (%i)\n", fwrc);
|
|
|
|
|
}
|
|
|
|
|
|
2012-03-21 15:47:07 +00:00
|
|
|
|
/**
|
2021-11-16 15:58:06 -06:00
|
|
|
|
* get_pseries_errorlog() - Find a specific pseries error log in an RTAS
|
|
|
|
|
* extended event log.
|
2012-03-21 15:47:07 +00:00
|
|
|
|
* @log: RTAS error/event log
|
|
|
|
|
* @section_id: two character section identifier
|
|
|
|
|
*
|
2021-11-16 15:58:06 -06:00
|
|
|
|
* Return: A pointer to the specified errorlog or NULL if not found.
|
2012-03-21 15:47:07 +00:00
|
|
|
|
*/
|
2022-05-19 17:45:21 +10:00
|
|
|
|
noinstr struct pseries_errorlog *get_pseries_errorlog(struct rtas_error_log *log,
|
|
|
|
|
uint16_t section_id)
|
2012-03-21 15:47:07 +00:00
|
|
|
|
{
|
|
|
|
|
struct rtas_ext_event_log_v6 *ext_log =
|
|
|
|
|
(struct rtas_ext_event_log_v6 *)log->buffer;
|
|
|
|
|
struct pseries_errorlog *sect;
|
|
|
|
|
unsigned char *p, *log_end;
|
2014-04-04 09:35:13 +02:00
|
|
|
|
uint32_t ext_log_length = rtas_error_extended_log_length(log);
|
|
|
|
|
uint8_t log_format = rtas_ext_event_log_format(ext_log);
|
|
|
|
|
uint32_t company_id = rtas_ext_event_company_id(ext_log);
|
2012-03-21 15:47:07 +00:00
|
|
|
|
|
|
|
|
|
/* Check that we understand the format */
|
2014-04-04 09:35:13 +02:00
|
|
|
|
if (ext_log_length < sizeof(struct rtas_ext_event_log_v6) ||
|
|
|
|
|
log_format != RTAS_V6EXT_LOG_FORMAT_EVENT_LOG ||
|
|
|
|
|
company_id != RTAS_V6EXT_COMPANY_ID_IBM)
|
2012-03-21 15:47:07 +00:00
|
|
|
|
return NULL;
|
|
|
|
|
|
2014-04-04 09:35:13 +02:00
|
|
|
|
log_end = log->buffer + ext_log_length;
|
2012-03-21 15:47:07 +00:00
|
|
|
|
p = ext_log->vendor_log;
|
|
|
|
|
|
|
|
|
|
while (p < log_end) {
|
|
|
|
|
sect = (struct pseries_errorlog *)p;
|
2014-04-04 09:35:13 +02:00
|
|
|
|
if (pseries_errorlog_id(sect) == section_id)
|
2012-03-21 15:47:07 +00:00
|
|
|
|
return sect;
|
2014-04-04 09:35:13 +02:00
|
|
|
|
p += pseries_errorlog_length(sect);
|
2012-03-21 15:47:07 +00:00
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
return NULL;
|
|
|
|
|
}
|
|
|
|
|
|
powerpc/rtas: Restrict RTAS requests from userspace
A number of userspace utilities depend on making calls to RTAS to retrieve
information and update various things.
The existing API through which we expose RTAS to userspace exposes more
RTAS functionality than we actually need, through the sys_rtas syscall,
which allows root (or anyone with CAP_SYS_ADMIN) to make any RTAS call they
want with arbitrary arguments.
Many RTAS calls take the address of a buffer as an argument, and it's up to
the caller to specify the physical address of the buffer as an argument. We
allocate a buffer (the "RMO buffer") in the Real Memory Area that RTAS can
access, and then expose the physical address and size of this buffer in
/proc/powerpc/rtas/rmo_buffer. Userspace is expected to read this address,
poke at the buffer using /dev/mem, and pass an address in the RMO buffer to
the RTAS call.
However, there's nothing stopping the caller from specifying whatever
address they want in the RTAS call, and it's easy to construct a series of
RTAS calls that can overwrite arbitrary bytes (even without /dev/mem
access).
Additionally, there are some RTAS calls that do potentially dangerous
things and for which there are no legitimate userspace use cases.
In the past, this would not have been a particularly big deal as it was
assumed that root could modify all system state freely, but with Secure
Boot and lockdown we need to care about this.
We can't fundamentally change the ABI at this point, however we can address
this by implementing a filter that checks RTAS calls against a list
of permitted calls and forces the caller to use addresses within the RMO
buffer.
The list is based off the list of calls that are used by the librtas
userspace library, and has been tested with a number of existing userspace
RTAS utilities. For compatibility with any applications we are not aware of
that require other calls, the filter can be turned off at build time.
Cc: stable@vger.kernel.org
Reported-by: Daniel Axtens <dja@axtens.net>
Signed-off-by: Andrew Donnellan <ajd@linux.ibm.com>
Signed-off-by: Michael Ellerman <mpe@ellerman.id.au>
Link: https://lore.kernel.org/r/20200820044512.7543-1-ajd@linux.ibm.com
2020-08-20 14:45:12 +10:00
|
|
|
|
/*
|
|
|
|
|
* The sys_rtas syscall, as originally designed, allows root to pass
|
|
|
|
|
* arbitrary physical addresses to RTAS calls. A number of RTAS calls
|
|
|
|
|
* can be abused to write to arbitrary memory and do other things that
|
|
|
|
|
* are potentially harmful to system integrity, and thus should only
|
|
|
|
|
* be used inside the kernel and not exposed to userspace.
|
|
|
|
|
*
|
|
|
|
|
* All known legitimate users of the sys_rtas syscall will only ever
|
|
|
|
|
* pass addresses that fall within the RMO buffer, and use a known
|
|
|
|
|
* subset of RTAS calls.
|
|
|
|
|
*
|
|
|
|
|
* Accordingly, we filter RTAS requests to check that the call is
|
|
|
|
|
* permitted, and that provided pointers fall within the RMO buffer.
|
powerpc/rtas: improve function information lookups
The core RTAS support code and its clients perform two types of lookup
for RTAS firmware function information.
First, mapping a known function name to a token. The typical use case
invokes rtas_token() to retrieve the token value to pass to
rtas_call(). rtas_token() relies on of_get_property(), which performs
a linear search of the /rtas node's property list under a lock with
IRQs disabled.
Second, and less common: given a token value, looking up some
information about the function. The primary example is the sys_rtas
filter path, which linearly scans a small table to match the token to
a rtas_filter struct. Another use case to come is RTAS entry/exit
tracepoints, which will require efficient lookup of function names
from token values. Currently there is no general API for this.
We need something much like the existing rtas_filters table, but more
general and organized to facilitate efficient lookups.
Introduce:
* A new rtas_function type, aggregating function name, token,
and filter. Other function characteristics could be added in the
future.
* An array of rtas_function, where each element corresponds to a known
RTAS function. All information in the table is static save the token
values, which are derived from the device tree at boot. The array is
sorted by function name to allow binary search.
* A named constant for each known RTAS function, used to index the
function array. These also will be used in a client-facing API to be
added later.
* An xarray that maps valid tokens to rtas_function objects.
Fold the existing rtas_filter table into the new rtas_function array,
with the appropriate adjustments to block_rtas_call(). Remove
now-redundant fields from struct rtas_filter. Preserve the function of
the CONFIG_CPU_BIG_ENDIAN guard in the current filter table by
introducing a per-function flag that is set for the function entries
related to pseries LPAR migration. These have never had working users
via sys_rtas on ppc64le; see commit de0f7349a0dd ("powerpc/rtas:
prevent suspend-related sys_rtas use on LE").
Convert rtas_token() to use a lockless binary search on the function
table. Fall back to the old behavior for lookups against names that
are not known to be RTAS functions, but issue a warning. rtas_token()
is for function names; it is not a general facility for accessing
arbitrary properties of the /rtas node. All known misuses of
rtas_token() have been converted to more appropriate of_ APIs in
preceding changes.
Signed-off-by: Nathan Lynch <nathanl@linux.ibm.com>
Signed-off-by: Michael Ellerman <mpe@ellerman.id.au>
Link: https://lore.kernel.org/r/20230125-b4-powerpc-rtas-queue-v3-8-26929c8cce78@linux.ibm.com
2023-02-10 12:41:56 -06:00
|
|
|
|
* If a function is allowed to be invoked via the syscall, then its
|
|
|
|
|
* entry in the rtas_functions table points to a rtas_filter that
|
|
|
|
|
* describes its constraints, with the indexes of the parameters which
|
|
|
|
|
* are expected to contain addresses and sizes of buffers allocated
|
|
|
|
|
* inside the RMO buffer.
|
powerpc/rtas: Restrict RTAS requests from userspace
A number of userspace utilities depend on making calls to RTAS to retrieve
information and update various things.
The existing API through which we expose RTAS to userspace exposes more
RTAS functionality than we actually need, through the sys_rtas syscall,
which allows root (or anyone with CAP_SYS_ADMIN) to make any RTAS call they
want with arbitrary arguments.
Many RTAS calls take the address of a buffer as an argument, and it's up to
the caller to specify the physical address of the buffer as an argument. We
allocate a buffer (the "RMO buffer") in the Real Memory Area that RTAS can
access, and then expose the physical address and size of this buffer in
/proc/powerpc/rtas/rmo_buffer. Userspace is expected to read this address,
poke at the buffer using /dev/mem, and pass an address in the RMO buffer to
the RTAS call.
However, there's nothing stopping the caller from specifying whatever
address they want in the RTAS call, and it's easy to construct a series of
RTAS calls that can overwrite arbitrary bytes (even without /dev/mem
access).
Additionally, there are some RTAS calls that do potentially dangerous
things and for which there are no legitimate userspace use cases.
In the past, this would not have been a particularly big deal as it was
assumed that root could modify all system state freely, but with Secure
Boot and lockdown we need to care about this.
We can't fundamentally change the ABI at this point, however we can address
this by implementing a filter that checks RTAS calls against a list
of permitted calls and forces the caller to use addresses within the RMO
buffer.
The list is based off the list of calls that are used by the librtas
userspace library, and has been tested with a number of existing userspace
RTAS utilities. For compatibility with any applications we are not aware of
that require other calls, the filter can be turned off at build time.
Cc: stable@vger.kernel.org
Reported-by: Daniel Axtens <dja@axtens.net>
Signed-off-by: Andrew Donnellan <ajd@linux.ibm.com>
Signed-off-by: Michael Ellerman <mpe@ellerman.id.au>
Link: https://lore.kernel.org/r/20200820044512.7543-1-ajd@linux.ibm.com
2020-08-20 14:45:12 +10:00
|
|
|
|
*/
|
|
|
|
|
|
|
|
|
|
static bool in_rmo_buf(u32 base, u32 end)
|
|
|
|
|
{
|
|
|
|
|
return base >= rtas_rmo_buf &&
|
2021-04-08 09:06:30 -05:00
|
|
|
|
base < (rtas_rmo_buf + RTAS_USER_REGION_SIZE) &&
|
powerpc/rtas: Restrict RTAS requests from userspace
A number of userspace utilities depend on making calls to RTAS to retrieve
information and update various things.
The existing API through which we expose RTAS to userspace exposes more
RTAS functionality than we actually need, through the sys_rtas syscall,
which allows root (or anyone with CAP_SYS_ADMIN) to make any RTAS call they
want with arbitrary arguments.
Many RTAS calls take the address of a buffer as an argument, and it's up to
the caller to specify the physical address of the buffer as an argument. We
allocate a buffer (the "RMO buffer") in the Real Memory Area that RTAS can
access, and then expose the physical address and size of this buffer in
/proc/powerpc/rtas/rmo_buffer. Userspace is expected to read this address,
poke at the buffer using /dev/mem, and pass an address in the RMO buffer to
the RTAS call.
However, there's nothing stopping the caller from specifying whatever
address they want in the RTAS call, and it's easy to construct a series of
RTAS calls that can overwrite arbitrary bytes (even without /dev/mem
access).
Additionally, there are some RTAS calls that do potentially dangerous
things and for which there are no legitimate userspace use cases.
In the past, this would not have been a particularly big deal as it was
assumed that root could modify all system state freely, but with Secure
Boot and lockdown we need to care about this.
We can't fundamentally change the ABI at this point, however we can address
this by implementing a filter that checks RTAS calls against a list
of permitted calls and forces the caller to use addresses within the RMO
buffer.
The list is based off the list of calls that are used by the librtas
userspace library, and has been tested with a number of existing userspace
RTAS utilities. For compatibility with any applications we are not aware of
that require other calls, the filter can be turned off at build time.
Cc: stable@vger.kernel.org
Reported-by: Daniel Axtens <dja@axtens.net>
Signed-off-by: Andrew Donnellan <ajd@linux.ibm.com>
Signed-off-by: Michael Ellerman <mpe@ellerman.id.au>
Link: https://lore.kernel.org/r/20200820044512.7543-1-ajd@linux.ibm.com
2020-08-20 14:45:12 +10:00
|
|
|
|
base <= end &&
|
|
|
|
|
end >= rtas_rmo_buf &&
|
2021-04-08 09:06:30 -05:00
|
|
|
|
end < (rtas_rmo_buf + RTAS_USER_REGION_SIZE);
|
powerpc/rtas: Restrict RTAS requests from userspace
A number of userspace utilities depend on making calls to RTAS to retrieve
information and update various things.
The existing API through which we expose RTAS to userspace exposes more
RTAS functionality than we actually need, through the sys_rtas syscall,
which allows root (or anyone with CAP_SYS_ADMIN) to make any RTAS call they
want with arbitrary arguments.
Many RTAS calls take the address of a buffer as an argument, and it's up to
the caller to specify the physical address of the buffer as an argument. We
allocate a buffer (the "RMO buffer") in the Real Memory Area that RTAS can
access, and then expose the physical address and size of this buffer in
/proc/powerpc/rtas/rmo_buffer. Userspace is expected to read this address,
poke at the buffer using /dev/mem, and pass an address in the RMO buffer to
the RTAS call.
However, there's nothing stopping the caller from specifying whatever
address they want in the RTAS call, and it's easy to construct a series of
RTAS calls that can overwrite arbitrary bytes (even without /dev/mem
access).
Additionally, there are some RTAS calls that do potentially dangerous
things and for which there are no legitimate userspace use cases.
In the past, this would not have been a particularly big deal as it was
assumed that root could modify all system state freely, but with Secure
Boot and lockdown we need to care about this.
We can't fundamentally change the ABI at this point, however we can address
this by implementing a filter that checks RTAS calls against a list
of permitted calls and forces the caller to use addresses within the RMO
buffer.
The list is based off the list of calls that are used by the librtas
userspace library, and has been tested with a number of existing userspace
RTAS utilities. For compatibility with any applications we are not aware of
that require other calls, the filter can be turned off at build time.
Cc: stable@vger.kernel.org
Reported-by: Daniel Axtens <dja@axtens.net>
Signed-off-by: Andrew Donnellan <ajd@linux.ibm.com>
Signed-off-by: Michael Ellerman <mpe@ellerman.id.au>
Link: https://lore.kernel.org/r/20200820044512.7543-1-ajd@linux.ibm.com
2020-08-20 14:45:12 +10:00
|
|
|
|
}
|
|
|
|
|
|
2023-12-12 11:01:52 -06:00
|
|
|
|
static bool block_rtas_call(const struct rtas_function *func, int nargs,
|
powerpc/rtas: Restrict RTAS requests from userspace
A number of userspace utilities depend on making calls to RTAS to retrieve
information and update various things.
The existing API through which we expose RTAS to userspace exposes more
RTAS functionality than we actually need, through the sys_rtas syscall,
which allows root (or anyone with CAP_SYS_ADMIN) to make any RTAS call they
want with arbitrary arguments.
Many RTAS calls take the address of a buffer as an argument, and it's up to
the caller to specify the physical address of the buffer as an argument. We
allocate a buffer (the "RMO buffer") in the Real Memory Area that RTAS can
access, and then expose the physical address and size of this buffer in
/proc/powerpc/rtas/rmo_buffer. Userspace is expected to read this address,
poke at the buffer using /dev/mem, and pass an address in the RMO buffer to
the RTAS call.
However, there's nothing stopping the caller from specifying whatever
address they want in the RTAS call, and it's easy to construct a series of
RTAS calls that can overwrite arbitrary bytes (even without /dev/mem
access).
Additionally, there are some RTAS calls that do potentially dangerous
things and for which there are no legitimate userspace use cases.
In the past, this would not have been a particularly big deal as it was
assumed that root could modify all system state freely, but with Secure
Boot and lockdown we need to care about this.
We can't fundamentally change the ABI at this point, however we can address
this by implementing a filter that checks RTAS calls against a list
of permitted calls and forces the caller to use addresses within the RMO
buffer.
The list is based off the list of calls that are used by the librtas
userspace library, and has been tested with a number of existing userspace
RTAS utilities. For compatibility with any applications we are not aware of
that require other calls, the filter can be turned off at build time.
Cc: stable@vger.kernel.org
Reported-by: Daniel Axtens <dja@axtens.net>
Signed-off-by: Andrew Donnellan <ajd@linux.ibm.com>
Signed-off-by: Michael Ellerman <mpe@ellerman.id.au>
Link: https://lore.kernel.org/r/20200820044512.7543-1-ajd@linux.ibm.com
2020-08-20 14:45:12 +10:00
|
|
|
|
struct rtas_args *args)
|
|
|
|
|
{
|
powerpc/rtas: improve function information lookups
The core RTAS support code and its clients perform two types of lookup
for RTAS firmware function information.
First, mapping a known function name to a token. The typical use case
invokes rtas_token() to retrieve the token value to pass to
rtas_call(). rtas_token() relies on of_get_property(), which performs
a linear search of the /rtas node's property list under a lock with
IRQs disabled.
Second, and less common: given a token value, looking up some
information about the function. The primary example is the sys_rtas
filter path, which linearly scans a small table to match the token to
a rtas_filter struct. Another use case to come is RTAS entry/exit
tracepoints, which will require efficient lookup of function names
from token values. Currently there is no general API for this.
We need something much like the existing rtas_filters table, but more
general and organized to facilitate efficient lookups.
Introduce:
* A new rtas_function type, aggregating function name, token,
and filter. Other function characteristics could be added in the
future.
* An array of rtas_function, where each element corresponds to a known
RTAS function. All information in the table is static save the token
values, which are derived from the device tree at boot. The array is
sorted by function name to allow binary search.
* A named constant for each known RTAS function, used to index the
function array. These also will be used in a client-facing API to be
added later.
* An xarray that maps valid tokens to rtas_function objects.
Fold the existing rtas_filter table into the new rtas_function array,
with the appropriate adjustments to block_rtas_call(). Remove
now-redundant fields from struct rtas_filter. Preserve the function of
the CONFIG_CPU_BIG_ENDIAN guard in the current filter table by
introducing a per-function flag that is set for the function entries
related to pseries LPAR migration. These have never had working users
via sys_rtas on ppc64le; see commit de0f7349a0dd ("powerpc/rtas:
prevent suspend-related sys_rtas use on LE").
Convert rtas_token() to use a lockless binary search on the function
table. Fall back to the old behavior for lookups against names that
are not known to be RTAS functions, but issue a warning. rtas_token()
is for function names; it is not a general facility for accessing
arbitrary properties of the /rtas node. All known misuses of
rtas_token() have been converted to more appropriate of_ APIs in
preceding changes.
Signed-off-by: Nathan Lynch <nathanl@linux.ibm.com>
Signed-off-by: Michael Ellerman <mpe@ellerman.id.au>
Link: https://lore.kernel.org/r/20230125-b4-powerpc-rtas-queue-v3-8-26929c8cce78@linux.ibm.com
2023-02-10 12:41:56 -06:00
|
|
|
|
const struct rtas_filter *f;
|
2023-12-12 11:01:52 -06:00
|
|
|
|
const bool is_platform_dump =
|
|
|
|
|
func == &rtas_function_table[RTAS_FNIDX__IBM_PLATFORM_DUMP];
|
|
|
|
|
const bool is_config_conn =
|
|
|
|
|
func == &rtas_function_table[RTAS_FNIDX__IBM_CONFIGURE_CONNECTOR];
|
powerpc/rtas: improve function information lookups
The core RTAS support code and its clients perform two types of lookup
for RTAS firmware function information.
First, mapping a known function name to a token. The typical use case
invokes rtas_token() to retrieve the token value to pass to
rtas_call(). rtas_token() relies on of_get_property(), which performs
a linear search of the /rtas node's property list under a lock with
IRQs disabled.
Second, and less common: given a token value, looking up some
information about the function. The primary example is the sys_rtas
filter path, which linearly scans a small table to match the token to
a rtas_filter struct. Another use case to come is RTAS entry/exit
tracepoints, which will require efficient lookup of function names
from token values. Currently there is no general API for this.
We need something much like the existing rtas_filters table, but more
general and organized to facilitate efficient lookups.
Introduce:
* A new rtas_function type, aggregating function name, token,
and filter. Other function characteristics could be added in the
future.
* An array of rtas_function, where each element corresponds to a known
RTAS function. All information in the table is static save the token
values, which are derived from the device tree at boot. The array is
sorted by function name to allow binary search.
* A named constant for each known RTAS function, used to index the
function array. These also will be used in a client-facing API to be
added later.
* An xarray that maps valid tokens to rtas_function objects.
Fold the existing rtas_filter table into the new rtas_function array,
with the appropriate adjustments to block_rtas_call(). Remove
now-redundant fields from struct rtas_filter. Preserve the function of
the CONFIG_CPU_BIG_ENDIAN guard in the current filter table by
introducing a per-function flag that is set for the function entries
related to pseries LPAR migration. These have never had working users
via sys_rtas on ppc64le; see commit de0f7349a0dd ("powerpc/rtas:
prevent suspend-related sys_rtas use on LE").
Convert rtas_token() to use a lockless binary search on the function
table. Fall back to the old behavior for lookups against names that
are not known to be RTAS functions, but issue a warning. rtas_token()
is for function names; it is not a general facility for accessing
arbitrary properties of the /rtas node. All known misuses of
rtas_token() have been converted to more appropriate of_ APIs in
preceding changes.
Signed-off-by: Nathan Lynch <nathanl@linux.ibm.com>
Signed-off-by: Michael Ellerman <mpe@ellerman.id.au>
Link: https://lore.kernel.org/r/20230125-b4-powerpc-rtas-queue-v3-8-26929c8cce78@linux.ibm.com
2023-02-10 12:41:56 -06:00
|
|
|
|
u32 base, size, end;
|
powerpc/rtas: Restrict RTAS requests from userspace
A number of userspace utilities depend on making calls to RTAS to retrieve
information and update various things.
The existing API through which we expose RTAS to userspace exposes more
RTAS functionality than we actually need, through the sys_rtas syscall,
which allows root (or anyone with CAP_SYS_ADMIN) to make any RTAS call they
want with arbitrary arguments.
Many RTAS calls take the address of a buffer as an argument, and it's up to
the caller to specify the physical address of the buffer as an argument. We
allocate a buffer (the "RMO buffer") in the Real Memory Area that RTAS can
access, and then expose the physical address and size of this buffer in
/proc/powerpc/rtas/rmo_buffer. Userspace is expected to read this address,
poke at the buffer using /dev/mem, and pass an address in the RMO buffer to
the RTAS call.
However, there's nothing stopping the caller from specifying whatever
address they want in the RTAS call, and it's easy to construct a series of
RTAS calls that can overwrite arbitrary bytes (even without /dev/mem
access).
Additionally, there are some RTAS calls that do potentially dangerous
things and for which there are no legitimate userspace use cases.
In the past, this would not have been a particularly big deal as it was
assumed that root could modify all system state freely, but with Secure
Boot and lockdown we need to care about this.
We can't fundamentally change the ABI at this point, however we can address
this by implementing a filter that checks RTAS calls against a list
of permitted calls and forces the caller to use addresses within the RMO
buffer.
The list is based off the list of calls that are used by the librtas
userspace library, and has been tested with a number of existing userspace
RTAS utilities. For compatibility with any applications we are not aware of
that require other calls, the filter can be turned off at build time.
Cc: stable@vger.kernel.org
Reported-by: Daniel Axtens <dja@axtens.net>
Signed-off-by: Andrew Donnellan <ajd@linux.ibm.com>
Signed-off-by: Michael Ellerman <mpe@ellerman.id.au>
Link: https://lore.kernel.org/r/20200820044512.7543-1-ajd@linux.ibm.com
2020-08-20 14:45:12 +10:00
|
|
|
|
|
powerpc/rtas: improve function information lookups
The core RTAS support code and its clients perform two types of lookup
for RTAS firmware function information.
First, mapping a known function name to a token. The typical use case
invokes rtas_token() to retrieve the token value to pass to
rtas_call(). rtas_token() relies on of_get_property(), which performs
a linear search of the /rtas node's property list under a lock with
IRQs disabled.
Second, and less common: given a token value, looking up some
information about the function. The primary example is the sys_rtas
filter path, which linearly scans a small table to match the token to
a rtas_filter struct. Another use case to come is RTAS entry/exit
tracepoints, which will require efficient lookup of function names
from token values. Currently there is no general API for this.
We need something much like the existing rtas_filters table, but more
general and organized to facilitate efficient lookups.
Introduce:
* A new rtas_function type, aggregating function name, token,
and filter. Other function characteristics could be added in the
future.
* An array of rtas_function, where each element corresponds to a known
RTAS function. All information in the table is static save the token
values, which are derived from the device tree at boot. The array is
sorted by function name to allow binary search.
* A named constant for each known RTAS function, used to index the
function array. These also will be used in a client-facing API to be
added later.
* An xarray that maps valid tokens to rtas_function objects.
Fold the existing rtas_filter table into the new rtas_function array,
with the appropriate adjustments to block_rtas_call(). Remove
now-redundant fields from struct rtas_filter. Preserve the function of
the CONFIG_CPU_BIG_ENDIAN guard in the current filter table by
introducing a per-function flag that is set for the function entries
related to pseries LPAR migration. These have never had working users
via sys_rtas on ppc64le; see commit de0f7349a0dd ("powerpc/rtas:
prevent suspend-related sys_rtas use on LE").
Convert rtas_token() to use a lockless binary search on the function
table. Fall back to the old behavior for lookups against names that
are not known to be RTAS functions, but issue a warning. rtas_token()
is for function names; it is not a general facility for accessing
arbitrary properties of the /rtas node. All known misuses of
rtas_token() have been converted to more appropriate of_ APIs in
preceding changes.
Signed-off-by: Nathan Lynch <nathanl@linux.ibm.com>
Signed-off-by: Michael Ellerman <mpe@ellerman.id.au>
Link: https://lore.kernel.org/r/20230125-b4-powerpc-rtas-queue-v3-8-26929c8cce78@linux.ibm.com
2023-02-10 12:41:56 -06:00
|
|
|
|
/*
|
2023-12-12 11:01:52 -06:00
|
|
|
|
* Only functions with filters attached are allowed.
|
powerpc/rtas: improve function information lookups
The core RTAS support code and its clients perform two types of lookup
for RTAS firmware function information.
First, mapping a known function name to a token. The typical use case
invokes rtas_token() to retrieve the token value to pass to
rtas_call(). rtas_token() relies on of_get_property(), which performs
a linear search of the /rtas node's property list under a lock with
IRQs disabled.
Second, and less common: given a token value, looking up some
information about the function. The primary example is the sys_rtas
filter path, which linearly scans a small table to match the token to
a rtas_filter struct. Another use case to come is RTAS entry/exit
tracepoints, which will require efficient lookup of function names
from token values. Currently there is no general API for this.
We need something much like the existing rtas_filters table, but more
general and organized to facilitate efficient lookups.
Introduce:
* A new rtas_function type, aggregating function name, token,
and filter. Other function characteristics could be added in the
future.
* An array of rtas_function, where each element corresponds to a known
RTAS function. All information in the table is static save the token
values, which are derived from the device tree at boot. The array is
sorted by function name to allow binary search.
* A named constant for each known RTAS function, used to index the
function array. These also will be used in a client-facing API to be
added later.
* An xarray that maps valid tokens to rtas_function objects.
Fold the existing rtas_filter table into the new rtas_function array,
with the appropriate adjustments to block_rtas_call(). Remove
now-redundant fields from struct rtas_filter. Preserve the function of
the CONFIG_CPU_BIG_ENDIAN guard in the current filter table by
introducing a per-function flag that is set for the function entries
related to pseries LPAR migration. These have never had working users
via sys_rtas on ppc64le; see commit de0f7349a0dd ("powerpc/rtas:
prevent suspend-related sys_rtas use on LE").
Convert rtas_token() to use a lockless binary search on the function
table. Fall back to the old behavior for lookups against names that
are not known to be RTAS functions, but issue a warning. rtas_token()
is for function names; it is not a general facility for accessing
arbitrary properties of the /rtas node. All known misuses of
rtas_token() have been converted to more appropriate of_ APIs in
preceding changes.
Signed-off-by: Nathan Lynch <nathanl@linux.ibm.com>
Signed-off-by: Michael Ellerman <mpe@ellerman.id.au>
Link: https://lore.kernel.org/r/20230125-b4-powerpc-rtas-queue-v3-8-26929c8cce78@linux.ibm.com
2023-02-10 12:41:56 -06:00
|
|
|
|
*/
|
|
|
|
|
f = func->filter;
|
|
|
|
|
if (!f)
|
|
|
|
|
goto err;
|
|
|
|
|
/*
|
|
|
|
|
* And some functions aren't allowed on LE.
|
|
|
|
|
*/
|
|
|
|
|
if (IS_ENABLED(CONFIG_CPU_LITTLE_ENDIAN) && func->banned_for_syscall_on_le)
|
|
|
|
|
goto err;
|
|
|
|
|
|
|
|
|
|
if (f->buf_idx1 != -1) {
|
|
|
|
|
base = be32_to_cpu(args->args[f->buf_idx1]);
|
|
|
|
|
if (f->size_idx1 != -1)
|
|
|
|
|
size = be32_to_cpu(args->args[f->size_idx1]);
|
|
|
|
|
else if (f->fixed_size)
|
|
|
|
|
size = f->fixed_size;
|
|
|
|
|
else
|
|
|
|
|
size = 1;
|
2022-06-14 23:49:52 +10:00
|
|
|
|
|
powerpc/rtas: improve function information lookups
The core RTAS support code and its clients perform two types of lookup
for RTAS firmware function information.
First, mapping a known function name to a token. The typical use case
invokes rtas_token() to retrieve the token value to pass to
rtas_call(). rtas_token() relies on of_get_property(), which performs
a linear search of the /rtas node's property list under a lock with
IRQs disabled.
Second, and less common: given a token value, looking up some
information about the function. The primary example is the sys_rtas
filter path, which linearly scans a small table to match the token to
a rtas_filter struct. Another use case to come is RTAS entry/exit
tracepoints, which will require efficient lookup of function names
from token values. Currently there is no general API for this.
We need something much like the existing rtas_filters table, but more
general and organized to facilitate efficient lookups.
Introduce:
* A new rtas_function type, aggregating function name, token,
and filter. Other function characteristics could be added in the
future.
* An array of rtas_function, where each element corresponds to a known
RTAS function. All information in the table is static save the token
values, which are derived from the device tree at boot. The array is
sorted by function name to allow binary search.
* A named constant for each known RTAS function, used to index the
function array. These also will be used in a client-facing API to be
added later.
* An xarray that maps valid tokens to rtas_function objects.
Fold the existing rtas_filter table into the new rtas_function array,
with the appropriate adjustments to block_rtas_call(). Remove
now-redundant fields from struct rtas_filter. Preserve the function of
the CONFIG_CPU_BIG_ENDIAN guard in the current filter table by
introducing a per-function flag that is set for the function entries
related to pseries LPAR migration. These have never had working users
via sys_rtas on ppc64le; see commit de0f7349a0dd ("powerpc/rtas:
prevent suspend-related sys_rtas use on LE").
Convert rtas_token() to use a lockless binary search on the function
table. Fall back to the old behavior for lookups against names that
are not known to be RTAS functions, but issue a warning. rtas_token()
is for function names; it is not a general facility for accessing
arbitrary properties of the /rtas node. All known misuses of
rtas_token() have been converted to more appropriate of_ APIs in
preceding changes.
Signed-off-by: Nathan Lynch <nathanl@linux.ibm.com>
Signed-off-by: Michael Ellerman <mpe@ellerman.id.au>
Link: https://lore.kernel.org/r/20230125-b4-powerpc-rtas-queue-v3-8-26929c8cce78@linux.ibm.com
2023-02-10 12:41:56 -06:00
|
|
|
|
end = base + size - 1;
|
2022-06-14 23:49:52 +10:00
|
|
|
|
|
powerpc/rtas: improve function information lookups
The core RTAS support code and its clients perform two types of lookup
for RTAS firmware function information.
First, mapping a known function name to a token. The typical use case
invokes rtas_token() to retrieve the token value to pass to
rtas_call(). rtas_token() relies on of_get_property(), which performs
a linear search of the /rtas node's property list under a lock with
IRQs disabled.
Second, and less common: given a token value, looking up some
information about the function. The primary example is the sys_rtas
filter path, which linearly scans a small table to match the token to
a rtas_filter struct. Another use case to come is RTAS entry/exit
tracepoints, which will require efficient lookup of function names
from token values. Currently there is no general API for this.
We need something much like the existing rtas_filters table, but more
general and organized to facilitate efficient lookups.
Introduce:
* A new rtas_function type, aggregating function name, token,
and filter. Other function characteristics could be added in the
future.
* An array of rtas_function, where each element corresponds to a known
RTAS function. All information in the table is static save the token
values, which are derived from the device tree at boot. The array is
sorted by function name to allow binary search.
* A named constant for each known RTAS function, used to index the
function array. These also will be used in a client-facing API to be
added later.
* An xarray that maps valid tokens to rtas_function objects.
Fold the existing rtas_filter table into the new rtas_function array,
with the appropriate adjustments to block_rtas_call(). Remove
now-redundant fields from struct rtas_filter. Preserve the function of
the CONFIG_CPU_BIG_ENDIAN guard in the current filter table by
introducing a per-function flag that is set for the function entries
related to pseries LPAR migration. These have never had working users
via sys_rtas on ppc64le; see commit de0f7349a0dd ("powerpc/rtas:
prevent suspend-related sys_rtas use on LE").
Convert rtas_token() to use a lockless binary search on the function
table. Fall back to the old behavior for lookups against names that
are not known to be RTAS functions, but issue a warning. rtas_token()
is for function names; it is not a general facility for accessing
arbitrary properties of the /rtas node. All known misuses of
rtas_token() have been converted to more appropriate of_ APIs in
preceding changes.
Signed-off-by: Nathan Lynch <nathanl@linux.ibm.com>
Signed-off-by: Michael Ellerman <mpe@ellerman.id.au>
Link: https://lore.kernel.org/r/20230125-b4-powerpc-rtas-queue-v3-8-26929c8cce78@linux.ibm.com
2023-02-10 12:41:56 -06:00
|
|
|
|
/*
|
|
|
|
|
* Special case for ibm,platform-dump - NULL buffer
|
|
|
|
|
* address is used to indicate end of dump processing
|
|
|
|
|
*/
|
2023-02-10 12:42:08 -06:00
|
|
|
|
if (is_platform_dump && base == 0)
|
powerpc/rtas: improve function information lookups
The core RTAS support code and its clients perform two types of lookup
for RTAS firmware function information.
First, mapping a known function name to a token. The typical use case
invokes rtas_token() to retrieve the token value to pass to
rtas_call(). rtas_token() relies on of_get_property(), which performs
a linear search of the /rtas node's property list under a lock with
IRQs disabled.
Second, and less common: given a token value, looking up some
information about the function. The primary example is the sys_rtas
filter path, which linearly scans a small table to match the token to
a rtas_filter struct. Another use case to come is RTAS entry/exit
tracepoints, which will require efficient lookup of function names
from token values. Currently there is no general API for this.
We need something much like the existing rtas_filters table, but more
general and organized to facilitate efficient lookups.
Introduce:
* A new rtas_function type, aggregating function name, token,
and filter. Other function characteristics could be added in the
future.
* An array of rtas_function, where each element corresponds to a known
RTAS function. All information in the table is static save the token
values, which are derived from the device tree at boot. The array is
sorted by function name to allow binary search.
* A named constant for each known RTAS function, used to index the
function array. These also will be used in a client-facing API to be
added later.
* An xarray that maps valid tokens to rtas_function objects.
Fold the existing rtas_filter table into the new rtas_function array,
with the appropriate adjustments to block_rtas_call(). Remove
now-redundant fields from struct rtas_filter. Preserve the function of
the CONFIG_CPU_BIG_ENDIAN guard in the current filter table by
introducing a per-function flag that is set for the function entries
related to pseries LPAR migration. These have never had working users
via sys_rtas on ppc64le; see commit de0f7349a0dd ("powerpc/rtas:
prevent suspend-related sys_rtas use on LE").
Convert rtas_token() to use a lockless binary search on the function
table. Fall back to the old behavior for lookups against names that
are not known to be RTAS functions, but issue a warning. rtas_token()
is for function names; it is not a general facility for accessing
arbitrary properties of the /rtas node. All known misuses of
rtas_token() have been converted to more appropriate of_ APIs in
preceding changes.
Signed-off-by: Nathan Lynch <nathanl@linux.ibm.com>
Signed-off-by: Michael Ellerman <mpe@ellerman.id.au>
Link: https://lore.kernel.org/r/20230125-b4-powerpc-rtas-queue-v3-8-26929c8cce78@linux.ibm.com
2023-02-10 12:41:56 -06:00
|
|
|
|
return false;
|
powerpc/rtas: Restrict RTAS requests from userspace
A number of userspace utilities depend on making calls to RTAS to retrieve
information and update various things.
The existing API through which we expose RTAS to userspace exposes more
RTAS functionality than we actually need, through the sys_rtas syscall,
which allows root (or anyone with CAP_SYS_ADMIN) to make any RTAS call they
want with arbitrary arguments.
Many RTAS calls take the address of a buffer as an argument, and it's up to
the caller to specify the physical address of the buffer as an argument. We
allocate a buffer (the "RMO buffer") in the Real Memory Area that RTAS can
access, and then expose the physical address and size of this buffer in
/proc/powerpc/rtas/rmo_buffer. Userspace is expected to read this address,
poke at the buffer using /dev/mem, and pass an address in the RMO buffer to
the RTAS call.
However, there's nothing stopping the caller from specifying whatever
address they want in the RTAS call, and it's easy to construct a series of
RTAS calls that can overwrite arbitrary bytes (even without /dev/mem
access).
Additionally, there are some RTAS calls that do potentially dangerous
things and for which there are no legitimate userspace use cases.
In the past, this would not have been a particularly big deal as it was
assumed that root could modify all system state freely, but with Secure
Boot and lockdown we need to care about this.
We can't fundamentally change the ABI at this point, however we can address
this by implementing a filter that checks RTAS calls against a list
of permitted calls and forces the caller to use addresses within the RMO
buffer.
The list is based off the list of calls that are used by the librtas
userspace library, and has been tested with a number of existing userspace
RTAS utilities. For compatibility with any applications we are not aware of
that require other calls, the filter can be turned off at build time.
Cc: stable@vger.kernel.org
Reported-by: Daniel Axtens <dja@axtens.net>
Signed-off-by: Andrew Donnellan <ajd@linux.ibm.com>
Signed-off-by: Michael Ellerman <mpe@ellerman.id.au>
Link: https://lore.kernel.org/r/20200820044512.7543-1-ajd@linux.ibm.com
2020-08-20 14:45:12 +10:00
|
|
|
|
|
powerpc/rtas: improve function information lookups
The core RTAS support code and its clients perform two types of lookup
for RTAS firmware function information.
First, mapping a known function name to a token. The typical use case
invokes rtas_token() to retrieve the token value to pass to
rtas_call(). rtas_token() relies on of_get_property(), which performs
a linear search of the /rtas node's property list under a lock with
IRQs disabled.
Second, and less common: given a token value, looking up some
information about the function. The primary example is the sys_rtas
filter path, which linearly scans a small table to match the token to
a rtas_filter struct. Another use case to come is RTAS entry/exit
tracepoints, which will require efficient lookup of function names
from token values. Currently there is no general API for this.
We need something much like the existing rtas_filters table, but more
general and organized to facilitate efficient lookups.
Introduce:
* A new rtas_function type, aggregating function name, token,
and filter. Other function characteristics could be added in the
future.
* An array of rtas_function, where each element corresponds to a known
RTAS function. All information in the table is static save the token
values, which are derived from the device tree at boot. The array is
sorted by function name to allow binary search.
* A named constant for each known RTAS function, used to index the
function array. These also will be used in a client-facing API to be
added later.
* An xarray that maps valid tokens to rtas_function objects.
Fold the existing rtas_filter table into the new rtas_function array,
with the appropriate adjustments to block_rtas_call(). Remove
now-redundant fields from struct rtas_filter. Preserve the function of
the CONFIG_CPU_BIG_ENDIAN guard in the current filter table by
introducing a per-function flag that is set for the function entries
related to pseries LPAR migration. These have never had working users
via sys_rtas on ppc64le; see commit de0f7349a0dd ("powerpc/rtas:
prevent suspend-related sys_rtas use on LE").
Convert rtas_token() to use a lockless binary search on the function
table. Fall back to the old behavior for lookups against names that
are not known to be RTAS functions, but issue a warning. rtas_token()
is for function names; it is not a general facility for accessing
arbitrary properties of the /rtas node. All known misuses of
rtas_token() have been converted to more appropriate of_ APIs in
preceding changes.
Signed-off-by: Nathan Lynch <nathanl@linux.ibm.com>
Signed-off-by: Michael Ellerman <mpe@ellerman.id.au>
Link: https://lore.kernel.org/r/20230125-b4-powerpc-rtas-queue-v3-8-26929c8cce78@linux.ibm.com
2023-02-10 12:41:56 -06:00
|
|
|
|
if (!in_rmo_buf(base, end))
|
|
|
|
|
goto err;
|
|
|
|
|
}
|
powerpc/rtas: Restrict RTAS requests from userspace
A number of userspace utilities depend on making calls to RTAS to retrieve
information and update various things.
The existing API through which we expose RTAS to userspace exposes more
RTAS functionality than we actually need, through the sys_rtas syscall,
which allows root (or anyone with CAP_SYS_ADMIN) to make any RTAS call they
want with arbitrary arguments.
Many RTAS calls take the address of a buffer as an argument, and it's up to
the caller to specify the physical address of the buffer as an argument. We
allocate a buffer (the "RMO buffer") in the Real Memory Area that RTAS can
access, and then expose the physical address and size of this buffer in
/proc/powerpc/rtas/rmo_buffer. Userspace is expected to read this address,
poke at the buffer using /dev/mem, and pass an address in the RMO buffer to
the RTAS call.
However, there's nothing stopping the caller from specifying whatever
address they want in the RTAS call, and it's easy to construct a series of
RTAS calls that can overwrite arbitrary bytes (even without /dev/mem
access).
Additionally, there are some RTAS calls that do potentially dangerous
things and for which there are no legitimate userspace use cases.
In the past, this would not have been a particularly big deal as it was
assumed that root could modify all system state freely, but with Secure
Boot and lockdown we need to care about this.
We can't fundamentally change the ABI at this point, however we can address
this by implementing a filter that checks RTAS calls against a list
of permitted calls and forces the caller to use addresses within the RMO
buffer.
The list is based off the list of calls that are used by the librtas
userspace library, and has been tested with a number of existing userspace
RTAS utilities. For compatibility with any applications we are not aware of
that require other calls, the filter can be turned off at build time.
Cc: stable@vger.kernel.org
Reported-by: Daniel Axtens <dja@axtens.net>
Signed-off-by: Andrew Donnellan <ajd@linux.ibm.com>
Signed-off-by: Michael Ellerman <mpe@ellerman.id.au>
Link: https://lore.kernel.org/r/20200820044512.7543-1-ajd@linux.ibm.com
2020-08-20 14:45:12 +10:00
|
|
|
|
|
powerpc/rtas: improve function information lookups
The core RTAS support code and its clients perform two types of lookup
for RTAS firmware function information.
First, mapping a known function name to a token. The typical use case
invokes rtas_token() to retrieve the token value to pass to
rtas_call(). rtas_token() relies on of_get_property(), which performs
a linear search of the /rtas node's property list under a lock with
IRQs disabled.
Second, and less common: given a token value, looking up some
information about the function. The primary example is the sys_rtas
filter path, which linearly scans a small table to match the token to
a rtas_filter struct. Another use case to come is RTAS entry/exit
tracepoints, which will require efficient lookup of function names
from token values. Currently there is no general API for this.
We need something much like the existing rtas_filters table, but more
general and organized to facilitate efficient lookups.
Introduce:
* A new rtas_function type, aggregating function name, token,
and filter. Other function characteristics could be added in the
future.
* An array of rtas_function, where each element corresponds to a known
RTAS function. All information in the table is static save the token
values, which are derived from the device tree at boot. The array is
sorted by function name to allow binary search.
* A named constant for each known RTAS function, used to index the
function array. These also will be used in a client-facing API to be
added later.
* An xarray that maps valid tokens to rtas_function objects.
Fold the existing rtas_filter table into the new rtas_function array,
with the appropriate adjustments to block_rtas_call(). Remove
now-redundant fields from struct rtas_filter. Preserve the function of
the CONFIG_CPU_BIG_ENDIAN guard in the current filter table by
introducing a per-function flag that is set for the function entries
related to pseries LPAR migration. These have never had working users
via sys_rtas on ppc64le; see commit de0f7349a0dd ("powerpc/rtas:
prevent suspend-related sys_rtas use on LE").
Convert rtas_token() to use a lockless binary search on the function
table. Fall back to the old behavior for lookups against names that
are not known to be RTAS functions, but issue a warning. rtas_token()
is for function names; it is not a general facility for accessing
arbitrary properties of the /rtas node. All known misuses of
rtas_token() have been converted to more appropriate of_ APIs in
preceding changes.
Signed-off-by: Nathan Lynch <nathanl@linux.ibm.com>
Signed-off-by: Michael Ellerman <mpe@ellerman.id.au>
Link: https://lore.kernel.org/r/20230125-b4-powerpc-rtas-queue-v3-8-26929c8cce78@linux.ibm.com
2023-02-10 12:41:56 -06:00
|
|
|
|
if (f->buf_idx2 != -1) {
|
|
|
|
|
base = be32_to_cpu(args->args[f->buf_idx2]);
|
|
|
|
|
if (f->size_idx2 != -1)
|
|
|
|
|
size = be32_to_cpu(args->args[f->size_idx2]);
|
|
|
|
|
else if (f->fixed_size)
|
|
|
|
|
size = f->fixed_size;
|
|
|
|
|
else
|
|
|
|
|
size = 1;
|
|
|
|
|
end = base + size - 1;
|
powerpc/rtas: Restrict RTAS requests from userspace
A number of userspace utilities depend on making calls to RTAS to retrieve
information and update various things.
The existing API through which we expose RTAS to userspace exposes more
RTAS functionality than we actually need, through the sys_rtas syscall,
which allows root (or anyone with CAP_SYS_ADMIN) to make any RTAS call they
want with arbitrary arguments.
Many RTAS calls take the address of a buffer as an argument, and it's up to
the caller to specify the physical address of the buffer as an argument. We
allocate a buffer (the "RMO buffer") in the Real Memory Area that RTAS can
access, and then expose the physical address and size of this buffer in
/proc/powerpc/rtas/rmo_buffer. Userspace is expected to read this address,
poke at the buffer using /dev/mem, and pass an address in the RMO buffer to
the RTAS call.
However, there's nothing stopping the caller from specifying whatever
address they want in the RTAS call, and it's easy to construct a series of
RTAS calls that can overwrite arbitrary bytes (even without /dev/mem
access).
Additionally, there are some RTAS calls that do potentially dangerous
things and for which there are no legitimate userspace use cases.
In the past, this would not have been a particularly big deal as it was
assumed that root could modify all system state freely, but with Secure
Boot and lockdown we need to care about this.
We can't fundamentally change the ABI at this point, however we can address
this by implementing a filter that checks RTAS calls against a list
of permitted calls and forces the caller to use addresses within the RMO
buffer.
The list is based off the list of calls that are used by the librtas
userspace library, and has been tested with a number of existing userspace
RTAS utilities. For compatibility with any applications we are not aware of
that require other calls, the filter can be turned off at build time.
Cc: stable@vger.kernel.org
Reported-by: Daniel Axtens <dja@axtens.net>
Signed-off-by: Andrew Donnellan <ajd@linux.ibm.com>
Signed-off-by: Michael Ellerman <mpe@ellerman.id.au>
Link: https://lore.kernel.org/r/20200820044512.7543-1-ajd@linux.ibm.com
2020-08-20 14:45:12 +10:00
|
|
|
|
|
powerpc/rtas: improve function information lookups
The core RTAS support code and its clients perform two types of lookup
for RTAS firmware function information.
First, mapping a known function name to a token. The typical use case
invokes rtas_token() to retrieve the token value to pass to
rtas_call(). rtas_token() relies on of_get_property(), which performs
a linear search of the /rtas node's property list under a lock with
IRQs disabled.
Second, and less common: given a token value, looking up some
information about the function. The primary example is the sys_rtas
filter path, which linearly scans a small table to match the token to
a rtas_filter struct. Another use case to come is RTAS entry/exit
tracepoints, which will require efficient lookup of function names
from token values. Currently there is no general API for this.
We need something much like the existing rtas_filters table, but more
general and organized to facilitate efficient lookups.
Introduce:
* A new rtas_function type, aggregating function name, token,
and filter. Other function characteristics could be added in the
future.
* An array of rtas_function, where each element corresponds to a known
RTAS function. All information in the table is static save the token
values, which are derived from the device tree at boot. The array is
sorted by function name to allow binary search.
* A named constant for each known RTAS function, used to index the
function array. These also will be used in a client-facing API to be
added later.
* An xarray that maps valid tokens to rtas_function objects.
Fold the existing rtas_filter table into the new rtas_function array,
with the appropriate adjustments to block_rtas_call(). Remove
now-redundant fields from struct rtas_filter. Preserve the function of
the CONFIG_CPU_BIG_ENDIAN guard in the current filter table by
introducing a per-function flag that is set for the function entries
related to pseries LPAR migration. These have never had working users
via sys_rtas on ppc64le; see commit de0f7349a0dd ("powerpc/rtas:
prevent suspend-related sys_rtas use on LE").
Convert rtas_token() to use a lockless binary search on the function
table. Fall back to the old behavior for lookups against names that
are not known to be RTAS functions, but issue a warning. rtas_token()
is for function names; it is not a general facility for accessing
arbitrary properties of the /rtas node. All known misuses of
rtas_token() have been converted to more appropriate of_ APIs in
preceding changes.
Signed-off-by: Nathan Lynch <nathanl@linux.ibm.com>
Signed-off-by: Michael Ellerman <mpe@ellerman.id.au>
Link: https://lore.kernel.org/r/20230125-b4-powerpc-rtas-queue-v3-8-26929c8cce78@linux.ibm.com
2023-02-10 12:41:56 -06:00
|
|
|
|
/*
|
|
|
|
|
* Special case for ibm,configure-connector where the
|
|
|
|
|
* address can be 0
|
|
|
|
|
*/
|
2023-02-10 12:42:08 -06:00
|
|
|
|
if (is_config_conn && base == 0)
|
powerpc/rtas: improve function information lookups
The core RTAS support code and its clients perform two types of lookup
for RTAS firmware function information.
First, mapping a known function name to a token. The typical use case
invokes rtas_token() to retrieve the token value to pass to
rtas_call(). rtas_token() relies on of_get_property(), which performs
a linear search of the /rtas node's property list under a lock with
IRQs disabled.
Second, and less common: given a token value, looking up some
information about the function. The primary example is the sys_rtas
filter path, which linearly scans a small table to match the token to
a rtas_filter struct. Another use case to come is RTAS entry/exit
tracepoints, which will require efficient lookup of function names
from token values. Currently there is no general API for this.
We need something much like the existing rtas_filters table, but more
general and organized to facilitate efficient lookups.
Introduce:
* A new rtas_function type, aggregating function name, token,
and filter. Other function characteristics could be added in the
future.
* An array of rtas_function, where each element corresponds to a known
RTAS function. All information in the table is static save the token
values, which are derived from the device tree at boot. The array is
sorted by function name to allow binary search.
* A named constant for each known RTAS function, used to index the
function array. These also will be used in a client-facing API to be
added later.
* An xarray that maps valid tokens to rtas_function objects.
Fold the existing rtas_filter table into the new rtas_function array,
with the appropriate adjustments to block_rtas_call(). Remove
now-redundant fields from struct rtas_filter. Preserve the function of
the CONFIG_CPU_BIG_ENDIAN guard in the current filter table by
introducing a per-function flag that is set for the function entries
related to pseries LPAR migration. These have never had working users
via sys_rtas on ppc64le; see commit de0f7349a0dd ("powerpc/rtas:
prevent suspend-related sys_rtas use on LE").
Convert rtas_token() to use a lockless binary search on the function
table. Fall back to the old behavior for lookups against names that
are not known to be RTAS functions, but issue a warning. rtas_token()
is for function names; it is not a general facility for accessing
arbitrary properties of the /rtas node. All known misuses of
rtas_token() have been converted to more appropriate of_ APIs in
preceding changes.
Signed-off-by: Nathan Lynch <nathanl@linux.ibm.com>
Signed-off-by: Michael Ellerman <mpe@ellerman.id.au>
Link: https://lore.kernel.org/r/20230125-b4-powerpc-rtas-queue-v3-8-26929c8cce78@linux.ibm.com
2023-02-10 12:41:56 -06:00
|
|
|
|
return false;
|
powerpc/rtas: Restrict RTAS requests from userspace
A number of userspace utilities depend on making calls to RTAS to retrieve
information and update various things.
The existing API through which we expose RTAS to userspace exposes more
RTAS functionality than we actually need, through the sys_rtas syscall,
which allows root (or anyone with CAP_SYS_ADMIN) to make any RTAS call they
want with arbitrary arguments.
Many RTAS calls take the address of a buffer as an argument, and it's up to
the caller to specify the physical address of the buffer as an argument. We
allocate a buffer (the "RMO buffer") in the Real Memory Area that RTAS can
access, and then expose the physical address and size of this buffer in
/proc/powerpc/rtas/rmo_buffer. Userspace is expected to read this address,
poke at the buffer using /dev/mem, and pass an address in the RMO buffer to
the RTAS call.
However, there's nothing stopping the caller from specifying whatever
address they want in the RTAS call, and it's easy to construct a series of
RTAS calls that can overwrite arbitrary bytes (even without /dev/mem
access).
Additionally, there are some RTAS calls that do potentially dangerous
things and for which there are no legitimate userspace use cases.
In the past, this would not have been a particularly big deal as it was
assumed that root could modify all system state freely, but with Secure
Boot and lockdown we need to care about this.
We can't fundamentally change the ABI at this point, however we can address
this by implementing a filter that checks RTAS calls against a list
of permitted calls and forces the caller to use addresses within the RMO
buffer.
The list is based off the list of calls that are used by the librtas
userspace library, and has been tested with a number of existing userspace
RTAS utilities. For compatibility with any applications we are not aware of
that require other calls, the filter can be turned off at build time.
Cc: stable@vger.kernel.org
Reported-by: Daniel Axtens <dja@axtens.net>
Signed-off-by: Andrew Donnellan <ajd@linux.ibm.com>
Signed-off-by: Michael Ellerman <mpe@ellerman.id.au>
Link: https://lore.kernel.org/r/20200820044512.7543-1-ajd@linux.ibm.com
2020-08-20 14:45:12 +10:00
|
|
|
|
|
powerpc/rtas: improve function information lookups
The core RTAS support code and its clients perform two types of lookup
for RTAS firmware function information.
First, mapping a known function name to a token. The typical use case
invokes rtas_token() to retrieve the token value to pass to
rtas_call(). rtas_token() relies on of_get_property(), which performs
a linear search of the /rtas node's property list under a lock with
IRQs disabled.
Second, and less common: given a token value, looking up some
information about the function. The primary example is the sys_rtas
filter path, which linearly scans a small table to match the token to
a rtas_filter struct. Another use case to come is RTAS entry/exit
tracepoints, which will require efficient lookup of function names
from token values. Currently there is no general API for this.
We need something much like the existing rtas_filters table, but more
general and organized to facilitate efficient lookups.
Introduce:
* A new rtas_function type, aggregating function name, token,
and filter. Other function characteristics could be added in the
future.
* An array of rtas_function, where each element corresponds to a known
RTAS function. All information in the table is static save the token
values, which are derived from the device tree at boot. The array is
sorted by function name to allow binary search.
* A named constant for each known RTAS function, used to index the
function array. These also will be used in a client-facing API to be
added later.
* An xarray that maps valid tokens to rtas_function objects.
Fold the existing rtas_filter table into the new rtas_function array,
with the appropriate adjustments to block_rtas_call(). Remove
now-redundant fields from struct rtas_filter. Preserve the function of
the CONFIG_CPU_BIG_ENDIAN guard in the current filter table by
introducing a per-function flag that is set for the function entries
related to pseries LPAR migration. These have never had working users
via sys_rtas on ppc64le; see commit de0f7349a0dd ("powerpc/rtas:
prevent suspend-related sys_rtas use on LE").
Convert rtas_token() to use a lockless binary search on the function
table. Fall back to the old behavior for lookups against names that
are not known to be RTAS functions, but issue a warning. rtas_token()
is for function names; it is not a general facility for accessing
arbitrary properties of the /rtas node. All known misuses of
rtas_token() have been converted to more appropriate of_ APIs in
preceding changes.
Signed-off-by: Nathan Lynch <nathanl@linux.ibm.com>
Signed-off-by: Michael Ellerman <mpe@ellerman.id.au>
Link: https://lore.kernel.org/r/20230125-b4-powerpc-rtas-queue-v3-8-26929c8cce78@linux.ibm.com
2023-02-10 12:41:56 -06:00
|
|
|
|
if (!in_rmo_buf(base, end))
|
|
|
|
|
goto err;
|
powerpc/rtas: Restrict RTAS requests from userspace
A number of userspace utilities depend on making calls to RTAS to retrieve
information and update various things.
The existing API through which we expose RTAS to userspace exposes more
RTAS functionality than we actually need, through the sys_rtas syscall,
which allows root (or anyone with CAP_SYS_ADMIN) to make any RTAS call they
want with arbitrary arguments.
Many RTAS calls take the address of a buffer as an argument, and it's up to
the caller to specify the physical address of the buffer as an argument. We
allocate a buffer (the "RMO buffer") in the Real Memory Area that RTAS can
access, and then expose the physical address and size of this buffer in
/proc/powerpc/rtas/rmo_buffer. Userspace is expected to read this address,
poke at the buffer using /dev/mem, and pass an address in the RMO buffer to
the RTAS call.
However, there's nothing stopping the caller from specifying whatever
address they want in the RTAS call, and it's easy to construct a series of
RTAS calls that can overwrite arbitrary bytes (even without /dev/mem
access).
Additionally, there are some RTAS calls that do potentially dangerous
things and for which there are no legitimate userspace use cases.
In the past, this would not have been a particularly big deal as it was
assumed that root could modify all system state freely, but with Secure
Boot and lockdown we need to care about this.
We can't fundamentally change the ABI at this point, however we can address
this by implementing a filter that checks RTAS calls against a list
of permitted calls and forces the caller to use addresses within the RMO
buffer.
The list is based off the list of calls that are used by the librtas
userspace library, and has been tested with a number of existing userspace
RTAS utilities. For compatibility with any applications we are not aware of
that require other calls, the filter can be turned off at build time.
Cc: stable@vger.kernel.org
Reported-by: Daniel Axtens <dja@axtens.net>
Signed-off-by: Andrew Donnellan <ajd@linux.ibm.com>
Signed-off-by: Michael Ellerman <mpe@ellerman.id.au>
Link: https://lore.kernel.org/r/20200820044512.7543-1-ajd@linux.ibm.com
2020-08-20 14:45:12 +10:00
|
|
|
|
}
|
|
|
|
|
|
powerpc/rtas: improve function information lookups
The core RTAS support code and its clients perform two types of lookup
for RTAS firmware function information.
First, mapping a known function name to a token. The typical use case
invokes rtas_token() to retrieve the token value to pass to
rtas_call(). rtas_token() relies on of_get_property(), which performs
a linear search of the /rtas node's property list under a lock with
IRQs disabled.
Second, and less common: given a token value, looking up some
information about the function. The primary example is the sys_rtas
filter path, which linearly scans a small table to match the token to
a rtas_filter struct. Another use case to come is RTAS entry/exit
tracepoints, which will require efficient lookup of function names
from token values. Currently there is no general API for this.
We need something much like the existing rtas_filters table, but more
general and organized to facilitate efficient lookups.
Introduce:
* A new rtas_function type, aggregating function name, token,
and filter. Other function characteristics could be added in the
future.
* An array of rtas_function, where each element corresponds to a known
RTAS function. All information in the table is static save the token
values, which are derived from the device tree at boot. The array is
sorted by function name to allow binary search.
* A named constant for each known RTAS function, used to index the
function array. These also will be used in a client-facing API to be
added later.
* An xarray that maps valid tokens to rtas_function objects.
Fold the existing rtas_filter table into the new rtas_function array,
with the appropriate adjustments to block_rtas_call(). Remove
now-redundant fields from struct rtas_filter. Preserve the function of
the CONFIG_CPU_BIG_ENDIAN guard in the current filter table by
introducing a per-function flag that is set for the function entries
related to pseries LPAR migration. These have never had working users
via sys_rtas on ppc64le; see commit de0f7349a0dd ("powerpc/rtas:
prevent suspend-related sys_rtas use on LE").
Convert rtas_token() to use a lockless binary search on the function
table. Fall back to the old behavior for lookups against names that
are not known to be RTAS functions, but issue a warning. rtas_token()
is for function names; it is not a general facility for accessing
arbitrary properties of the /rtas node. All known misuses of
rtas_token() have been converted to more appropriate of_ APIs in
preceding changes.
Signed-off-by: Nathan Lynch <nathanl@linux.ibm.com>
Signed-off-by: Michael Ellerman <mpe@ellerman.id.au>
Link: https://lore.kernel.org/r/20230125-b4-powerpc-rtas-queue-v3-8-26929c8cce78@linux.ibm.com
2023-02-10 12:41:56 -06:00
|
|
|
|
return false;
|
powerpc/rtas: Restrict RTAS requests from userspace
A number of userspace utilities depend on making calls to RTAS to retrieve
information and update various things.
The existing API through which we expose RTAS to userspace exposes more
RTAS functionality than we actually need, through the sys_rtas syscall,
which allows root (or anyone with CAP_SYS_ADMIN) to make any RTAS call they
want with arbitrary arguments.
Many RTAS calls take the address of a buffer as an argument, and it's up to
the caller to specify the physical address of the buffer as an argument. We
allocate a buffer (the "RMO buffer") in the Real Memory Area that RTAS can
access, and then expose the physical address and size of this buffer in
/proc/powerpc/rtas/rmo_buffer. Userspace is expected to read this address,
poke at the buffer using /dev/mem, and pass an address in the RMO buffer to
the RTAS call.
However, there's nothing stopping the caller from specifying whatever
address they want in the RTAS call, and it's easy to construct a series of
RTAS calls that can overwrite arbitrary bytes (even without /dev/mem
access).
Additionally, there are some RTAS calls that do potentially dangerous
things and for which there are no legitimate userspace use cases.
In the past, this would not have been a particularly big deal as it was
assumed that root could modify all system state freely, but with Secure
Boot and lockdown we need to care about this.
We can't fundamentally change the ABI at this point, however we can address
this by implementing a filter that checks RTAS calls against a list
of permitted calls and forces the caller to use addresses within the RMO
buffer.
The list is based off the list of calls that are used by the librtas
userspace library, and has been tested with a number of existing userspace
RTAS utilities. For compatibility with any applications we are not aware of
that require other calls, the filter can be turned off at build time.
Cc: stable@vger.kernel.org
Reported-by: Daniel Axtens <dja@axtens.net>
Signed-off-by: Andrew Donnellan <ajd@linux.ibm.com>
Signed-off-by: Michael Ellerman <mpe@ellerman.id.au>
Link: https://lore.kernel.org/r/20200820044512.7543-1-ajd@linux.ibm.com
2020-08-20 14:45:12 +10:00
|
|
|
|
err:
|
|
|
|
|
pr_err_ratelimited("sys_rtas: RTAS call blocked - exploit attempt?\n");
|
2023-12-12 11:01:52 -06:00
|
|
|
|
pr_err_ratelimited("sys_rtas: %s nargs=%d (called by %s)\n",
|
|
|
|
|
func->name, nargs, current->comm);
|
powerpc/rtas: Restrict RTAS requests from userspace
A number of userspace utilities depend on making calls to RTAS to retrieve
information and update various things.
The existing API through which we expose RTAS to userspace exposes more
RTAS functionality than we actually need, through the sys_rtas syscall,
which allows root (or anyone with CAP_SYS_ADMIN) to make any RTAS call they
want with arbitrary arguments.
Many RTAS calls take the address of a buffer as an argument, and it's up to
the caller to specify the physical address of the buffer as an argument. We
allocate a buffer (the "RMO buffer") in the Real Memory Area that RTAS can
access, and then expose the physical address and size of this buffer in
/proc/powerpc/rtas/rmo_buffer. Userspace is expected to read this address,
poke at the buffer using /dev/mem, and pass an address in the RMO buffer to
the RTAS call.
However, there's nothing stopping the caller from specifying whatever
address they want in the RTAS call, and it's easy to construct a series of
RTAS calls that can overwrite arbitrary bytes (even without /dev/mem
access).
Additionally, there are some RTAS calls that do potentially dangerous
things and for which there are no legitimate userspace use cases.
In the past, this would not have been a particularly big deal as it was
assumed that root could modify all system state freely, but with Secure
Boot and lockdown we need to care about this.
We can't fundamentally change the ABI at this point, however we can address
this by implementing a filter that checks RTAS calls against a list
of permitted calls and forces the caller to use addresses within the RMO
buffer.
The list is based off the list of calls that are used by the librtas
userspace library, and has been tested with a number of existing userspace
RTAS utilities. For compatibility with any applications we are not aware of
that require other calls, the filter can be turned off at build time.
Cc: stable@vger.kernel.org
Reported-by: Daniel Axtens <dja@axtens.net>
Signed-off-by: Andrew Donnellan <ajd@linux.ibm.com>
Signed-off-by: Michael Ellerman <mpe@ellerman.id.au>
Link: https://lore.kernel.org/r/20200820044512.7543-1-ajd@linux.ibm.com
2020-08-20 14:45:12 +10:00
|
|
|
|
return true;
|
|
|
|
|
}
|
|
|
|
|
|
2014-03-19 17:02:51 +01:00
|
|
|
|
/* We assume to be passed big endian arguments */
|
2018-05-02 23:20:48 +10:00
|
|
|
|
SYSCALL_DEFINE1(rtas, struct rtas_args __user *, uargs)
|
2005-04-16 15:20:36 -07:00
|
|
|
|
{
|
2023-12-12 11:01:52 -06:00
|
|
|
|
const struct rtas_function *func;
|
2023-03-06 15:33:45 -06:00
|
|
|
|
struct pin_cookie cookie;
|
2005-04-16 15:20:36 -07:00
|
|
|
|
struct rtas_args args;
|
|
|
|
|
unsigned long flags;
|
2005-10-26 17:05:24 +10:00
|
|
|
|
char *buff_copy, *errbuf = NULL;
|
2014-03-19 17:02:51 +01:00
|
|
|
|
int nargs, nret, token;
|
2005-04-16 15:20:36 -07:00
|
|
|
|
|
|
|
|
|
if (!capable(CAP_SYS_ADMIN))
|
|
|
|
|
return -EPERM;
|
|
|
|
|
|
2015-10-16 15:53:29 +05:30
|
|
|
|
if (!rtas.entry)
|
|
|
|
|
return -EINVAL;
|
|
|
|
|
|
2005-04-16 15:20:36 -07:00
|
|
|
|
if (copy_from_user(&args, uargs, 3 * sizeof(u32)) != 0)
|
|
|
|
|
return -EFAULT;
|
|
|
|
|
|
2014-03-19 17:02:51 +01:00
|
|
|
|
nargs = be32_to_cpu(args.nargs);
|
|
|
|
|
nret = be32_to_cpu(args.nret);
|
|
|
|
|
token = be32_to_cpu(args.token);
|
|
|
|
|
|
2016-03-18 17:36:33 +11:00
|
|
|
|
if (nargs >= ARRAY_SIZE(args.args)
|
2014-03-19 17:02:51 +01:00
|
|
|
|
|| nret > ARRAY_SIZE(args.args)
|
|
|
|
|
|| nargs + nret > ARRAY_SIZE(args.args))
|
2005-04-16 15:20:36 -07:00
|
|
|
|
return -EINVAL;
|
|
|
|
|
|
|
|
|
|
/* Copy in args. */
|
|
|
|
|
if (copy_from_user(args.args, uargs->args,
|
|
|
|
|
nargs * sizeof(rtas_arg_t)) != 0)
|
|
|
|
|
return -EFAULT;
|
|
|
|
|
|
2023-12-12 11:01:52 -06:00
|
|
|
|
/*
|
|
|
|
|
* If this token doesn't correspond to a function the kernel
|
|
|
|
|
* understands, you're not allowed to call it.
|
|
|
|
|
*/
|
|
|
|
|
func = rtas_token_to_function_untrusted(token);
|
|
|
|
|
if (!func)
|
2006-01-13 18:39:24 -06:00
|
|
|
|
return -EINVAL;
|
|
|
|
|
|
2008-07-31 02:23:27 +10:00
|
|
|
|
args.rets = &args.args[nargs];
|
2014-03-19 17:02:51 +01:00
|
|
|
|
memset(args.rets, 0, nret * sizeof(rtas_arg_t));
|
2008-07-31 02:23:27 +10:00
|
|
|
|
|
2023-12-12 11:01:52 -06:00
|
|
|
|
if (block_rtas_call(func, nargs, &args))
|
powerpc/rtas: Restrict RTAS requests from userspace
A number of userspace utilities depend on making calls to RTAS to retrieve
information and update various things.
The existing API through which we expose RTAS to userspace exposes more
RTAS functionality than we actually need, through the sys_rtas syscall,
which allows root (or anyone with CAP_SYS_ADMIN) to make any RTAS call they
want with arbitrary arguments.
Many RTAS calls take the address of a buffer as an argument, and it's up to
the caller to specify the physical address of the buffer as an argument. We
allocate a buffer (the "RMO buffer") in the Real Memory Area that RTAS can
access, and then expose the physical address and size of this buffer in
/proc/powerpc/rtas/rmo_buffer. Userspace is expected to read this address,
poke at the buffer using /dev/mem, and pass an address in the RMO buffer to
the RTAS call.
However, there's nothing stopping the caller from specifying whatever
address they want in the RTAS call, and it's easy to construct a series of
RTAS calls that can overwrite arbitrary bytes (even without /dev/mem
access).
Additionally, there are some RTAS calls that do potentially dangerous
things and for which there are no legitimate userspace use cases.
In the past, this would not have been a particularly big deal as it was
assumed that root could modify all system state freely, but with Secure
Boot and lockdown we need to care about this.
We can't fundamentally change the ABI at this point, however we can address
this by implementing a filter that checks RTAS calls against a list
of permitted calls and forces the caller to use addresses within the RMO
buffer.
The list is based off the list of calls that are used by the librtas
userspace library, and has been tested with a number of existing userspace
RTAS utilities. For compatibility with any applications we are not aware of
that require other calls, the filter can be turned off at build time.
Cc: stable@vger.kernel.org
Reported-by: Daniel Axtens <dja@axtens.net>
Signed-off-by: Andrew Donnellan <ajd@linux.ibm.com>
Signed-off-by: Michael Ellerman <mpe@ellerman.id.au>
Link: https://lore.kernel.org/r/20200820044512.7543-1-ajd@linux.ibm.com
2020-08-20 14:45:12 +10:00
|
|
|
|
return -EINVAL;
|
|
|
|
|
|
2023-02-10 12:42:08 -06:00
|
|
|
|
if (token_is_restricted_errinjct(token)) {
|
2022-09-26 08:16:43 -05:00
|
|
|
|
int err;
|
|
|
|
|
|
|
|
|
|
err = security_locked_down(LOCKDOWN_RTAS_ERROR_INJECTION);
|
|
|
|
|
if (err)
|
|
|
|
|
return err;
|
|
|
|
|
}
|
|
|
|
|
|
2006-01-13 18:39:24 -06:00
|
|
|
|
/* Need to handle ibm,suspend_me call specially */
|
2023-02-10 12:42:08 -06:00
|
|
|
|
if (token == rtas_function_token(RTAS_FN_IBM_SUSPEND_ME)) {
|
2015-01-21 13:32:00 +11:00
|
|
|
|
|
|
|
|
|
/*
|
2015-03-27 12:47:25 -07:00
|
|
|
|
* rtas_ibm_suspend_me assumes the streamid handle is in cpu
|
|
|
|
|
* endian, or at least the hcall within it requires it.
|
2015-01-21 13:32:00 +11:00
|
|
|
|
*/
|
2015-03-27 12:47:25 -07:00
|
|
|
|
int rc = 0;
|
2015-01-21 13:32:00 +11:00
|
|
|
|
u64 handle = ((u64)be32_to_cpu(args.args[0]) << 32)
|
|
|
|
|
| be32_to_cpu(args.args[1]);
|
2020-12-07 15:51:47 -06:00
|
|
|
|
rc = rtas_syscall_dispatch_ibm_suspend_me(handle);
|
2015-03-27 12:47:25 -07:00
|
|
|
|
if (rc == -EAGAIN)
|
|
|
|
|
args.rets[0] = cpu_to_be32(RTAS_NOT_SUSPENDABLE);
|
|
|
|
|
else if (rc == -EIO)
|
|
|
|
|
args.rets[0] = cpu_to_be32(-1);
|
|
|
|
|
else if (rc)
|
2006-01-13 18:39:24 -06:00
|
|
|
|
return rc;
|
|
|
|
|
goto copy_return;
|
|
|
|
|
}
|
|
|
|
|
|
2005-10-26 17:05:24 +10:00
|
|
|
|
buff_copy = get_errorlog_buffer();
|
2005-04-16 15:20:36 -07:00
|
|
|
|
|
powerpc/rtas: Facilitate high-level call sequences
On RTAS platforms there is a general restriction that the OS must not
enter RTAS on more than one CPU at a time. This low-level
serialization requirement is satisfied by holding a spin
lock (rtas_lock) across most RTAS function invocations.
However, some pseries RTAS functions require multiple successive calls
to complete a logical operation. Beginning a new call sequence for such a
function may disrupt any other sequences of that function already in
progress. Safe and reliable use of these functions effectively
requires higher-level serialization beyond what is already done at the
level of RTAS entry and exit.
Where a sequence-based RTAS function is invoked only through
sys_rtas(), with no in-kernel users, there is no issue as far as the
kernel is concerned. User space is responsible for appropriately
serializing its call sequences. (Whether user space code actually
takes measures to prevent sequence interleaving is another matter.)
Examples of such functions currently include ibm,platform-dump and
ibm,get-vpd.
But where a sequence-based RTAS function has both user space and
in-kernel uesrs, there is a hazard. Even if the in-kernel call sites
of such a function serialize their sequences correctly, a user of
sys_rtas() can invoke the same function at any time, potentially
disrupting a sequence in progress.
So in order to prevent disruption of kernel-based RTAS call sequences,
they must serialize not only with themselves but also with sys_rtas()
users, somehow. Preferably without adding more function-specific hacks
to sys_rtas(). This is a prerequisite for adding an in-kernel call
sequence of ibm,get-vpd, which is in a change to follow.
Note that it has never been feasible for the kernel to prevent
sys_rtas()-based sequences from being disrupted because control
returns to user space on every call. sys_rtas()-based users of these
functions have always been, and continue to be, responsible for
coordinating their call sequences with other users, even those which
may invoke the RTAS functions through less direct means than
sys_rtas(). This is an unavoidable consequence of exposing
sequence-based RTAS functions through sys_rtas().
* Add an optional mutex member to struct rtas_function.
* Statically define a mutex for each RTAS function with known call
sequence serialization requirements, and assign its address to the
.lock member of the corresponding function table entry, along with
justifying commentary.
* In sys_rtas(), if the table entry for the RTAS function being
called has a populated lock member, acquire it before taking
rtas_lock and entering RTAS.
* Kernel-based RTAS call sequences are expected to access the
appropriate mutex explicitly by name. For example, a user of the
ibm,activate-firmware RTAS function would do:
int token = rtas_function_token(RTAS_FN_IBM_ACTIVATE_FIRMWARE);
int fwrc;
mutex_lock(&rtas_ibm_activate_firmware_lock);
do {
fwrc = rtas_call(token, 0, 1, NULL);
} while (rtas_busy_delay(fwrc));
mutex_unlock(&rtas_ibm_activate_firmware_lock);
There should be no perceivable change introduced here except that
concurrent callers of the same RTAS function via sys_rtas() may block
on a mutex instead of spinning on rtas_lock.
Signed-off-by: Nathan Lynch <nathanl@linux.ibm.com>
Signed-off-by: Michael Ellerman <mpe@ellerman.id.au>
Link: https://msgid.link/20231212-papr-sys_rtas-vs-lockdown-v6-6-e9eafd0c8c6c@linux.ibm.com
2023-12-12 11:01:53 -06:00
|
|
|
|
/*
|
|
|
|
|
* If this function has a mutex assigned to it, we must
|
|
|
|
|
* acquire it to avoid interleaving with any kernel-based uses
|
|
|
|
|
* of the same function. Kernel-based sequences acquire the
|
|
|
|
|
* appropriate mutex explicitly.
|
|
|
|
|
*/
|
|
|
|
|
if (func->lock)
|
|
|
|
|
mutex_lock(func->lock);
|
|
|
|
|
|
2023-01-24 08:04:48 -06:00
|
|
|
|
raw_spin_lock_irqsave(&rtas_lock, flags);
|
2023-03-06 15:33:45 -06:00
|
|
|
|
cookie = lockdep_pin_lock(&rtas_lock);
|
2005-04-16 15:20:36 -07:00
|
|
|
|
|
2023-01-24 08:04:47 -06:00
|
|
|
|
rtas_args = args;
|
2023-02-10 12:41:57 -06:00
|
|
|
|
do_enter_rtas(&rtas_args);
|
2023-01-24 08:04:47 -06:00
|
|
|
|
args = rtas_args;
|
2005-04-16 15:20:36 -07:00
|
|
|
|
|
|
|
|
|
/* A -1 return code indicates that the last command couldn't
|
|
|
|
|
be completed due to a hardware error. */
|
2014-03-19 17:02:51 +01:00
|
|
|
|
if (be32_to_cpu(args.rets[0]) == -1)
|
2005-10-26 17:05:24 +10:00
|
|
|
|
errbuf = __fetch_rtas_last_error(buff_copy);
|
2005-04-16 15:20:36 -07:00
|
|
|
|
|
2023-03-06 15:33:45 -06:00
|
|
|
|
lockdep_unpin_lock(&rtas_lock, cookie);
|
2023-01-24 08:04:48 -06:00
|
|
|
|
raw_spin_unlock_irqrestore(&rtas_lock, flags);
|
2005-04-16 15:20:36 -07:00
|
|
|
|
|
powerpc/rtas: Facilitate high-level call sequences
On RTAS platforms there is a general restriction that the OS must not
enter RTAS on more than one CPU at a time. This low-level
serialization requirement is satisfied by holding a spin
lock (rtas_lock) across most RTAS function invocations.
However, some pseries RTAS functions require multiple successive calls
to complete a logical operation. Beginning a new call sequence for such a
function may disrupt any other sequences of that function already in
progress. Safe and reliable use of these functions effectively
requires higher-level serialization beyond what is already done at the
level of RTAS entry and exit.
Where a sequence-based RTAS function is invoked only through
sys_rtas(), with no in-kernel users, there is no issue as far as the
kernel is concerned. User space is responsible for appropriately
serializing its call sequences. (Whether user space code actually
takes measures to prevent sequence interleaving is another matter.)
Examples of such functions currently include ibm,platform-dump and
ibm,get-vpd.
But where a sequence-based RTAS function has both user space and
in-kernel uesrs, there is a hazard. Even if the in-kernel call sites
of such a function serialize their sequences correctly, a user of
sys_rtas() can invoke the same function at any time, potentially
disrupting a sequence in progress.
So in order to prevent disruption of kernel-based RTAS call sequences,
they must serialize not only with themselves but also with sys_rtas()
users, somehow. Preferably without adding more function-specific hacks
to sys_rtas(). This is a prerequisite for adding an in-kernel call
sequence of ibm,get-vpd, which is in a change to follow.
Note that it has never been feasible for the kernel to prevent
sys_rtas()-based sequences from being disrupted because control
returns to user space on every call. sys_rtas()-based users of these
functions have always been, and continue to be, responsible for
coordinating their call sequences with other users, even those which
may invoke the RTAS functions through less direct means than
sys_rtas(). This is an unavoidable consequence of exposing
sequence-based RTAS functions through sys_rtas().
* Add an optional mutex member to struct rtas_function.
* Statically define a mutex for each RTAS function with known call
sequence serialization requirements, and assign its address to the
.lock member of the corresponding function table entry, along with
justifying commentary.
* In sys_rtas(), if the table entry for the RTAS function being
called has a populated lock member, acquire it before taking
rtas_lock and entering RTAS.
* Kernel-based RTAS call sequences are expected to access the
appropriate mutex explicitly by name. For example, a user of the
ibm,activate-firmware RTAS function would do:
int token = rtas_function_token(RTAS_FN_IBM_ACTIVATE_FIRMWARE);
int fwrc;
mutex_lock(&rtas_ibm_activate_firmware_lock);
do {
fwrc = rtas_call(token, 0, 1, NULL);
} while (rtas_busy_delay(fwrc));
mutex_unlock(&rtas_ibm_activate_firmware_lock);
There should be no perceivable change introduced here except that
concurrent callers of the same RTAS function via sys_rtas() may block
on a mutex instead of spinning on rtas_lock.
Signed-off-by: Nathan Lynch <nathanl@linux.ibm.com>
Signed-off-by: Michael Ellerman <mpe@ellerman.id.au>
Link: https://msgid.link/20231212-papr-sys_rtas-vs-lockdown-v6-6-e9eafd0c8c6c@linux.ibm.com
2023-12-12 11:01:53 -06:00
|
|
|
|
if (func->lock)
|
|
|
|
|
mutex_unlock(func->lock);
|
|
|
|
|
|
2005-04-16 15:20:36 -07:00
|
|
|
|
if (buff_copy) {
|
2005-10-26 17:05:24 +10:00
|
|
|
|
if (errbuf)
|
|
|
|
|
log_error(errbuf, ERR_TYPE_RTAS_LOG, 0);
|
2005-04-16 15:20:36 -07:00
|
|
|
|
kfree(buff_copy);
|
|
|
|
|
}
|
|
|
|
|
|
2006-01-13 18:39:24 -06:00
|
|
|
|
copy_return:
|
2005-04-16 15:20:36 -07:00
|
|
|
|
/* Copy out args. */
|
|
|
|
|
if (copy_to_user(uargs->args + nargs,
|
|
|
|
|
args.args + nargs,
|
2014-03-19 17:02:51 +01:00
|
|
|
|
nret * sizeof(rtas_arg_t)) != 0)
|
2005-04-16 15:20:36 -07:00
|
|
|
|
return -EFAULT;
|
|
|
|
|
|
|
|
|
|
return 0;
|
|
|
|
|
}
|
|
|
|
|
|
powerpc/rtas: improve function information lookups
The core RTAS support code and its clients perform two types of lookup
for RTAS firmware function information.
First, mapping a known function name to a token. The typical use case
invokes rtas_token() to retrieve the token value to pass to
rtas_call(). rtas_token() relies on of_get_property(), which performs
a linear search of the /rtas node's property list under a lock with
IRQs disabled.
Second, and less common: given a token value, looking up some
information about the function. The primary example is the sys_rtas
filter path, which linearly scans a small table to match the token to
a rtas_filter struct. Another use case to come is RTAS entry/exit
tracepoints, which will require efficient lookup of function names
from token values. Currently there is no general API for this.
We need something much like the existing rtas_filters table, but more
general and organized to facilitate efficient lookups.
Introduce:
* A new rtas_function type, aggregating function name, token,
and filter. Other function characteristics could be added in the
future.
* An array of rtas_function, where each element corresponds to a known
RTAS function. All information in the table is static save the token
values, which are derived from the device tree at boot. The array is
sorted by function name to allow binary search.
* A named constant for each known RTAS function, used to index the
function array. These also will be used in a client-facing API to be
added later.
* An xarray that maps valid tokens to rtas_function objects.
Fold the existing rtas_filter table into the new rtas_function array,
with the appropriate adjustments to block_rtas_call(). Remove
now-redundant fields from struct rtas_filter. Preserve the function of
the CONFIG_CPU_BIG_ENDIAN guard in the current filter table by
introducing a per-function flag that is set for the function entries
related to pseries LPAR migration. These have never had working users
via sys_rtas on ppc64le; see commit de0f7349a0dd ("powerpc/rtas:
prevent suspend-related sys_rtas use on LE").
Convert rtas_token() to use a lockless binary search on the function
table. Fall back to the old behavior for lookups against names that
are not known to be RTAS functions, but issue a warning. rtas_token()
is for function names; it is not a general facility for accessing
arbitrary properties of the /rtas node. All known misuses of
rtas_token() have been converted to more appropriate of_ APIs in
preceding changes.
Signed-off-by: Nathan Lynch <nathanl@linux.ibm.com>
Signed-off-by: Michael Ellerman <mpe@ellerman.id.au>
Link: https://lore.kernel.org/r/20230125-b4-powerpc-rtas-queue-v3-8-26929c8cce78@linux.ibm.com
2023-02-10 12:41:56 -06:00
|
|
|
|
static void __init rtas_function_table_init(void)
|
|
|
|
|
{
|
|
|
|
|
struct property *prop;
|
|
|
|
|
|
|
|
|
|
for (size_t i = 0; i < ARRAY_SIZE(rtas_function_table); ++i) {
|
|
|
|
|
struct rtas_function *curr = &rtas_function_table[i];
|
|
|
|
|
struct rtas_function *prior;
|
|
|
|
|
int cmp;
|
|
|
|
|
|
|
|
|
|
curr->token = RTAS_UNKNOWN_SERVICE;
|
|
|
|
|
|
|
|
|
|
if (i == 0)
|
|
|
|
|
continue;
|
|
|
|
|
/*
|
|
|
|
|
* Ensure table is sorted correctly for binary search
|
|
|
|
|
* on function names.
|
|
|
|
|
*/
|
|
|
|
|
prior = &rtas_function_table[i - 1];
|
|
|
|
|
|
|
|
|
|
cmp = strcmp(prior->name, curr->name);
|
|
|
|
|
if (cmp < 0)
|
|
|
|
|
continue;
|
|
|
|
|
|
|
|
|
|
if (cmp == 0) {
|
|
|
|
|
pr_err("'%s' has duplicate function table entries\n",
|
|
|
|
|
curr->name);
|
|
|
|
|
} else {
|
|
|
|
|
pr_err("function table unsorted: '%s' wrongly precedes '%s'\n",
|
|
|
|
|
prior->name, curr->name);
|
|
|
|
|
}
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
for_each_property_of_node(rtas.dev, prop) {
|
|
|
|
|
struct rtas_function *func;
|
|
|
|
|
|
|
|
|
|
if (prop->length != sizeof(u32))
|
|
|
|
|
continue;
|
|
|
|
|
|
|
|
|
|
func = __rtas_name_to_function(prop->name);
|
|
|
|
|
if (!func)
|
|
|
|
|
continue;
|
|
|
|
|
|
|
|
|
|
func->token = be32_to_cpup((__be32 *)prop->value);
|
|
|
|
|
|
|
|
|
|
pr_debug("function %s has token %u\n", func->name, func->token);
|
|
|
|
|
}
|
|
|
|
|
}
|
|
|
|
|
|
2005-04-16 15:20:36 -07:00
|
|
|
|
/*
|
2014-09-17 22:15:34 +10:00
|
|
|
|
* Call early during boot, before mem init, to retrieve the RTAS
|
|
|
|
|
* information from the device-tree and allocate the RMO buffer for userland
|
2005-04-16 15:20:36 -07:00
|
|
|
|
* accesses.
|
|
|
|
|
*/
|
|
|
|
|
void __init rtas_initialize(void)
|
|
|
|
|
{
|
2005-10-26 17:05:24 +10:00
|
|
|
|
unsigned long rtas_region = RTAS_INSTANTIATE_MAX;
|
2017-01-24 09:49:53 +11:00
|
|
|
|
u32 base, size, entry;
|
|
|
|
|
int no_base, no_size, no_entry;
|
2005-10-26 17:05:24 +10:00
|
|
|
|
|
2005-04-16 15:20:36 -07:00
|
|
|
|
/* Get RTAS dev node and fill up our "rtas" structure with infos
|
|
|
|
|
* about it.
|
|
|
|
|
*/
|
|
|
|
|
rtas.dev = of_find_node_by_name(NULL, "rtas");
|
2005-10-26 17:05:24 +10:00
|
|
|
|
if (!rtas.dev)
|
|
|
|
|
return;
|
|
|
|
|
|
2017-01-24 09:49:53 +11:00
|
|
|
|
no_base = of_property_read_u32(rtas.dev, "linux,rtas-base", &base);
|
|
|
|
|
no_size = of_property_read_u32(rtas.dev, "rtas-size", &size);
|
|
|
|
|
if (no_base || no_size) {
|
2017-01-24 09:49:54 +11:00
|
|
|
|
of_node_put(rtas.dev);
|
2017-01-24 09:49:52 +11:00
|
|
|
|
rtas.dev = NULL;
|
|
|
|
|
return;
|
|
|
|
|
}
|
|
|
|
|
|
2017-01-24 09:49:53 +11:00
|
|
|
|
rtas.base = base;
|
|
|
|
|
rtas.size = size;
|
|
|
|
|
no_entry = of_property_read_u32(rtas.dev, "linux,rtas-entry", &entry);
|
|
|
|
|
rtas.entry = no_entry ? rtas.base : entry;
|
2017-01-24 09:49:52 +11:00
|
|
|
|
|
2022-11-18 09:07:44 -06:00
|
|
|
|
init_error_log_max();
|
|
|
|
|
|
powerpc/rtas: improve function information lookups
The core RTAS support code and its clients perform two types of lookup
for RTAS firmware function information.
First, mapping a known function name to a token. The typical use case
invokes rtas_token() to retrieve the token value to pass to
rtas_call(). rtas_token() relies on of_get_property(), which performs
a linear search of the /rtas node's property list under a lock with
IRQs disabled.
Second, and less common: given a token value, looking up some
information about the function. The primary example is the sys_rtas
filter path, which linearly scans a small table to match the token to
a rtas_filter struct. Another use case to come is RTAS entry/exit
tracepoints, which will require efficient lookup of function names
from token values. Currently there is no general API for this.
We need something much like the existing rtas_filters table, but more
general and organized to facilitate efficient lookups.
Introduce:
* A new rtas_function type, aggregating function name, token,
and filter. Other function characteristics could be added in the
future.
* An array of rtas_function, where each element corresponds to a known
RTAS function. All information in the table is static save the token
values, which are derived from the device tree at boot. The array is
sorted by function name to allow binary search.
* A named constant for each known RTAS function, used to index the
function array. These also will be used in a client-facing API to be
added later.
* An xarray that maps valid tokens to rtas_function objects.
Fold the existing rtas_filter table into the new rtas_function array,
with the appropriate adjustments to block_rtas_call(). Remove
now-redundant fields from struct rtas_filter. Preserve the function of
the CONFIG_CPU_BIG_ENDIAN guard in the current filter table by
introducing a per-function flag that is set for the function entries
related to pseries LPAR migration. These have never had working users
via sys_rtas on ppc64le; see commit de0f7349a0dd ("powerpc/rtas:
prevent suspend-related sys_rtas use on LE").
Convert rtas_token() to use a lockless binary search on the function
table. Fall back to the old behavior for lookups against names that
are not known to be RTAS functions, but issue a warning. rtas_token()
is for function names; it is not a general facility for accessing
arbitrary properties of the /rtas node. All known misuses of
rtas_token() have been converted to more appropriate of_ APIs in
preceding changes.
Signed-off-by: Nathan Lynch <nathanl@linux.ibm.com>
Signed-off-by: Michael Ellerman <mpe@ellerman.id.au>
Link: https://lore.kernel.org/r/20230125-b4-powerpc-rtas-queue-v3-8-26929c8cce78@linux.ibm.com
2023-02-10 12:41:56 -06:00
|
|
|
|
/* Must be called before any function token lookups */
|
|
|
|
|
rtas_function_table_init();
|
|
|
|
|
|
2022-11-18 09:07:41 -06:00
|
|
|
|
/*
|
2023-02-10 12:42:08 -06:00
|
|
|
|
* Discover this now to avoid a device tree lookup in the
|
2022-11-18 09:07:41 -06:00
|
|
|
|
* panic path.
|
|
|
|
|
*/
|
2023-02-10 12:42:08 -06:00
|
|
|
|
ibm_extended_os_term = of_property_read_bool(rtas.dev, "ibm,extended-os-term");
|
2022-11-18 09:07:41 -06:00
|
|
|
|
|
2005-04-16 15:20:36 -07:00
|
|
|
|
/* If RTAS was found, allocate the RMO buffer for it and look for
|
|
|
|
|
* the stop-self token if any
|
|
|
|
|
*/
|
2005-10-26 17:05:24 +10:00
|
|
|
|
#ifdef CONFIG_PPC64
|
2021-04-08 09:06:28 -05:00
|
|
|
|
if (firmware_has_feature(FW_FEATURE_LPAR))
|
2010-07-06 15:39:02 -07:00
|
|
|
|
rtas_region = min(ppc64_rma_size, RTAS_INSTANTIATE_MAX);
|
2005-10-26 17:05:24 +10:00
|
|
|
|
#endif
|
2021-04-08 09:06:30 -05:00
|
|
|
|
rtas_rmo_buf = memblock_phys_alloc_range(RTAS_USER_REGION_SIZE, PAGE_SIZE,
|
2019-03-11 23:29:35 -07:00
|
|
|
|
0, rtas_region);
|
|
|
|
|
if (!rtas_rmo_buf)
|
|
|
|
|
panic("ERROR: RTAS: Failed to allocate %lx bytes below %pa\n",
|
|
|
|
|
PAGE_SIZE, &rtas_region);
|
2005-04-16 15:20:36 -07:00
|
|
|
|
|
powerpc/pseries: add RTAS work area allocator
Various pseries-specific RTAS functions take a temporary "work area"
parameter - a buffer in memory accessible to RTAS. Typically such
functions are passed the statically allocated rtas_data_buf buffer as
the argument. This buffer is protected by a global spinlock. So users
of rtas_data_buf cannot perform sleeping operations while accessing
the buffer.
Most RTAS functions that have a work area parameter can return a
status (-2/990x) that indicates that the caller should retry. Before
retrying, the caller may need to reschedule or sleep (see
rtas_busy_delay() for details). This combination of factors
leads to uncomfortable constructions like this:
do {
spin_lock(&rtas_data_buf_lock);
rc = rtas_call(token, __pa(rtas_data_buf, ...);
if (rc == 0) {
/* parse or copy out rtas_data_buf contents */
}
spin_unlock(&rtas_data_buf_lock);
} while (rtas_busy_delay(rc));
Another unfortunately common way of handling this is for callers to
blithely ignore the possibility of a -2/990x status and hope for the
best.
If users were allowed to perform blocking operations while owning a
work area, the programming model would become less tedious and
error-prone. Users could schedule away, sleep, or perform other
blocking operations without having to release and re-acquire
resources.
We could continue to use a single work area buffer, and convert
rtas_data_buf_lock to a mutex. But that would impose an unnecessarily
coarse serialization on all users. As awkward as the current design
is, it prevents longer running operations that need to repeatedly use
rtas_data_buf from blocking the progress of others.
There are more considerations. One is that while 4KB is fine for all
current in-kernel uses, some RTAS calls can take much smaller buffers,
and some (VPD, platform dumps) would likely benefit from larger
ones. Another is that at least one RTAS function (ibm,get-vpd)
has *two* work area parameters. And finally, we should expect the
number of work area users in the kernel to increase over time as we
introduce lockdown-compatible ABIs to replace less safe use cases
based on sys_rtas/librtas.
So a special-purpose allocator for RTAS work area buffers seems worth
trying.
Properties:
* The backing memory for the allocator is reserved early in boot in
order to satisfy RTAS addressing requirements, and then managed with
genalloc.
* Allocations can block, but they never fail (mempool-like).
* Prioritizes first-come, first-serve fairness over throughput.
* Early boot allocations before the allocator has been initialized are
served via an internal static buffer.
Intended to replace rtas_data_buf. New code that needs RTAS work area
buffers should prefer this API.
Signed-off-by: Nathan Lynch <nathanl@linux.ibm.com>
Signed-off-by: Michael Ellerman <mpe@ellerman.id.au>
Link: https://lore.kernel.org/r/20230125-b4-powerpc-rtas-queue-v3-12-26929c8cce78@linux.ibm.com
2023-02-10 12:42:00 -06:00
|
|
|
|
rtas_work_area_reserve_arena(rtas_region);
|
2005-04-16 15:20:36 -07:00
|
|
|
|
}
|
2006-06-23 18:20:13 +10:00
|
|
|
|
|
|
|
|
|
int __init early_init_dt_scan_rtas(unsigned long node,
|
|
|
|
|
const char *uname, int depth, void *data)
|
|
|
|
|
{
|
2014-04-01 23:49:03 -05:00
|
|
|
|
const u32 *basep, *entryp, *sizep;
|
2006-06-23 18:20:13 +10:00
|
|
|
|
|
|
|
|
|
if (depth != 1 || strcmp(uname, "rtas") != 0)
|
|
|
|
|
return 0;
|
|
|
|
|
|
|
|
|
|
basep = of_get_flat_dt_prop(node, "linux,rtas-base", NULL);
|
|
|
|
|
entryp = of_get_flat_dt_prop(node, "linux,rtas-entry", NULL);
|
|
|
|
|
sizep = of_get_flat_dt_prop(node, "rtas-size", NULL);
|
|
|
|
|
|
2022-02-04 14:26:01 +05:30
|
|
|
|
#ifdef CONFIG_PPC64
|
|
|
|
|
/* need this feature to decide the crashkernel offset */
|
|
|
|
|
if (of_get_flat_dt_prop(node, "ibm,hypertas-functions", NULL))
|
|
|
|
|
powerpc_firmware_features |= FW_FEATURE_LPAR;
|
|
|
|
|
#endif
|
|
|
|
|
|
2006-06-23 18:20:13 +10:00
|
|
|
|
if (basep && entryp && sizep) {
|
|
|
|
|
rtas.base = *basep;
|
|
|
|
|
rtas.entry = *entryp;
|
|
|
|
|
rtas.size = *sizep;
|
|
|
|
|
}
|
|
|
|
|
|
2006-06-23 18:20:16 +10:00
|
|
|
|
#ifdef CONFIG_UDBG_RTAS_CONSOLE
|
|
|
|
|
basep = of_get_flat_dt_prop(node, "put-term-char", NULL);
|
|
|
|
|
if (basep)
|
|
|
|
|
rtas_putchar_token = *basep;
|
|
|
|
|
|
|
|
|
|
basep = of_get_flat_dt_prop(node, "get-term-char", NULL);
|
|
|
|
|
if (basep)
|
|
|
|
|
rtas_getchar_token = *basep;
|
2006-08-16 23:12:14 -05:00
|
|
|
|
|
|
|
|
|
if (rtas_putchar_token != RTAS_UNKNOWN_SERVICE &&
|
|
|
|
|
rtas_getchar_token != RTAS_UNKNOWN_SERVICE)
|
|
|
|
|
udbg_init_rtas_console();
|
|
|
|
|
|
2006-06-23 18:20:16 +10:00
|
|
|
|
#endif
|
|
|
|
|
|
2006-06-23 18:20:13 +10:00
|
|
|
|
/* break now */
|
|
|
|
|
return 1;
|
|
|
|
|
}
|
2009-06-16 16:42:50 +00:00
|
|
|
|
|
2023-01-24 08:04:48 -06:00
|
|
|
|
static DEFINE_RAW_SPINLOCK(timebase_lock);
|
2009-06-16 16:42:50 +00:00
|
|
|
|
static u64 timebase = 0;
|
|
|
|
|
|
2013-06-24 15:30:09 -04:00
|
|
|
|
void rtas_give_timebase(void)
|
2009-06-16 16:42:50 +00:00
|
|
|
|
{
|
|
|
|
|
unsigned long flags;
|
|
|
|
|
|
2023-01-24 08:04:48 -06:00
|
|
|
|
raw_spin_lock_irqsave(&timebase_lock, flags);
|
2009-06-16 16:42:50 +00:00
|
|
|
|
hard_irq_disable();
|
2023-02-10 12:42:08 -06:00
|
|
|
|
rtas_call(rtas_function_token(RTAS_FN_FREEZE_TIME_BASE), 0, 1, NULL);
|
2009-06-16 16:42:50 +00:00
|
|
|
|
timebase = get_tb();
|
2023-01-24 08:04:48 -06:00
|
|
|
|
raw_spin_unlock(&timebase_lock);
|
2009-06-16 16:42:50 +00:00
|
|
|
|
|
|
|
|
|
while (timebase)
|
|
|
|
|
barrier();
|
2023-02-10 12:42:08 -06:00
|
|
|
|
rtas_call(rtas_function_token(RTAS_FN_THAW_TIME_BASE), 0, 1, NULL);
|
2009-06-16 16:42:50 +00:00
|
|
|
|
local_irq_restore(flags);
|
|
|
|
|
}
|
|
|
|
|
|
2013-06-24 15:30:09 -04:00
|
|
|
|
void rtas_take_timebase(void)
|
2009-06-16 16:42:50 +00:00
|
|
|
|
{
|
|
|
|
|
while (!timebase)
|
|
|
|
|
barrier();
|
2023-01-24 08:04:48 -06:00
|
|
|
|
raw_spin_lock(&timebase_lock);
|
2009-06-16 16:42:50 +00:00
|
|
|
|
set_tb(timebase >> 32, timebase & 0xffffffff);
|
|
|
|
|
timebase = 0;
|
2023-01-24 08:04:48 -06:00
|
|
|
|
raw_spin_unlock(&timebase_lock);
|
2009-06-16 16:42:50 +00:00
|
|
|
|
}
|