summaryrefslogtreecommitdiffstats
path: root/drivers/s390
diff options
context:
space:
mode:
authorHarald Freudenberger <freude@linux.ibm.com>2023-10-26 09:33:31 +0200
committerVasily Gorbik <gor@linux.ibm.com>2023-11-05 22:34:57 +0100
commit5cf1a563a3284dc5c9f4ee8917ad2ebd51ff3def (patch)
tree4e9c380157eefcc3d2262da3c9a55694de2cda67 /drivers/s390
parents390/zcrypt: don't report online if card or queue is in check-stop state (diff)
downloadlinux-5cf1a563a3284dc5c9f4ee8917ad2ebd51ff3def.tar.xz
linux-5cf1a563a3284dc5c9f4ee8917ad2ebd51ff3def.zip
s390/ap: fix vanishing crypto cards in SE environment
A secure execution (SE, also known as confidential computing) guest may see asynchronous errors on a crypto firmware queue. The current implementation to gather information about cards and queues in ap_queue_info() simple returns if an asynchronous error is hanging on the firmware queue. If such a situation happened and it was the only queue visible for a crypto card within an SE guest, then the card vanished from sysfs as the AP bus scan function refuses to hold a card without any type information. As lszcrypt evaluates the sysfs such a card vanished from the lszcrypt card listing and the user is baffled and has no way to reset and thus clear the pending asynchronous error. This patch improves the named function to also evaluate GR2 of the TAPQ in case of asynchronous error pending. If there is a not-null value stored in, the info is processed now. In the end, a queue with pending asynchronous error does not lead to a vanishing card any more. Reviewed-by: Holger Dengler <dengler@linux.ibm.com> Signed-off-by: Harald Freudenberger <freude@linux.ibm.com> Signed-off-by: Vasily Gorbik <gor@linux.ibm.com>
Diffstat (limited to 'drivers/s390')
-rw-r--r--drivers/s390/crypto/ap_bus.c43
1 files changed, 20 insertions, 23 deletions
diff --git a/drivers/s390/crypto/ap_bus.c b/drivers/s390/crypto/ap_bus.c
index d6ad437883fa..5dd33155d5d5 100644
--- a/drivers/s390/crypto/ap_bus.c
+++ b/drivers/s390/crypto/ap_bus.c
@@ -352,7 +352,7 @@ EXPORT_SYMBOL(ap_test_config_ctrl_domain);
/*
* ap_queue_info(): Check and get AP queue info.
* Returns: 1 if APQN exists and info is filled,
- * 0 if APQN seems to exit but there is no info
+ * 0 if APQN seems to exist but there is no info
* available (eg. caused by an asynch pending error)
* -1 invalid APQN, TAPQ error or AP queue status which
* indicates there is no APQN.
@@ -373,36 +373,33 @@ static int ap_queue_info(ap_qid_t qid, int *q_type, unsigned int *q_fac,
/* call TAPQ on this APQN */
status = ap_test_queue(qid, ap_apft_available(), &tapq_info);
- /* handle pending async error with return 'no info available' */
- if (status.async)
- return 0;
-
switch (status.response_code) {
case AP_RESPONSE_NORMAL:
case AP_RESPONSE_RESET_IN_PROGRESS:
case AP_RESPONSE_DECONFIGURED:
case AP_RESPONSE_CHECKSTOPPED:
case AP_RESPONSE_BUSY:
- /*
- * According to the architecture in all these cases the
- * info should be filled. All bits 0 is not possible as
- * there is at least one of the mode bits set.
- */
- if (WARN_ON_ONCE(!tapq_info.value))
- return 0;
- *q_type = tapq_info.at;
- *q_fac = tapq_info.fac;
- *q_depth = tapq_info.qd;
- *q_ml = tapq_info.ml;
- *q_decfg = status.response_code == AP_RESPONSE_DECONFIGURED;
- *q_cstop = status.response_code == AP_RESPONSE_CHECKSTOPPED;
- return 1;
+ /* For all these RCs the tapq info should be available */
+ break;
default:
- /*
- * A response code which indicates, there is no info available.
- */
- return -1;
+ /* On a pending async error the info should be available */
+ if (!status.async)
+ return -1;
+ break;
}
+
+ /* There should be at least one of the mode bits set */
+ if (WARN_ON_ONCE(!tapq_info.value))
+ return 0;
+
+ *q_type = tapq_info.at;
+ *q_fac = tapq_info.fac;
+ *q_depth = tapq_info.qd;
+ *q_ml = tapq_info.ml;
+ *q_decfg = status.response_code == AP_RESPONSE_DECONFIGURED;
+ *q_cstop = status.response_code == AP_RESPONSE_CHECKSTOPPED;
+
+ return 1;
}
void ap_wait(enum ap_sm_wait wait)