kernel/linux.git/arch/powerpc/platforms/pseries/Makefile, branch linux-7.0.y

powerpc/pseries: move the PLPKS config inside its own sysfs directory

2026-01-30T03:57:26+00:00

The /sys/firmware/secvar/config directory represents Power LPAR Platform KeyStore (PLPKS) configuration properties such as max_object_size, signed_ update_algorithms, supported_policies, total_size, used_space, and version. These attributes describe the PLPKS, and not the secure boot variables (secvars). Create /sys/firmware/plpks directory and move the PLPKS config inside this directory. For backwards compatibility, create a soft link from the secvar sysfs directory to this config and emit a warning stating that the older sysfs path has been deprecated. Separate out the plpks specific documentation from secvar. Signed-off-by: Srish Srinivasan Tested-by: Nayna Jain Reviewed-by: Mimi Zohar Reviewed-by: Nayna Jain Signed-off-by: Madhavan Srinivasan Link: https://patch.msgid.link/20260127145228.48320-3-ssrish@linux.ibm.com

powerpc/pseries: Add papr-hvpipe char driver for HVPIPE interfaces

2025-09-15T08:08:40+00:00

The hypervisor provides ibm,send-hvpipe-msg and ibm,receive-hvpipe-msg RTAS calls which can be used by the partition to communicate through an inband hypervisor channel with different external sources such as Hardware Management Console (HMC). The information exchanged, whether it be messages, raw or formatted data, etc., is only known to between applications in the OS and the source (HMC). This patch adds papr-hvpipe character driver and provides the standard interfaces such as open / ioctl/ read / write to user space for exchanging information with HMC using send/recevive HVPIPE RTAS functions. PAPR (7.3.32 Hypervisor Pipe Information Exchange) defines the HVPIPE usage: - The hypervisor has one HVPIPE per partition for all sources. - OS can determine this feature’s availability by detecting the “ibm,hypervisor-pipe-capable” property in the /rtas node of the device tree. - Each source is represented by the source ID which is used in send / recv HVPIPE RTAS. (Ex: source ID is the target for the payload in send RTAS). - Return status of ibm,send-hvpipe-msg can be considered as delivered the payload. - Return status of ibm,receive-hvpipe-msg can be considered as ACK to source. - The hypervisor generates hvpipe message event interrupt when the partition has the payload to receive. Provide the interfaces to the user space with /dev/papr-hvpipe character device using the following programming model: int devfd = open("/dev/papr-hvpipe") int fd = ioctl(devfd, PAPR_HVPIPE_IOC_CREATE_HANDLE, &srcID); - Restrict the user space to use the same source ID and do not expect more than one process access with the same source. char *buf = malloc(size); - SIZE should be 4K and the buffer contains header and the payload. length = write(fd, buf, size); - OS issues ibm,send-hvpipe-msg RTAS and returns the RTAS status to the user space. ret = poll(fd,...) - The HVPIPE event message IRQ wakes up for any waiting FDs. length = read(fd, buf, size); - OS issues ibm,receive-hvpipe-msg to receive payload from the hypervisor. release(fd); - OS issues ibm,receive-hvpipe-msg if any payload is pending so that pipe is not blocked. The actual implementation of these calls are added in the next patches. Signed-off-by: Haren Myneni Tested-by: Shashank MS Reviewed-by: Mahesh Salgaonkar Reviewed-by: Tyrel Datwyler Signed-off-by: Madhavan Srinivasan Link: https://patch.msgid.link/20250909084402.1488456-4-haren@linux.ibm.com

powerpc/pseries: Add a char driver for physical-attestation RTAS

2025-04-17T06:12:30+00:00

