Received: by 10.192.165.156 with SMTP id m28csp276174imm; Tue, 17 Apr 2018 09:58:34 -0700 (PDT) X-Google-Smtp-Source: AIpwx48SuSrUQ5Wfyz5dPJkx0zwKOaXxXhlyN1NsTf4KIlzcta0QZUh19lOn+bMafsH8YWhrhro2 X-Received: by 10.99.172.26 with SMTP id v26mr2449398pge.105.1523984314318; Tue, 17 Apr 2018 09:58:34 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1523984314; cv=none; d=google.com; s=arc-20160816; b=S+yIim6qcjFu9WCeD1PRbnDWrfcBmASlZM+Vy8vaad56RZzIEns2PsaJJSs8I6vOod JPm/HkqswnH57D0kDWZ3k+JE8PGbyZGjF5hRIxM1ed+0ddbHqXIlDBTSMts0oJRASYn1 qLxSpMqeMAn16BFIhCENt35XX/DUNVea8yAF6yTjDwk+2LP7XXhWCq9smYb/RQ/qQ60H YkhDkuFcohXz5Ir+QFF1YKD1TjygqphoHyRfFO72NEbBt7y/L7niTObEzQ8mVS8M0B6n yp2O02aHZdfXdCFQxHBb6XKLw9ngnaMZcqg6qJWgLh4Ews3dQjy+iD0n90DFQ7uvjV53 NfZA== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:content-transfer-encoding:mime-version :organization:references:in-reply-to:message-id:subject:cc:to:from :date:arc-authentication-results; bh=9bKfO2yaHqBvcoNn0d9O/X3ZCM81UBE49Ig3OunC0o4=; b=O4GvQ4hVTBQOakJ6PcrkumpO1RXHGNZNy/s+g7BKpztvi6r+G1aMmUu/cf1VNQkk2Q uno1kSWU29LE0w7VabRQakgBM06443+PkDj3LaguzIao6RL1ctFfdxlW4snXo7+7o+6Y lieLWpZY9WmmVLtYR0EqFlfnzjFiK1SOuPQEEFJ26lKgkFpwwunlIdebORGMr+qz8uhJ 430nJ93W7y1hGCbQBJMv33jvkDqtIEQCGyKnqJQmI/P7kWyzvVUhvBvST5LGqGnB3AiI fvUyA7Uf8axvVEFhj1Ki/loVzNeh1B/l3dKEa55H3iNl2YUzhQ/8et/k0LnQwI9vkdDg TuJQ== ARC-Authentication-Results: i=1; mx.google.com; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=fail (p=NONE sp=NONE dis=NONE) header.from=redhat.com Return-Path: Received: from vger.kernel.org (vger.kernel.org. [209.132.180.67]) by mx.google.com with ESMTP id f5si503696pgq.682.2018.04.17.09.58.20; Tue, 17 Apr 2018 09:58:34 -0700 (PDT) Received-SPF: pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) client-ip=209.132.180.67; Authentication-Results: mx.google.com; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=fail (p=NONE sp=NONE dis=NONE) header.from=redhat.com Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1754395AbeDQQ4y (ORCPT + 99 others); Tue, 17 Apr 2018 12:56:54 -0400 Received: from mx3-rdu2.redhat.com ([66.187.233.73]:57068 "EHLO mx1.redhat.com" rhost-flags-OK-OK-OK-FAIL) by vger.kernel.org with ESMTP id S1754216AbeDQQ4v (ORCPT ); Tue, 17 Apr 2018 12:56:51 -0400 Received: from smtp.corp.redhat.com (int-mx04.intmail.prod.int.rdu2.redhat.com [10.11.54.4]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by mx1.redhat.com (Postfix) with ESMTPS id DBD6281A88C4; Tue, 17 Apr 2018 16:56:50 +0000 (UTC) Received: from gondolin (dhcp-192-222.str.redhat.com [10.33.192.222]) by smtp.corp.redhat.com (Postfix) with ESMTP id 3326E2023227; Tue, 17 Apr 2018 16:56:48 +0000 (UTC) Date: Tue, 17 Apr 2018 18:56:46 +0200 From: Cornelia Huck To: Tony Krowiak Cc: Pierre Morel , freude@de.ibm.com, buendgen@de.ibm.com, linux-s390@vger.kernel.org, linux-kernel@vger.kernel.org, kvm@vger.kernel.org, schwidefsky@de.ibm.com, heiko.carstens@de.ibm.com, borntraeger@de.ibm.com, kwankhede@nvidia.com, bjsdjshi@linux.vnet.ibm.com, pbonzini@redhat.com, alex.williamson@redhat.com, alifm@linux.vnet.ibm.com, mjrosato@linux.vnet.ibm.com, jjherne@linux.vnet.ibm.com, thuth@redhat.com, pasic@linux.vnet.ibm.com, berrange@redhat.com, fiuczy@linux.vnet.ibm.com Subject: Re: [PATCH v4 01/15] s390: zcrypt: externalize AP instructions available function Message-ID: <20180417185646.5b43c911.cohuck@redhat.com> In-Reply-To: References: <1523827345-11600-1-git-send-email-akrowiak@linux.vnet.ibm.com> <1523827345-11600-2-git-send-email-akrowiak@linux.vnet.ibm.com> <77bbd4ca-8412-e59d-e1ca-9a114cf495a6@linux.vnet.ibm.com> <20180416141136.04be5558.cohuck@redhat.com> Organization: Red Hat GmbH MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-Scanned-By: MIMEDefang 2.78 on 10.11.54.4 X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.5.16 (mx1.redhat.com [10.11.55.8]); Tue, 17 Apr 2018 16:56:51 +0000 (UTC) X-Greylist: inspected by milter-greylist-4.5.16 (mx1.redhat.com [10.11.55.8]); Tue, 17 Apr 2018 16:56:51 +0000 (UTC) for IP:'10.11.54.4' DOMAIN:'int-mx04.intmail.prod.int.rdu2.redhat.com' HELO:'smtp.corp.redhat.com' FROM:'cohuck@redhat.com' RCPT:'' Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Tue, 17 Apr 2018 09:31:00 -0400 Tony Krowiak 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 > interfaces. 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.] 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 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.)