linux/drivers/s390/crypto/zcrypt_error.h
Harald Freudenberger e0332629e3 s390/ap/zcrypt: revisit ap and zcrypt error handling
Revisit the ap queue error handling: Based on discussions and
evaluatios with the firmware folk here is now a rework of the response
code handling for all the AP instructions. The idea is to distinguish
between failures because of some kind of invalid request where a retry
does not make any sense and a failure where another attempt to send
the very same request may succeed. The first case is handled by
returning EINVAL to the userspace application. The second case results
in retries within the zcrypt API controlled by a per message retry
counter.

Revisit the zcrpyt error handling: Similar here, based on discussions
with the firmware people here comes a rework of the handling of all
the reply codes.  Main point here is that there are only very few
cases left, where a zcrypt device queue is switched to offline. It
should never be the case that an AP reply message is 'unknown' to the
device driver as it indicates a total mismatch between device driver
and crypto card firmware. In all other cases, the code distinguishes
between failure because of invalid message (see above - EINVAL) or
failures of the infrastructure (see above - EAGAIN).

Signed-off-by: Harald Freudenberger <freude@linux.ibm.com>
Signed-off-by: Vasily Gorbik <gor@linux.ibm.com>
2020-10-07 21:50:01 +02:00

140 lines
4.8 KiB
C

