Add command line flags -i (read interval) and -l (loops) to
show the counter values for the specified number of iterations.
The CPUs to read the counter values from can be specified
on the command line. If none are specified, all online CPUs
are used.
For example the command '# lspai -l 2 -i 10 -t nnpa'
displays all PAI NNPA counter values two times with 10 second
interval.
Acked-by: Thomas Richter <tmricht@linux.ibm.com>
Reviewed-by: Thomas Richter <tmricht@linux.ibm.com>
Co-developed-by: Jan Polensky <japo@linux.ibm.com>
Signed-off-by: Thomas Richter <tmricht@linux.ibm.com>
Signed-off-by: Jan Höppner <hoeppner@linux.ibm.com>
Relocate remove_whitespace() from zdsfs to libutil/util_str.c, renaming
it to util_str_rm_whitespace() to make the helper available
project-wide.
Acked-by: Thomas Richter <tmricht@linux.ibm.com>
Reviewed-by: Jan Höppner <hoeppner@linux.ibm.com>
Signed-off-by: Jan Polensky <japo@linux.ibm.com>
Signed-off-by: Jan Höppner <hoeppner@linux.ibm.com>
Relocated the perf_event_open logic into a shared helper to eliminate
redundant implementations across multiple files. Enhances consistency,
reduces maintenance overhead, and lowers structural complexity.
Acked-by: Thomas Richter <tmricht@linux.ibm.com>
Reviewed-by: Thomas Richter <tmricht@linux.ibm.com>
Signed-off-by: Jan Polensky <japo@linux.ibm.com>
Signed-off-by: Jan Höppner <hoeppner@linux.ibm.com>
Fix a potential compile error when symbol
EKMF_SUPPORTS_RSA_PSS_CERTIFICATES is defined. With this symbol support
for RSA-PSS can be enabled for the EKMFWeb plugin. Currently this symbol
is never defined.
Fixes: c570f51f5f ("zkey-ekmfweb: Generate certificate or CSR with identity key")
Signed-off-by: Ingo Franzki <ifranzki@linux.ibm.com>
Reviewed-by: Finn Callies <fcallies@linux.ibm.com>
Signed-off-by: Steffen Eiden <seiden@linux.ibm.com>
Currently a certificate or certificate signing request generated by the
zkey EKMFWeb library erroneously always uses RSA-PSS as signing algorithm,
although EKMFWeb does not support RSA-PSS certificates in all versions.
This bug was introduced with the rework to use libseckey for secure
key crypto operations.
Fixes: 26c34a49b1 ("libekmfweb: Make use of the new libseckey")
Signed-off-by: Ingo Franzki <ifranzki@linux.ibm.com>
Reviewed-by: Finn Callies <fcallies@linux.ibm.com>
Signed-off-by: Steffen Eiden <seiden@linux.ibm.com>
Add support for '--image-key'. This new option can be used to select the
components encryption key (e.g. kernel, initrd, and kernel command
line). Previously, this was only available as an experimental
option ('--x-comp-key').
Reviewed-by: Hendrik Brueckner <brueckner@linux.ibm.com>
Reviewed-by: Steffen Eiden <seiden@linux.ibm.com>
Signed-off-by: Marc Hartmayer <mhartmay@linux.ibm.com>
Signed-off-by: Steffen Eiden <seiden@linux.ibm.com>
Normally, secure keys generated by zkey are intentionally export
restricted. Export restricted keys can not be wrapped with a key
encrypting key (KEK).
However, keys that are generated inside a Secure Execution for Linux
guest that shall also be used outside of the Secure Execution for Linux
guest can only be transported to outside the Secure Execution for Linux
guest by wrapping them with a KEK and unwrapping them outside of the
Secure Execution for Linux guest. For that such keys must be exportable.
Add an option to generate and import exportable secure keys, which then
can be wrapped, and thus transported to outside of a Secure Execution for
Linux guest.
This applies to keys of type 'CCA-AESCIPHER' and 'EP11-AES'. Keys of type
'CCA-AESDATA' are always exportable, and can not be export restricted.
For keys of type 'EP11-AES' additionally allow to set the
'wrap-with-trusted' attribute. This restricts the key so that it only can
be wrapped with a trusted key encrypting key.
For keys of type 'EP11-AES' to be exportable, the access control point
(ACP) XCP_CPB_ALLOW_COMBINED_EXTRACT must be 'ON' on all APQNs used. This
access control point is only supported on newer EP11 firmware levels. If
the access control point is 'OFF' or not supported by the EP11 firmware,
then the IOCTL to generate the key fails with a generic error
(Input/output error - EIO). The zkey tool prints an appropriate error
message in that case.
Signed-off-by: Ingo Franzki <ifranzki@linux.ibm.com>
Reviewed-by: Finn Callies <fcallies@linux.ibm.com>
Signed-off-by: Steffen Eiden <seiden@linux.ibm.com>
While parsing the rd.dasd kernel parameter, the dracut module
currently creates two separate udev rules for a single DASD — one
for ECKD type and one for FBA type. Because the kernel parameter
alone does not provide enough information to reliably determine the
DASD type, this dual configuration can lead to inconsistencies.
Update the logic to determine the DASD type dynamically by parsing
the modalias of available devices. If a device is not present during
boot, both udev rules will be generated.
Also add --no-module-load to the chzdev functions, because during this
time, we do not want chzdev to load the dasd module. The goal here is
to generate the right udev-rules only.
Suggested-by: Peter Oberparleiter <oberpar@linux.ibm.com>
Signed-off-by: Vineeth Vijayan <vneethv@linux.ibm.com>
Reviewed-by: Peter Oberparleiter <oberpar@linux.ibm.com>
Signed-off-by: Steffen Eiden <seiden@linux.ibm.com>
During autoconfig, DPM systems currently configures DASD devices twice:
once for dasd-eckd and once for dasd-fba. Because the firmware
configuration file does not provide the DASD type, this can lead
to inconsistent and redundant configurations.
For example, lszdev may show two devices with the same ID:
TYPE ID ON PERS NAMES
dasd-eckd 0.0.f001 yes auto dasda
dasd-fba 0.0.f001 no auto
However, only dasd-eckd is actually present on the machine, and
the dasd-fba entry is incorrect.
Modify this configuration logic to determine the DASD type dynamically
by parsing the modalias for each device-ID, and configures only the
correct dasd-type. The resulting lszdev output accurately reflects
the actual DASD devices present.
Signed-off-by: Vineeth Vijayan <vneethv@linux.ibm.com>
Reviewed-by: Peter Oberparleiter <oberpar@linux.ibm.com>
Signed-off-by: Steffen Eiden <seiden@linux.ibm.com>
When called with a device parameter, chzdev tries to load the kernel
module of the corresponding device type. This might not be desired in
certain situations like early initial RAM-disk processing.
To support this use cases, add a new command-line option
--no-module-load to prevent the loading of any kernel module by chzdev.
Suggested-by: Peter Oberparleiter <oberpar@linux.ibm.com>
Signed-off-by: Vineeth Vijayan <vneethv@linux.ibm.com>
Reviewed-by: Peter Oberparleiter <oberpar@linux.ibm.com>
Signed-off-by: Steffen Eiden <seiden@linux.ibm.com>
module_load_suppress() currently ignores the state parameter. Modify
it to respect the state parameter, so that the module load suppress
can be both enabled or disabled.
Signed-off-by: Vineeth Vijayan <vneethv@linux.ibm.com>
Reviewed-by: Peter Oberparleiter <oberpar@linux.ibm.com>
Signed-off-by: Steffen Eiden <seiden@linux.ibm.com>
The 'temp_area' buffer was not zeroed out for a retry in case of an
invalid input to select a boot menu entry.
Before:
zIPL v2.38.0-build-20250822 interactive boot menu
0. default (1TTTTTTTTTTTTTTTTTTTTTTTTTTTTTTTTTTTTTTTTTTTTTTTTTTTTTTTTTTTTTTT...
1. 1TTTTTTTTTTTTTTTTTTTTTTTTTTTTTTTTTTTTTTTTTTTTTTTTTTTTTTTTTTTTTTTTTTTTTTTT...
2. 2TTTTTTTTTTTTTTTTTTTTTTTTTTTTTTTTTTTTTTTTTTTTTTTTTTTTTTTTTTTTTTTTTTTTTTTT...
3. 3TTTTTTTTTTTTTTTTTTTTTTTTTTTTTTTTTTTTTTTTTTTTTTTTTTTTTTTTTTTTTTTTTTTTTTTT...
Note: VM users please use '#cp vi vmsg <input>'
Please choose (default will boot in 3 seconds):111
Error: undefined configuration
Please choose:1
Error: undefined configuration
After:
zIPL v2.38.0-build-20250822 interactive boot menu
0. default (1TTTTTTTTTTTTTTTTTTTTTTTTTTTTTTTTTTTTTTTTTTTTTTTTTTTTTTTTTTTTTTT...
1. 1TTTTTTTTTTTTTTTTTTTTTTTTTTTTTTTTTTTTTTTTTTTTTTTTTTTTTTTTTTTTTTTTTTTTTTTT...
2. 2TTTTTTTTTTTTTTTTTTTTTTTTTTTTTTTTTTTTTTTTTTTTTTTTTTTTTTTTTTTTTTTTTTTTTTTT...
3. 3TTTTTTTTTTTTTTTTTTTTTTTTTTTTTTTTTTTTTTTTTTTTTTTTTTTTTTTTTTTTTTTTTTTTTTTT...
Note: VM users please use '#cp vi vmsg <input>'
Please choose (default will boot in 3 seconds):111
Error: undefined configuration
Please choose:1
Booting 1TTTTTTTTTTTTTTTTTTTTTTTTTTTTTTTTTTTTTTTTTTTTTTTTTTTTTTTTTTTTTTTTTTTT...
Acked-by: Eduard Shishkin <edward6@linux.ibm.com>
Acked-by: Mikhail Zaslonko <zaslonko@linux.ibm.com>
Signed-off-by: Marc Hartmayer <mhartmay@linux.ibm.com>
Signed-off-by: Steffen Eiden <seiden@linux.ibm.com>
Fix a design mistake leading to IPL programs corruption.
Use a matrix of component ranges to locate the added components in the
body of bootmap file instead of an array.
Earlier an array of NR_PROGRAM_COMPONENTS was used, which is incorrect
Now a matrix of (NR_PROGRAM_COMPONENTS X BOOT_MENU_ENTRIES) is used.
Don't duplicate environment block for each menu entry. Instead, reuse
the one that was added when processing the first menu entry.
Tested-by: Alexander Egorenkov <egorenar@linux.ibm.com>
Reported-by: Alexander Egorenkov <egorenar@linux.ibm.com>
Signed-off-by: Eduard Shishkin <edward6@linux.ibm.com>
Signed-off-by: Steffen Eiden <seiden@linux.ibm.com>
Use exists and rename instead of renameat2 which is only available in the
linux implementation of libc. To enable compilation of pvsecret on macos
the rust wrapper function renameat2 which calls the libc renameat2 function
is replaced with rust native std::fs::exists ad std::fs::rename functions
because macos' implementation of libc does not have the renameat2 function.
Reviewed-by: Jan Höppner <hoeppner@linux.ibm.com>
Reviewed-by: Steffen Eiden <seiden@linux.ibm.com>
Signed-off-by: Finn Callies <fcallies@linux.ibm.com>
Signed-off-by: Steffen Eiden <seiden@linux.ibm.com>
Apply previously introduced generic infrastructure to add an
environment block as a "buffer component".
Signed-off-by: Eduard Shishkin <edward6@linux.ibm.com>
Reviewed-by: Stefan Haberland <sth@linux.ibm.com>
Signed-off-by: Steffen Eiden <seiden@linux.ibm.com>
Don't duplicate data of components added via add_component_buffer()
and friends to bootmap file. Instead, reuse data that were previously
added when preparing a program table for the first mirror to create
metadata (block lists, program tables, etc) specific for other mirrors.
Signed-off-by: Eduard Shishkin <edward6@linux.ibm.com>
Reviewed-by: Stefan Haberland <sth@linux.ibm.com>
Signed-off-by: Steffen Eiden <seiden@linux.ibm.com>
If the option '--add-files' is specified, don't duplicate data of
components added via add_component_file() and friends to bootmap
file for each mirror. Instead, reuse the data that were added when
preparing a program table for the first mirror to create metadata
(block lists, program tables, etc) specific for other mirrors.
Signed-off-by: Eduard Shishkin <edward6@linux.ibm.com>
Reviewed-by: Stefan Haberland <sth@linux.ibm.com>
Signed-off-by: Steffen Eiden <seiden@linux.ibm.com>
Drop limitations on identical target parameters of base disks per
logical device;
Fix verbose zipl output to include geometry of each mirror and
component load addresses that would be used when booting from each
mirror.
Signed-off-by: Eduard Shishkin <edward6@linux.ibm.com>
Reviewed-by: Stefan Haberland <sth@linux.ibm.com>
Signed-off-by: Steffen Eiden <seiden@linux.ibm.com>
Replace struct install_set with a new type containing multiple
program tables and program components. Refactor the code accordingly.
When retrieving device INFO, for each mirror complete a respective
structure disk_info in the INFO.BASE array.
When building a bootmap, for each mirror create a separate program
table (or a pair of tables in case of DASD - for CCW-TYPE IPL and
for LD-IPL), using respective components in the arrays INFO.BASE and
BIS.MIRRORS
Make data of program components added via get_component_buffer() and
get_component_file() be duplicated per each mirror.
Make boot record on each mirror point out to a respective program
table in the bootmap (when booting from different mirrors, different
program tables in the bootmap are used).
This patch doesn't make functional changes. However, test cases
comparing boot meta-data dumps of different mirrors may fail (since
boot records on different mirrors now refer different copies of boot
data). This will be fixed by the next patches in the series which
allow boot data to be reused.
Signed-off-by: Eduard Shishkin <edward6@linux.ibm.com>
Reviewed-by: Stefan Haberland <sth@linux.ibm.com>
Signed-off-by: Steffen Eiden <seiden@linux.ibm.com>
Replace struct disk_info with new 2 types.
Old type:
struct disk_info {
A; /* logical device info */
B; /* basedisk info */
};
New types:
struct disk_info {
B; /* basedisk info */
};
and
struct device_info {
A; /* logical device info */
struct disk_info C [MAX_TARGETS]; /* array of base disks */
};
Here A (logical device info) is the following:
dev_t device; /* logical device for bootmap creation */
char *name; /* name of logical device as reetrieved from
"/proc/partitions" */
char *drv_name; /* name of the driver managing the logical
device as retrieved from "/proc/devices",
or evaluated */
int fs_block_size;
Refactor the code respectively, to use only the first element of
the array C, so that this patch represents an equivalent transform.
Signed-off-by: Eduard Shishkin <edward6@linux.ibm.com>
Reviewed-by: Stefan Haberland <sth@linux.ibm.com>
Signed-off-by: Steffen Eiden <seiden@linux.ibm.com>
Add a man page note to clarify that BPS value scaling only applies to
human-readable output format.
Reviewed-by: Vineeth Vijayan <vneethv@linux.ibm.com>
Signed-off-by: Peter Oberparleiter <oberpar@linux.ibm.com>
Signed-off-by: Steffen Eiden <seiden@linux.ibm.com>
Add options to select power-of-two based IEC units such as KiB/s
(1024 B/s) for scaling throughput values in human readable reports.
Option Scaling factor
================================
--scale ki 1024
--scale mi 1048576
--scale gi 1073741824
--scale auto-iec IEC units
Reviewed-by: Jimmy Brisson <jbrisson@linux.ibm.com>
Reviewed-by: Vineeth Vijayan <vneethv@linux.ibm.com>
Signed-off-by: Peter Oberparleiter <oberpar@linux.ibm.com>
Signed-off-by: Steffen Eiden <seiden@linux.ibm.com>
chpstat uses power-of-two based IEC units such as KiB/s (1024 B/s) when
scaling throughput values in human readable reports. A user interpreting
these numbers can easily be confused by chpstat's default column header
("B/s") to assume that numbers are scaled using power-of-ten based SI
units such as kB/s (1000 B/s).
In addition, users that have worked with similar z/OS tooling to display
channel path activity are used to SI-based scaling, which increases the
chance of chpstat reports being misinterpreted.
To reduce this confusion, use SI units for throughput scaling:
Option Old factor New factor
==========================================
--scale k 1024 1000
--scale m 1048576 1000000
--scale g 1073741824 1000000000
--scale auto IEC units SI units
Note that machine-readable format produced via option --format is not
affected by scaling.
Reviewed-by: Jimmy Brison <jbrisson@linux.ibm.com>
Reviewed-by: Vineeth Vijayan <vneethv@linux.ibm.com>
Signed-off-by: Peter Oberparleiter <oberpar@linux.ibm.com>
Signed-off-by: Steffen Eiden <seiden@linux.ibm.com>
In tabular output, chpstat adds an additional space between columns
of different groups (e.g. between READ and WRITE data). Currently this
is done by increasing the column width of the first column in a group.
Depending on the value displayed in this first column of a group, the
spacing may vanish, and under certain circumstances, the precision of
auto-scaled *_PART columns may be higher than the precision of the
related *_TOTAL columns, resulting in a confusing view.
Example:
DPU READ(B/s) WRITE(B/s)
ID PART TOTAL PART TOTAL
6 10.7M 10.7M 10.8M 10.8M
6 0.00 11.3K 0.00 0.00
^^ ^^
Fix this by consistently adding padding between column groups without
increasing the column width of the first column of a group. Also ensure
the same width for *_PART and *_TOTAL columns.
Reviewed-by: Jimmy Brisson <jbrisson@linux.ibm.com>
Reviewed-by: Vineeth Vijayan <vneethv@linux.ibm.com>
Signed-off-by: Peter Oberparleiter <oberpar@linux.ibm.com>
Signed-off-by: Steffen Eiden <seiden@linux.ibm.com>
Fix segmentation fault when trying to process not supported dm-targets
Release allocated memory in error paths
Reviewed-by: Alexander Egorenkov <egorenar@linux.ibm.com>
Signed-off-by: Eduard Shishkin <edward6@linux.ibm.com>
Signed-off-by: Steffen Eiden <seiden@linux.ibm.com>
Use 'LDLIBS' to specify the libraries that the tool is linked against.
If it is specified as a dependency, the build system may attempt to
build it and fail.
Reviewed-by: Jan Höppner <hoeppner@linux.ibm.com>
Reviewed-by: Sumanth Korikkar <sumanthk@linux.ibm.com>
Signed-off-by: Marc Hartmayer <mhartmay@linux.ibm.com>
Signed-off-by: Jan Höppner <hoeppner@linux.ibm.com>
Match "chccwdev --online" example's description with its function
and improve "--safeoffline" example's wording.
Acked-by: Steffen Eiden <seiden@linux.ibm.com>
Signed-off-by: Mete Durlu <meted@linux.ibm.com>
Signed-off-by: Jan Höppner <hoeppner@linux.ibm.com>
Use 'PVIMG_PKGDATADIR' as it is used by the 'pvimg_pkg_data' macro rule.
The problem only shows up if someone changes 'PVIMG_PKGDATADIR' to
something different than the default.
Fixes: f4cf4ae6eb ("rust: Add a new tool called 'pvimg'")
Reviewed-by: Jan Höppner <hoeppner@linux.ibm.com>
Signed-off-by: Marc Hartmayer <mhartmay@linux.ibm.com>
Signed-off-by: Jan Höppner <hoeppner@linux.ibm.com>
The cpictl utility sends control-program identification data
from protected virtualization guests to hosts by default.
This behaviour leaks the below potentially sensitive
information to untrusted hosts.
- system_type
- system_level
- sysplex_name
- system_name
To prevent this behaviour, enhance the cpictl utility to stop
setting CPI information on protected virtualization guests by
default. If the user chooses to set the CPI information, it
could be set by one of the below options
- use the command line option --permit-cpi
- set the environment variable CPI_PERMIT_ON_PVGUEST to 1 to
control the CPI service behaviour during boot
Signed-off-by: Hendrik Brueckner <brueckner@linux.ibm.com>
Signed-off-by: Shalini Chellathurai Saroja <shalini@linux.ibm.com>
Reviewed-by: Jan Höppner <hoeppner@linux.ibm.com>
Reviewed-by: Peter Oberparleiter <oberpar@linux.ibm.com>
Reviewed-by: Hendrik Brueckner <brueckner@linux.ibm.com>
Signed-off-by: Jan Höppner <hoeppner@linux.ibm.com>