The RTAS call ibm,physical-attestation is used to retrieve information about the trusted boot state of the firmware and hypervisor on the system, and also Trusted Platform Modules (TPM) data if the system is TCG 2.0 compliant. This RTAS interface expects the caller to define different command structs such as RetrieveTPMLog, RetrievePlatformCertificat and etc, in a work area with a maximum size of 4K bytes and the response buffer will be returned in the same work area. The current implementation of this RTAS function is in the user space but allocation of the work area is restricted with the system lockdown. So this patch implements this RTAS function in the kernel and expose to the user space with open/ioctl/read interfaces. PAPR (2.13+ 21.3 ibm,physical-attestation) defines RTAS function: - Pass the command struct to obtain the response buffer for the specific command. - This RTAS function is sequence RTAS call and has to issue RTAS call multiple times to get the complete response buffer (max 64K). The hypervisor expects the first RTAS call with the sequence 1 and the subsequent calls with the sequence number returned from the previous calls. Expose these interfaces to user space with a /dev/papr-physical-attestation character device using the following programming model: int devfd = open("/dev/papr-physical-attestation"); int fd = ioctl(devfd, PAPR_PHY_ATTEST_IOC_HANDLE, struct papr_phy_attest_io_block); - The user space defines the command struct and requests the response for any command. - Obtain the complete response buffer and returned the buffer as blob to the command specific FD. size = read(fd, buf, len); - Can retrieve the response buffer once or multiple times until the end of BLOB buffer. Implemented this new kernel ABI support in librtas library for system lockdown Signed-off-by: Haren Myneni Signed-off-by: Madhavan Srinivasan Link: https://patch.msgid.link/20250416225743.596462-8-haren@linux.ibm.com

powerpc/pseries: Add papr-platform-dump character driver for dump retrieval

2025-04-17T06:12:29+00:00

ibm,platform-dump RTAS call in combination with writable mapping /dev/mem is issued to collect platform dump from the hypervisor and may need multiple calls to get the complete dump. The current implementation uses rtas_platform_dump() API provided by librtas library to issue these RTAS calls. But /dev/mem access by the user space is prohibited under system lockdown. The solution should be to restrict access to RTAS function in user space and provide kernel interfaces to collect dump. This patch adds papr-platform-dump character driver and expose standard interfaces such as open / ioctl/ read to user space in ways that are compatible with lockdown. PAPR (7.3.3.4.1 ibm,platform-dump) provides a method to obtain the complete dump: - Each dump will be identified by ID called dump tag. - A sequence of RTAS calls have to be issued until retrieve the complete dump. The hypervisor expects the first RTAS call with the sequence 0 and the subsequent calls with the sequence number returned from the previous calls. - The hypervisor returns "dump complete" status once the complete dump is retrieved. But expects one more RTAS call from the partition with the NULL buffer to invalidate dump which means the dump will be removed in the hypervisor. - Sequence of calls are allowed with different dump IDs at the same time but not with the same dump ID. Expose these interfaces to user space with a /dev/papr-platform-dump character device using the following programming model: int devfd = open("/dev/papr-platform-dump", O_RDONLY); int fd = ioctl(devfd,PAPR_PLATFORM_DUMP_IOC_CREATE_HANDLE, &dump_id) - Restrict user space to access with the same dump ID. Typically we do not expect user space requests the dump again for the same dump ID. char *buf = malloc(size); length = read(fd, buf, size); - size should be minimum 1K based on PAPR and <= 4K based on RTAS work area size. It will be restrict to RTAS work area size. Using 4K work area based on the current implementation in librtas library - Each read call issue RTAS call to get the data based on the size requirement and returns bytes returned from the hypervisor - If the previous call returns dump complete status, the next read returns 0 like EOF. ret = ioctl(PAPR_PLATFORM_DUMP_IOC_INVALIDATE, &dump_id) - RTAS call with NULL buffer to invalidates the dump. The read API should use the file descriptor obtained from ioctl based on dump ID so that gets dump contents for the corresponding dump ID. Implemented support in librtas (rtas_platform_dump()) for this new ABI to support system lockdown. Signed-off-by: Haren Myneni Tested-by: Sathvika Vasireddy Signed-off-by: Madhavan Srinivasan Link: https://patch.msgid.link/20250416225743.596462-7-haren@linux.ibm.com

powerpc/pseries: Add papr-indices char driver for ibm,get-indices

2025-04-17T06:12:29+00:00

