kata-containers/s390-tools
1
0
Fork 0
mirror of https://github.com/ibm-s390-linux/s390-tools.git synced 2026-08-05 02:14:52 +00:00
Code Issues Packages Projects Releases Wiki Activity

zcrypt: refine lszcrypt man page

Browse Source 
Added some explanations about the columns shown with the
lszcrypt verbose output.

Signed-off-by: Harald Freudenberger <freude@linux.ibm.com>
Signed-off-by: Jan Höppner <hoeppner@linux.ibm.com>
This commit is contained in:
Harald Freudenberger
2019-01-21 09:07:00 +01:00
committed by Jan Höppner
parent dffd41943e
commit e9c030f202
1 changed files with 63 additions and 1 deletions
Download Patch File Download Diff File Expand all files Collapse all files

64
zconf/zcrypt/lszcrypt.8
View File

@@ -10,7 +10,7 @@
.\" nroff -man lszcrypt.8
.\" to process this source
.\"
.TH LSZCRYPT 8 "OCT 2017" "s390-tools"
.TH LSZCRYPT 8 "JAN 2019" "s390-tools"
.SH NAME
lszcrypt \- display zcrypt device and configuration information
.SH SYNOPSIS
@@ -111,6 +111,68 @@ Displays help text and exits.
.TP 8
.B -v, --version
Displays version information and exits.
.SH VERBOSE LISTING DETAILS
Some of the columns showing up in verbose listing mode may need some
explanation:
.TP
.B TYPE and HWTYPE
The HWTYPE is a numeric value showing which type of hardware the zcrypt
device driver presumes that this crypto card is. The currently known values
are 7=CEX3C, 8=CEX3A, 10=CEX4, 11=CEX5 and 12=CEX6.
.br
The TYPE is a human readable value showing the hardware type and the basic
function type (A=Accelerator, C=CCA Coprocessor, P=EP11 Coprocessor). So
for example CEX6P means a CEX6 card in EP11 Coprocessor mode.
.TP
.B REQUESTS
This is the counter value of successful processed requests on card or queue
level. Successful here means the request was processed without any failure
in the whole processing chain.
.TP
.B PENDING
The underlying firmware and hardware layer usually provide some queuing
space for requests. When this queue is already filled up, the zcrypt device
driver maintains a software queue of pending requests. The sum of these
both values is displayed here and shows the amount of requests waiting for
processing on card or queue level.
.TP
.B FUNCTIONS
This column shows firmware and hardware function details:
.br
S - APSC available: card/queue can handle requests with the special bit
enabled.
.br
M - Accelerator card/queue with support for RSA ME with up to 4k key size.
.br
C - Accelerator card/queue with support for RSA CRT with up to 4k key size.
.br
D - Card/queue is providing CCA functions (this is the CCA Coprocessor mode).
.br
A - Card/queue is providing Accelerator functions (this is the Accelerator mode).
.br
X - Card/queue is providing EP11 functions (this is the EP11 Coprocessor mode).
.br
N - APXA available (ability to address more than 16 crypto cards and domains).
.br
F - Full function support (opposed to restricted function support, see below).
.br
R - Restricted function support. The F and R flag both reflect if a
hypervisor is somehow restricting this crypto resource in a virtual
environment. Dependent on the hypervisor configuration the crypto requests
may be filtered by the hypervisor to allow only a subset of functions
within the virtual runtime environment. For example a shared CCA
Coprocessor may be restricted by the hypervisor to allow only clear key
operations within the guests.
.TP
.B DRIVER
.br
Shows which card or queue device driver currently handles this crypto
resource. Currently known drivers are cex4card/cex4queue (CEX4-CEX6
hardware), cex2card/cex2cqueue (CEX2C and CEX3C hardware),
cex2acard/cex2aqueue (CEX2A and CEX3A hardware) and vfio_ap (queue reserved
for use by kvm hypervisor for kvm guests and not accessible to host
applications). It is also valid to have no driver handling a queue which is
shown as a -no-driver- entry.
.SH EXAMPLES
.TP
.B lszcrypt