kernel/linux.git/drivers/s390/crypto/ap_queue.c, branch v6.12.80

s390/ap: Fix wrong APQN fill calculation

2026-01-30T09:28:46+00:00

commit 3317785a8803db629efc759d811d0f589d3a0b2d upstream. The upper limit of the firmware queue fill state for each APQN is reported by the hwinfo.qd field. This field shows the numbers 0-7 for 1-8 queue spaces available. But the exploiting code assumed the real boundary is stored there and thus stoppes queuing in messages one tick too early. Correct the limit calculation and thus offer a boost of 12.5% performance for high traffic on one APQN. Fixes: d4c53ae8e4948 ("s390/ap: store TAPQ hwinfo in struct ap_card") Cc: stable@vger.kernel.org Reported-by: Ingo Franzki Reviewed-by: Ingo Franzki Signed-off-by: Harald Freudenberger Signed-off-by: Heiko Carstens Signed-off-by: Greg Kroah-Hartman

s390/ap: Fix CCA crypto card behavior within protected execution environment

2024-10-10T13:31:55+00:00

A crypto card comes in 3 flavors: accelerator, CCA co-processor or EP11 co-processor. Within a protected execution environment only the accelerator and EP11 co-processor is supported. However, it is possible to set up a KVM guest with a CCA card and run it as a protected execution guest. There is nothing at the host side which prevents this. Within such a guest, a CCA card is shown as "illicit" and you can't do anything with such a crypto card. Regardless of the unsupported CCA card within a protected execution guest there are a couple of user space applications which unconditional try to run crypto requests to the zcrypt device driver. There was a bug within the AP bus code which allowed such a request to be forwarded to a CCA card where it is finally rejected and the driver reacts with -ENODEV but also triggers an AP bus scan. Together with a retry loop this caused some kind of "hang" of the KVM guest. On startup it caused timeouts and finally led the KVM guest startup fail. Fix that by closing the gap and make sure a CCA card is not usable within a protected execution environment. Another behavior within an protected execution environment with CCA cards was that the se_bind and se_associate AP queue sysfs attributes where shown. The implementation unconditional always added these attributes. Fix that by checking if the card mode is supported within a protected execution environment and only if valid, add the attribute group. Signed-off-by: Harald Freudenberger Reviewed-by: Holger Dengler Signed-off-by: Heiko Carstens

s390/ap_queue: Cleanup debug code

2024-08-21T14:17:00+00:00

The dynamic debugging provides function names on request. So remove all explicit function strings. Reviewed-by: Harald Freudenberger Signed-off-by: Holger Dengler Signed-off-by: Vasily Gorbik

s390/ap: rename ap debug configuration option

2024-04-09T15:29:56+00:00

The configuration option ZCRYPT_DEBUG is used only in ap queue code, so rename it to AP_DEBUG. It also no longer depends on ZCRYPT but on AP. While at it, also update the help text. Signed-off-by: Holger Dengler Reviewed-by: Harald Freudenberger Signed-off-by: Alexander Gordeev

s390/ap: add debug possibility for AP messages

2024-02-16T13:30:13+00:00

This patch introduces two dynamic debug hexdump invocation possibilities to be able to a) dump an AP message immediately before it goes into the firmware queue and b) dump a fresh from the firmware queue received AP message. Signed-off-by: Harald Freudenberger Reviewed-by: Holger Dengler Signed-off-by: Heiko Carstens

s390/zcrypt: introduce dynamic debugging for AP and zcrypt code

2024-02-16T13:30:12+00:00

This patch replaces all the s390 debug feature calls with debug level by dynamic debug calls pr_debug. These calls are much more flexible and each single invocation can get enabled/disabled at runtime wheres the s390 debug feature debug calls have only one knob - enable or disable all in one bunch. The benefit is especially significant with high frequency called functions like the AP bus scan. In most debugging scenarios you don't want and need them, but sometimes it is crucial to know exactly when and how long the AP bus scan took. Signed-off-by: Harald Freudenberger Reviewed-by: Holger Dengler Signed-off-by: Heiko Carstens

s390/ap: handle outband SE bind state change

2023-11-30T15:24:23+00:00

This patch addresses some weird scenarios where an outband manipulation of the SE bind state of a queue assigned and maybe in use by an SE guest with AP pass-through support took place. So for example when the guest has bound and associated a queue and then this domain has been zeroed on the service element. Signed-off-by: Harald Freudenberger Reviewed-by: Holger Dengler Signed-off-by: Alexander Gordeev

s390/ap: store TAPQ hwinfo in struct ap_card

2023-11-30T15:24:23+00:00

As of now the AP card struct held only part of the queue's hwinfo (that is the GR2 register content returned with an TAPQ invocation). This patch reworks struct ap_card to hold the whole hwinfo now. As there is a nice bit field union on top of this ap_tapq_hwinfo struct, all the ugly bit checkings can now get replaced by simple evaluations of the required bit field. Suggested-by: Ingo Franzki Signed-off-by: Harald Freudenberger Reviewed-by: Holger Dengler Signed-off-by: Alexander Gordeev

s390/ap: re-enable interrupt for AP queues

2023-11-05T21:34:57+00:00

This patch introduces some code lines which check for interrupt support enabled on an AP queue after a reply has been received. This invocation has been chosen as there is a good chance to have the queue empty at that time. As the enablement of the irq imples a state machine change the queue should not have any pending requests or unreceived replies. Reviewed-by: Tony Krowiak Reviewed-by: Holger Dengler Signed-off-by: Harald Freudenberger Signed-off-by: Vasily Gorbik

s390/ap: rework to use irq info from ap queue status

2023-11-05T21:34:57+00:00

This patch reworks the irq handling and reporting code for the AP queue interrupt handling to always use the irq info from the queue status. Until now the interrupt status of an AP queue was stored into a bool variable within the ap_queue struct. This variable was set on a successful interrupt enablement and cleared with kicking a reset. However, it may be that the interrupt state is manipulated outband for example by a hypervisor. This patch removes this variable and instead the irq bit from the AP queue status which is always reflecting the current irq state is used. Reviewed-by: Tony Krowiak Reviewed-by: Holger Dengler Signed-off-by: Harald Freudenberger Signed-off-by: Vasily Gorbik