The RTAS call ibm,get-indices is used to obtain indices and location codes for a specified indicator or sensor token. The current implementation uses rtas_get_indices() API provided by librtas library which allocates RMO buffer and issue this RTAS call in the user space. But writable mapping /dev/mem access by the user space is prohibited under system lockdown. To overcome the restricted access in the user space, the kernel provide interfaces to collect indices data from the hypervisor. This patch adds papr-indices character driver and expose standard interfaces such as open / ioctl/ read to user space in ways that are compatible with lockdown. PAPR (2.13 7.3.17 ibm,get-indices RTAS Call) describes the following steps to retrieve all indices data: - User input parameters to the RTAS call: sensor or indicator, and indice type - ibm,get-indices is sequence RTAS call which means has to issue multiple times to get the entire list of indicators or sensors of a particular type. The hypervisor expects the first RTAS call with the sequence 1 and the subsequent calls with the sequence number returned from the previous calls. - The OS may not interleave calls to ibm,get-indices for different indicator or sensor types. Means other RTAS calls with different type should not be issued while the previous type sequence is in progress. So collect the entire list of indices and copied to buffer BLOB during ioctl() and expose this buffer to the user space with the file descriptor. - The hypervisor fills the work area with a specific format but does not return the number of bytes written to the buffer. Instead of parsing the data for each call to determine the data length, copy the work area size (RTAS_GET_INDICES_BUF_SIZE) to the buffer. Return work-area size of data to the user space for each read() call. Expose these interfaces to user space with a /dev/papr-indices character device using the following programming model: int devfd = open("/dev/papr-indices", O_RDONLY); int fd = ioctl(devfd, PAPR_INDICES_IOC_GET, struct papr_indices_io_block) - Collect all indices data for the specified token to the buffer char *buf = malloc(RTAS_GET_INDICES_BUF_SIZE); length = read(fd, buf, RTAS_GET_INDICES_BUF_SIZE) - RTAS_GET_INDICES_BUF_SIZE of data is returned to the user space. - The user space retrieves the indices and their location codes from the buffer - Should issue multiple read() calls until reaches the end of BLOB buffer. The read() should use the file descriptor obtained from ioctl to get the data that is exposed to file descriptor. Implemented support in librtas (rtas_get_indices()) for this new ABI for system lockdown. Signed-off-by: Haren Myneni Tested-by: Sathvika Vasireddy Signed-off-by: Madhavan Srinivasan Link: https://patch.msgid.link/20250416225743.596462-4-haren@linux.ibm.com

powerpc/pseries: Define common functions for RTAS sequence calls

2025-04-17T06:12:29+00:00

The RTAS call can be normal where retrieves the data form the hypervisor once or sequence based RTAS call which has to issue multiple times until the complete data is obtained. For some of these sequence RTAS calls, the OS should not interleave calls with different input until the sequence is completed. The data is collected for each call and copy to the buffer for the entire sequence during ioctl() handle and then expose this buffer to the user space with read() handle. One such sequence RTAS call is ibm,get-vpd and its support is already included in the current code. To add the similar support for other sequence based calls, move the common functions in to separate file and update papr_rtas_sequence struct with the following callbacks so that RTAS call specific code will be defined and executed to complete the sequence. struct papr_rtas_sequence { int error; void params; void (*begin) (struct papr_rtas_sequence *); void (*end) (struct papr_rtas_sequence *); const char * (*work) (struct papr_rtas_sequence *, size_t *); }; params: Input parameters used to pass for RTAS call. Begin: RTAS call specific function to initialize data including work area allocation. End: RTAS call specific function to free up resources (free work area) after the sequence is completed. Work: The actual RTAS call specific function which collects the data from the hypervisor. Signed-off-by: Haren Myneni Tested-by: Sathvika Vasireddy Signed-off-by: Madhavan Srinivasan Link: https://patch.msgid.link/20250416225743.596462-2-haren@linux.ibm.com

powerpc/pseries: Export hardware trace macro dump via debugfs

2025-02-11T06:05:45+00:00

