get and set system parameters via /dev/lparctl #26
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Prefer the proposed /dev/lparctl interface for getting and setting system parameters. Fall back to /dev/mem and sys_rtas if /dev/lparctl isn't present or if the appropriate ioctl commands do not work. lparctl.h is copied directly from the proposed kernel change. Signed-off-by: Nathan Lynch <nathanl@linux.ibm.com>
nathanlynch
added a commit
to nathanlynch/linuxppc-ci
that referenced
this pull request
Jul 29, 2022
This adds a chardev+ioctl-based interface for user space to access pseries platform-specific functions which don't easily fit elsewhere. The immediate motivation is to unbreak librtas[1] with kernel lockdown enabled. librtas provides a thin root-only user-space API, allowing nearly direct access to RTAS functions. Since its inception, some of librtas's APIs have used /dev/mem to allocate buffers that are addressable by RTAS for use with the powerpc-specific rtas() syscall. This design likely would not be our first choice today, but it has served adequately for about two decades without much change, and librtas has a non-negligible number of existing users, including powerpc-utils, ppc64-diag, lsvpd, lscpu (util-linux), and several non-OSS programs. With lockdown enabled, /dev/mem access is prohibited, preventing communication with the management console and breaking associated functions such as DLPAR and partition migration. So the task is to provide new lockdown-compatible interfaces for librtas to prefer over the legacy /dev/mem+sys_rtas(), allowing it to maintain its own user-facing ABIs as much as possible. This means that we make different interface choices than we would were we writing everything from scratch. In the ioctl commands added here, we do not map RTAS error statuses to Linux errno values, because the existing users of librtas's system parameter APIs expect the RTAS status codes. Instead, the ioctl succeeds if the kernel manages to call the RTAS function at all, and passes the RTAS status back to user space in the argument buffer. Add the ability to retrieve and change system parameters as defined by PAPR. Along with proposed implementation changes to librtas[2], this effectively fixes librtas's rtas_get_sysparm() and rtas_set_sysparm() APIs for existing users with lockdown. This is enough to get HMC communication working via the proprietary RSCT stack, enabling LPM, processor DLPAR, memory DLPAR, and various other use cases. While this starts with RTAS-implemented functions, there's no reason it couldn't host facilities that rely on hcalls or other PAPR-specified interfaces. It could be an alternative to adding more key=value lines to /proc/powrpc/lparcfg. Hence the generic name 'lparctl'. Utilities tested (ppc64le kernel and user space): * ppc64_cpu --run-mode (powerpc-utils, gets/sets processor diag run mode) * serv_config (powerpc-utils, gets/sets various system and LPAR policies) * lscpu (util-linux, retrieves processor topology) * RSCT (proprietary, retrieves HMC connection details) Future work to unbreak more librtas APIs may include: * VPD retrieval via ibm,get-vpd * RTAS error injection * indicator query/manipulation for diagnostics [1] https://github.com/ibm-power-utilities/librtas [2] ibm-power-utilities/librtas#26
nathanlynch
added a commit
to nathanlynch/linuxppc-ci
that referenced
this pull request
Jul 29, 2022
This adds a chardev+ioctl-based interface for user space to access pseries platform-specific functions which don't easily fit elsewhere. The immediate motivation is to unbreak librtas[1] with kernel lockdown enabled. librtas provides a thin root-only user-space API, allowing nearly direct access to RTAS functions. Since its inception, some of librtas's APIs have used /dev/mem to allocate buffers that are addressable by RTAS for use with the powerpc-specific rtas() syscall. This design likely would not be our first choice today, but it has served adequately for about two decades without much change, and librtas has a non-negligible number of existing users, including powerpc-utils, ppc64-diag, lsvpd, lscpu (util-linux), and several non-OSS programs. With lockdown enabled, /dev/mem access is prohibited, preventing communication with the management console and breaking associated functions such as DLPAR and partition migration. So the task is to provide new lockdown-compatible interfaces for librtas to prefer over the legacy /dev/mem+sys_rtas(), allowing it to maintain its own user-facing ABIs as much as possible. This means that we make different interface choices than we would were we writing everything from scratch. In the ioctl commands added here, we do not map RTAS error statuses to Linux errno values, because the existing users of librtas's system parameter APIs expect the RTAS status codes. Instead, the ioctl succeeds if the kernel manages to call the RTAS function at all, and passes the RTAS status back to user space in the argument buffer. Add the ability to retrieve and change system parameters as defined by PAPR. Along with proposed implementation changes to librtas[2], this effectively fixes librtas's rtas_get_sysparm() and rtas_set_sysparm() APIs for existing users with lockdown. This is enough to get HMC communication working via the proprietary RSCT stack, enabling LPM, processor DLPAR, memory DLPAR, and various other use cases. While this starts with RTAS-implemented functions, there's no reason it couldn't host facilities that rely on hcalls or other PAPR-specified interfaces. It could be an alternative to adding more key=value lines to /proc/powrpc/lparcfg. Hence the generic name 'lparctl'. Utilities tested (ppc64le kernel and user space): * ppc64_cpu --run-mode (powerpc-utils, gets/sets processor diag run mode) * serv_config (powerpc-utils, gets/sets various system and LPAR policies) * lscpu (util-linux, retrieves processor topology) * RSCT (proprietary, retrieves HMC connection details) Future work to unbreak more librtas APIs may include: * VPD retrieval via ibm,get-vpd * RTAS error injection * indicator query/manipulation for diagnostics [1] https://github.com/ibm-power-utilities/librtas [2] ibm-power-utilities/librtas#26
nathanlynch
added a commit
to nathanlynch/linuxppc-ci
that referenced
this pull request
Jul 30, 2022
This adds a chardev+ioctl-based interface for user space to access pseries platform-specific functions which don't easily fit elsewhere. The immediate motivation is to unbreak librtas[1] with kernel lockdown enabled. librtas provides a thin root-only user-space API, allowing nearly direct access to RTAS functions. Since its inception, some of librtas's APIs have used /dev/mem to allocate buffers that are addressable by RTAS for use with the powerpc-specific rtas() syscall. This design likely would not be our first choice today, but it has served adequately for about two decades without much change, and librtas has a non-negligible number of existing users, including powerpc-utils, ppc64-diag, lsvpd, lscpu (util-linux), and several non-OSS programs. With lockdown enabled, /dev/mem access is prohibited, preventing communication with the management console and breaking associated functions such as DLPAR and partition migration. So the task is to provide new lockdown-compatible interfaces for librtas to prefer over the legacy /dev/mem+sys_rtas(), allowing it to maintain its own user-facing ABIs as much as possible. This means that we make different interface choices than we would were we writing everything from scratch. In the ioctl commands added here, we do not map RTAS error statuses to Linux errno values, because the existing users of librtas's system parameter APIs expect the RTAS status codes. Instead, the ioctl succeeds if the kernel manages to call the RTAS function at all, and passes the RTAS status back to user space in the argument buffer. Add the ability to retrieve and change system parameters as defined by PAPR. Along with proposed implementation changes to librtas[2], this effectively fixes librtas's rtas_get_sysparm() and rtas_set_sysparm() APIs for existing users with lockdown. This is enough to get HMC communication working via the proprietary RSCT stack, enabling LPM, processor DLPAR, memory DLPAR, and various other use cases. While this starts with RTAS-implemented functions, there's no reason it couldn't host facilities that rely on hcalls or other PAPR-specified interfaces. It could be an alternative to adding more key=value lines to /proc/powrpc/lparcfg. Hence the generic name 'lparctl'. Utilities tested (ppc64le kernel and user space): * ppc64_cpu --run-mode (powerpc-utils, gets/sets processor diag run mode) * serv_config (powerpc-utils, gets/sets various system and LPAR policies) * lscpu (util-linux, retrieves processor topology) * RSCT (proprietary, retrieves HMC connection details) Future work to unbreak more librtas APIs may include: * VPD retrieval via ibm,get-vpd * RTAS error injection * indicator query/manipulation for diagnostics [1] https://github.com/ibm-power-utilities/librtas [2] ibm-power-utilities/librtas#26 Signed-off-by: Nathan Lynch <nathanl@linux.ibm.com>
intel-lab-lkp
pushed a commit
to intel-lab-lkp/linux
that referenced
this pull request
Jul 30, 2022
This adds a chardev+ioctl-based interface for user space to access pseries platform-specific functions which don't easily fit elsewhere. The immediate motivation is to unbreak librtas[1] with kernel lockdown enabled. librtas provides a thin root-only user-space API, allowing nearly direct access to RTAS functions. Since its inception, some of librtas's APIs have used /dev/mem to allocate buffers that are addressable by RTAS for use with the powerpc-specific rtas() syscall. This design likely would not be our first choice today, but it has served adequately for about two decades without much change, and librtas has a non-negligible number of existing users, including powerpc-utils, ppc64-diag, lsvpd, lscpu (util-linux), and several non-OSS programs. With lockdown enabled, /dev/mem access is prohibited, preventing communication with the management console and breaking associated functions such as DLPAR and partition migration. So the task is to provide new lockdown-compatible interfaces for librtas to prefer over the legacy /dev/mem+sys_rtas(), allowing it to maintain its own user-facing ABIs as much as possible. This means that we make different interface choices than we would were we writing everything from scratch. In the ioctl commands added here, we do not map RTAS error statuses to Linux errno values, because the existing users of librtas's system parameter APIs expect the RTAS status codes. Instead, the ioctl succeeds if the kernel manages to call the RTAS function at all, and passes the RTAS status back to user space in the argument buffer. Add the ability to retrieve and change system parameters as defined by PAPR. Along with proposed implementation changes to librtas[2], this effectively fixes librtas's rtas_get_sysparm() and rtas_set_sysparm() APIs for existing users with lockdown. This is enough to get HMC communication working via the proprietary RSCT stack, enabling LPM, processor DLPAR, memory DLPAR, and various other use cases. While this starts with RTAS-implemented functions, there's no reason it couldn't host facilities that rely on hcalls or other PAPR-specified interfaces. It could be an alternative to adding more key=value lines to /proc/powrpc/lparcfg. Hence the generic name 'lparctl'. Utilities tested (ppc64le kernel and user space): * ppc64_cpu --run-mode (powerpc-utils, gets/sets processor diag run mode) * serv_config (powerpc-utils, gets/sets various system and LPAR policies) * lscpu (util-linux, retrieves processor topology) * RSCT (proprietary, retrieves HMC connection details) Future work to unbreak more librtas APIs may include: * VPD retrieval via ibm,get-vpd * RTAS error injection * indicator query/manipulation for diagnostics [1] https://github.com/ibm-power-utilities/librtas [2] ibm-power-utilities/librtas#26 Signed-off-by: Nathan Lynch <nathanl@linux.ibm.com>
ldu4
reviewed
Aug 1, 2022
Laurent Dufour points out that we can avoid a syscall by simply attempting the ioctl command with a real argument and falling back on error if errno is ENOENT or ENOIOCTLCMD. Signed-off-by: Nathan Lynch <nathanl@linux.ibm.com>
Somehow neglected to build the prior commit. ENOIOCTLCMD isn't exposed to user space; ENOTTY is the value we want to check for unimplemented commands. Signed-off-by: Nathan Lynch <nathanl@linux.ibm.com>
|
obsolete, closing. |
nathanlynch
added a commit
to nathanlynch/linuxppc-ci
that referenced
this pull request
May 20, 2023
This adds a chardev+ioctl-based interface for user space to access pseries platform-specific functions which don't easily fit elsewhere. The immediate motivation is to unbreak librtas[1] with kernel lockdown enabled. librtas provides a thin root-only user-space API, allowing nearly direct access to RTAS functions. Since its inception, some of librtas's APIs have used /dev/mem to allocate buffers that are addressable by RTAS for use with the powerpc-specific rtas() syscall. This design likely would not be our first choice today, but it has served adequately for about two decades without much change, and librtas has a non-negligible number of existing users, including powerpc-utils, ppc64-diag, lsvpd, lscpu (util-linux), and several non-OSS programs. With lockdown enabled, /dev/mem access is prohibited, preventing communication with the management console and breaking associated functions such as DLPAR and partition migration. So the task is to provide new lockdown-compatible interfaces for librtas to prefer over the legacy /dev/mem+sys_rtas(), allowing it to maintain its own user-facing ABIs as much as possible. This means that we make different interface choices than we would were we writing everything from scratch. In the ioctl commands added here, we do not map RTAS error statuses to Linux errno values, because the existing users of librtas's system parameter APIs expect the RTAS status codes. Instead, the ioctl succeeds if the kernel manages to call the RTAS function at all, and passes the RTAS status back to user space in the argument buffer. Add the ability to retrieve and change system parameters as defined by PAPR. Along with proposed implementation changes to librtas[2], this effectively fixes librtas's rtas_get_sysparm() and rtas_set_sysparm() APIs for existing users with lockdown. This is enough to get HMC communication working via the proprietary RSCT stack, enabling LPM, processor DLPAR, memory DLPAR, and various other use cases. While this starts with RTAS-implemented functions, there's no reason it couldn't host facilities that rely on hcalls or other PAPR-specified interfaces. It could be an alternative to adding more key=value lines to /proc/powrpc/lparcfg. Hence the generic name 'lparctl'. Utilities tested (ppc64le kernel and user space): * ppc64_cpu --run-mode (powerpc-utils, gets/sets processor diag run mode) * serv_config (powerpc-utils, gets/sets various system and LPAR policies) * lscpu (util-linux, retrieves processor topology) * RSCT (proprietary, retrieves HMC connection details) Future work to unbreak more librtas APIs may include: * VPD retrieval via ibm,get-vpd * RTAS error injection * indicator query/manipulation for diagnostics [1] https://github.com/ibm-power-utilities/librtas [2] ibm-power-utilities/librtas#26 Signed-off-by: Nathan Lynch <nathanl@linux.ibm.com>
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
Prefer the proposed /dev/lparctl interface for getting and setting system
parameters. Fall back to /dev/mem and sys_rtas if /dev/lparctl isn't
present or if the appropriate ioctl commands do not work.
lparctl.h is copied directly from the proposed kernel change:
https://lore.kernel.org/linuxppc-dev/20220730000458.130938-1-nathanl@linux.ibm.com/
Signed-off-by: Nathan Lynch nathanl@linux.ibm.com