linux.git/drivers/s390/crypto/ap_queue.c, branch for-next

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

s390/zcrypt: introduce new internal AP queue se_bound attribute

2023-10-16T11:04:09+00:00

This patch introduces a new AP queue internal attribute
se_bound which reflects the bound state of an APQN within
a Secure Execution environment.

With introduction of Secure Execution guests now an
AP firmware queue needs to be bound to the guest before
usage. This patch introduces a new internal attribute
reflecting this bound state and some glue code to handle
this new field during lifetime of an AP queue device.

Together with that now the zcrypt scheduler considers
the state of the AP queues when a message is about to be
distributed among the existing queues. There is a new
function ap_queue_usable() which returns true only when
all conditions for using this AP queue device are fulfilled.
In details this means: the AP queue needs to be configured,
not checkstopped and within an SE environment it needs
to be bound. So the new function gives and indication
if the AP queue device is ready to serve requests or not.

Signed-off-by: Harald Freudenberger 
Reviewed-by: Holger Dengler 
Signed-off-by: Vasily Gorbik