This patch adds debugfs interface to export Hardware Trace Macro (HTM) function data in a LPAR. New hypervisor call "H_HTM" has been defined to setup, configure, control and dump the HTM data. This patch supports only dumping of HTM data in a LPAR. New debugfs folder called "htmdump" has been added under /sys/kernel/debug/arch path which contains files need to pass required parameters for the H_HTM dump function. New Kconfig option called "CONFIG_HTMDUMP" is added in platform/pseries for the same. With this module loaded, list of files in debugfs path /sys/kernel/debug/powerpc/htmdump coreindexonchip htmtype nodalchipindex nodeindex trace Signed-off-by: Abhishek Dubey Co-developed-by: Madhavan Srinivasan Reviewed-by: Athira Rajeev Signed-off-by: Madhavan Srinivasan Link: https://patch.msgid.link/20250113164039.302017-2-adubey@linux.ibm.com

powerpc/Makefile: Remove bits related to the previous use of -mcmodel=large

2024-05-07T13:48:45+00:00

All supported compilers today (gcc v5.1+ and clang v11+) have support for -mcmodel=medium. As such, NO_MINIMAL_TOC is no longer being set. Remove NO_MINIMAL_TOC as well as the fallback to -mminimal-toc. Reviewed-by: Christophe Leroy Signed-off-by: Naveen N Rao Signed-off-by: Michael Ellerman Link: https://msgid.link/20240110141237.3179199-1-naveen@kernel.org

powerpc/pseries: Add papr-vpd character driver for VPD retrieval

2023-12-13T10:38:21+00:00

PowerVM LPARs may retrieve Vital Product Data (VPD) for system components using the ibm,get-vpd RTAS function. We can expose this to user space with a /dev/papr-vpd character device, where the programming model is: struct papr_location_code plc = { .str = "", }; /* obtain all VPD */ int devfd = open("/dev/papr-vpd", O_RDONLY); int vpdfd = ioctl(devfd, PAPR_VPD_CREATE_HANDLE, &plc); size_t size = lseek(vpdfd, 0, SEEK_END); char *buf = malloc(size); pread(devfd, buf, size, 0); When a file descriptor is obtained from ioctl(PAPR_VPD_CREATE_HANDLE), the file contains the result of a complete ibm,get-vpd sequence. The file contents are immutable from the POV of user space. To get a new view of the VPD, the client must create a new handle. This design choice insulates user space from most of the complexities that ibm,get-vpd brings: * ibm,get-vpd must be called more than once to obtain complete results. * Only one ibm,get-vpd call sequence should be in progress at a time; interleaved sequences will disrupt each other. Callers must have a protocol for serializing their use of the function. * A call sequence in progress may receive a "VPD changed, try again" status, requiring the client to abandon the sequence and start over. The memory required for the VPD buffers seems acceptable, around 20KB for all VPD on one of my systems. And the value of the /rtas/ibm,vpd-size DT property (the estimated maximum size of VPD) is consistently 300KB across various systems I've checked. I've implemented support for this new ABI in the rtas_get_vpd() function in librtas, which the vpdupdate command currently uses to populate its VPD database. I've verified that an unmodified vpdupdate binary generates an identical database when using a librtas.so that prefers the new ABI. Along with the papr-vpd.h header exposed to user space, this introduces a common papr-miscdev.h uapi header to share a base ioctl ID with similar drivers to come. Tested-by: Michal Suchánek Signed-off-by: Nathan Lynch Signed-off-by: Michael Ellerman Link: https://msgid.link/20231212-papr-sys_rtas-vs-lockdown-v6-9-e9eafd0c8c6c@linux.ibm.com

powerpc/pseries: PLPKS SED Opal keystore support

2023-10-17T15:10:06+00:00

Define operations for SED Opal to read/write keys from POWER LPAR Platform KeyStore(PLPKS). This allows non-volatile storage of SED Opal keys. Signed-off-by: Greg Joyce Reviewed-by: Jonathan Derrick Link: https://lore.kernel.org/r/20231004201957.1451669-4-gjoyce@linux.vnet.ibm.com Signed-off-by: Jens Axboe