Re: [PATCH v4 01/15] s390: zcrypt: externalize AP instructions available function

From: Tony Krowiak
Date: Tue Apr 17 2018 - 14:15:03 EST

On 04/17/2018 12:56 PM, Cornelia Huck wrote:
On Tue, 17 Apr 2018 09:31:00 -0400
Tony Krowiak <akrowiak@xxxxxxxxxxxxxxxxxx> wrote:

My preference would be one of the following:

1. All of the interfaces defined in arch/s390/include/asm/ap.h
are implemented in a file that is built whether ZCRYPT is
built or not.

2. The drivers/s390/crypto/ap_asm.h file containing the functions
that execute the AP instructions are made available outside of
the AP bus, for example; arch/s390/include/asm

I requested this from the maintainer but was told we don't want to
have any crypto adapter support when the host AP functionality is
disabled (CONFIG_ZCRYPT=n). This makes sense, however; I think it is
a bit confusing to have a header file (arch/s390/include/asm/ap.h)
with interfaces that are conditionally built.

This is why I chose the ifdeffery (as you call it) approach. The
only other solution I can conjure is to duplicate the asm code for
the AP instructions needed in KVM and bypass using the AP bus
I think at the root of this is an unfortunate mixup in the
architecture: The format of the crycb changes depending on some ap
feature being installed. Providing the crycb does not have anything to
do with ap device usage in the host, but we need to issue an ap
instruction to get this right. [Correct me if I'm wrong; but that's
what I get without being able to consult the actual architecture.]

That sums it up.

So, exporting *all* of the interfaces is probably not needed anyway. I
think it boils down to either "export the interfaces where a mixup
happened, and keep the rest to zcrypt only", or "duplicate the
instructions for kvm usage".

I only suggested exporting all of the interfaces because the others may
be needed down the road when interception is implemented for full
virtualization of AP devices.

I hope we can find a solution here, as this seems to be one of the main
discussion points :/ (FWIW, I think the basic driver interface is sane.)

I will work on coming up with something that attempts to take into consideration
all of the comments thus far. In the meantime, I will keep my eyes on this
space if anybody comes up with a better, concrete resolution.