/* SPDX-License-Identifier: GPL-2.0+ */
/*
* Copyright IBM Corp. 2001, 2006
* Author(s): Robert Burroughs
* Eric Rossman (edrossma@us.ibm.com)
*
* Hotplug & misc device support: Jochen Roehrig (roehrig@de.ibm.com)
* Major cleanup & driver split: Martin Schwidefsky <schwidefsky@de.ibm.com>
*/
#ifndef _ZCRYPT_ERROR_H_
#define _ZCRYPT_ERROR_H_
#include <linux/atomic.h>
#include "zcrypt_debug.h"
#include "zcrypt_api.h"
#include "zcrypt_msgtype6.h"
/**
* Reply Messages
*
* Error reply messages are of two types:
* 82: Error (see below)
* 88: Error (see below)
* Both type 82 and type 88 have the same structure in the header.
*
* Request reply messages are of three known types:
* 80: Reply from a Type 50 Request (see CEX2A-RELATED STRUCTS)
* 84: Reply from a Type 4 Request (see PCICA-RELATED STRUCTS)
* 86: Reply from a Type 6 Request (see PCICC/PCIXCC/CEX2C-RELATED STRUCTS)
*
*/
struct error_hdr {
unsigned char reserved1; /* 0x00 */
unsigned char type; /* 0x82 or 0x88 */
unsigned char reserved2[2]; /* 0x0000 */
unsigned char reply_code; /* reply code */
unsigned char reserved3[3]; /* 0x000000 */
};
#define TYPE82_RSP_CODE 0x82
#define TYPE88_RSP_CODE 0x88
#define REP82_ERROR_MACHINE_FAILURE 0x10
#define REP82_ERROR_PREEMPT_FAILURE 0x12
#define REP82_ERROR_CHECKPT_FAILURE 0x14
#define REP82_ERROR_MESSAGE_TYPE 0x20
#define REP82_ERROR_INVALID_COMM_CD 0x21 /* Type 84 */
#define REP82_ERROR_INVALID_MSG_LEN 0x23
#define REP82_ERROR_RESERVD_FIELD 0x24 /* was 0x50 */
#define REP82_ERROR_FORMAT_FIELD 0x29
#define REP82_ERROR_INVALID_COMMAND 0x30
#define REP82_ERROR_MALFORMED_MSG 0x40
#define REP82_ERROR_INVALID_SPECIAL_CMD 0x41
#define REP82_ERROR_RESERVED_FIELDO 0x50 /* old value */
#define REP82_ERROR_WORD_ALIGNMENT 0x60
#define REP82_ERROR_MESSAGE_LENGTH 0x80
#define REP82_ERROR_OPERAND_INVALID 0x82
#define REP82_ERROR_OPERAND_SIZE 0x84
#define REP82_ERROR_EVEN_MOD_IN_OPND 0x85
#define REP82_ERROR_RESERVED_FIELD 0x88
#define REP82_ERROR_INVALID_DOMAIN_PENDING 0x8A
#define REP82_ERROR_FILTERED_BY_HYPERVISOR 0x8B
#define REP82_ERROR_TRANSPORT_FAIL 0x90
#define REP82_ERROR_PACKET_TRUNCATED 0xA0
#define REP82_ERROR_ZERO_BUFFER_LEN 0xB0
#define REP88_ERROR_MODULE_FAILURE 0x10
#define REP88_ERROR_MESSAGE_TYPE 0x20
#define REP88_ERROR_MESSAGE_MALFORMD 0x22
#define REP88_ERROR_MESSAGE_LENGTH 0x23
#define REP88_ERROR_RESERVED_FIELD 0x24
#define REP88_ERROR_KEY_TYPE 0x34
#define REP88_ERROR_INVALID_KEY 0x82 /* CEX2A */
#define REP88_ERROR_OPERAND 0x84 /* CEX2A */
#define REP88_ERROR_OPERAND_EVEN_MOD 0x85 /* CEX2A */
static inline int convert_error(struct zcrypt_queue *zq,
struct ap_message *reply)
{
struct error_hdr *ehdr = reply->msg;
int card = AP_QID_CARD(zq->queue->qid);
int queue = AP_QID_QUEUE(zq->queue->qid);
switch (ehdr->reply_code) {
case REP82_ERROR_INVALID_MSG_LEN: /* 0x23 */
case REP82_ERROR_RESERVD_FIELD: /* 0x24 */
case REP82_ERROR_FORMAT_FIELD: /* 0x29 */
case REP82_ERROR_MALFORMED_MSG: /* 0x40 */
case REP82_ERROR_INVALID_SPECIAL_CMD: /* 0x41 */
case REP82_ERROR_MESSAGE_LENGTH: /* 0x80 */
case REP82_ERROR_OPERAND_INVALID: /* 0x82 */
case REP82_ERROR_OPERAND_SIZE: /* 0x84 */
case REP82_ERROR_EVEN_MOD_IN_OPND: /* 0x85 */
case REP82_ERROR_INVALID_DOMAIN_PENDING: /* 0x8A */
case REP82_ERROR_FILTERED_BY_HYPERVISOR: /* 0x8B */
case REP82_ERROR_PACKET_TRUNCATED: /* 0xA0 */
case REP88_ERROR_MESSAGE_MALFORMD: /* 0x22 */
case REP88_ERROR_KEY_TYPE: /* 0x34 */
/* RY indicates malformed request */
ZCRYPT_DBF(DBF_WARN,
"dev=%02x.%04x RY=0x%02x => rc=EINVAL\n",
card, queue, ehdr->reply_code);
return -EINVAL;
case REP82_ERROR_MACHINE_FAILURE: /* 0x10 */
case REP82_ERROR_MESSAGE_TYPE: /* 0x20 */
case REP82_ERROR_TRANSPORT_FAIL: /* 0x90 */
/*
* Msg to wrong type or card/infrastructure failure.
* Trigger rescan of the ap bus, trigger retry request.
*/
atomic_set(&zcrypt_rescan_req, 1);
/* For type 86 response show the apfs value (failure reason) */
if (ehdr->reply_code == REP82_ERROR_TRANSPORT_FAIL &&
ehdr->type == TYPE86_RSP_CODE) {
struct {
struct type86_hdr hdr;
struct type86_fmt2_ext fmt2;
} __packed * head = reply->msg;
unsigned int apfs = *((u32 *)head->fmt2.apfs);
ZCRYPT_DBF(DBF_WARN,
"dev=%02x.%04x RY=0x%02x apfs=0x%x => bus rescan, rc=EAGAIN\n",
card, queue, ehdr->reply_code, apfs);
} else
ZCRYPT_DBF(DBF_WARN,
"dev=%02x.%04x RY=0x%02x => bus rescan, rc=EAGAIN\n",
card, queue, ehdr->reply_code);
return -EAGAIN;
default:
/* Assume request is valid and a retry will be worth it */
ZCRYPT_DBF(DBF_WARN,
"dev=%02x.%04x RY=0x%02x => rc=EAGAIN\n",
card, queue, ehdr->reply_code);
return -EAGAIN;
}
}
#endif /* _ZCRYPT_ERROR_H_ */