Received: by 10.223.164.202 with SMTP id h10csp777496wrb; Tue, 14 Nov 2017 09:27:48 -0800 (PST) X-Google-Smtp-Source: AGs4zMY9JKnSVQqGmD2kGXDCTHpVvKtNdMVi9HUTU4eN+mcoD0a7fk0t1pRibqDMiKCMhE3FmVl0 X-Received: by 10.99.145.199 with SMTP id l190mr12764384pge.132.1510680468845; Tue, 14 Nov 2017 09:27:48 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; t=1510680468; cv=none; d=google.com; s=arc-20160816; b=IaG1acN6CvnE2TIo2rDfEYjozz3nxOrCJA5VCTMYaPVjFYvZJJ3+0WrP+tjKzG5v4D HxMpT/C93utyCrIkAiDdUc54A5JECsVAUykXyDPR1LqT59EEl3nA4I/LXvvPeOZQBzx5 0Rp04So9/G5tftsyF2LMaxConRUnhXgv6q4kHHNFd2Uu54y3+NKowULZRqk/4Ure6rOb qNEs64NI/7q59pR1BCYXWTWd4HU/ZBaHxWq57lDOPI+sTOMEVwpRc8n9QJVr7tub0Q/z Od6dgCG3zKP0DqrxiizkfW9oYMxqHRkKwuNAM50NOadgFEhVssY72NOEhUdXD9yWHmVd vcmg== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:message-id:content-language :content-transfer-encoding:in-reply-to:mime-version:user-agent:date :from:references:cc:to:subject:arc-authentication-results; bh=G3okOg8LmiaapSRhuiFAYlAxxkih7lyGprC2uCrKJTA=; b=F2GUpcMUs4UjM+yiOUQ7374kRJWpcme23L+p6MDRryv7LR4t0FgIDcY+oETi6gHT9B fMey3ZaO7VSiaLomSrTbdBA3833hPuQDA5uiSguXqjlD+Gb2Iqpu0F3WhK+8inJx1Bra h+1y6z8j4R2hnAbpYPVluwtiodDDt1j347xeIHuMtTZ8y8YB0Y+l2/Har11/AViSPb17 uLCTwuqCYAZTEdp7fKKVUKrFTG/MPBndrdxiuvTdqWreCXhoKLPqImI1NJ4BUJ8O1whn rGu0Je+PqUT9e3bwlThlxlI1+/qK51j6yiH2jZmCgRN4+EreZ+Le5KSVQ/txvisuEz2X fOww== 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=ibm.com Return-Path: Received: from vger.kernel.org (vger.kernel.org. [209.132.180.67]) by mx.google.com with ESMTP id n187si17736049pfn.150.2017.11.14.09.27.36; Tue, 14 Nov 2017 09:27:48 -0800 (PST) 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=ibm.com Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1755357AbdKNQhW (ORCPT + 88 others); Tue, 14 Nov 2017 11:37:22 -0500 Received: from mx0a-001b2d01.pphosted.com ([148.163.156.1]:47808 "EHLO mx0a-001b2d01.pphosted.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1755066AbdKNQhO (ORCPT ); Tue, 14 Nov 2017 11:37:14 -0500 Received: from pps.filterd (m0098404.ppops.net [127.0.0.1]) by mx0a-001b2d01.pphosted.com (8.16.0.21/8.16.0.21) with SMTP id vAEGZ3or066128 for ; Tue, 14 Nov 2017 11:37:14 -0500 Received: from e37.co.us.ibm.com (e37.co.us.ibm.com [32.97.110.158]) by mx0a-001b2d01.pphosted.com with ESMTP id 2e82qnn10x-1 (version=TLSv1.2 cipher=AES256-SHA bits=256 verify=NOT) for ; Tue, 14 Nov 2017 11:37:13 -0500 Received: from localhost by e37.co.us.ibm.com with IBM ESMTP SMTP Gateway: Authorized Use Only! Violators will be prosecuted for from ; Tue, 14 Nov 2017 09:37:12 -0700 Received: from b03cxnp08027.gho.boulder.ibm.com (9.17.130.19) by e37.co.us.ibm.com (192.168.1.137) with IBM ESMTP SMTP Gateway: Authorized Use Only! Violators will be prosecuted; Tue, 14 Nov 2017 09:37:09 -0700 Received: from b03ledav003.gho.boulder.ibm.com (b03ledav003.gho.boulder.ibm.com [9.17.130.234]) by b03cxnp08027.gho.boulder.ibm.com (8.14.9/8.14.9/NCO v10.0) with ESMTP id vAEGb7R84391350; Tue, 14 Nov 2017 09:37:07 -0700 Received: from b03ledav003.gho.boulder.ibm.com (unknown [127.0.0.1]) by IMSVA (Postfix) with ESMTP id A9E616A03D; Tue, 14 Nov 2017 09:37:07 -0700 (MST) Received: from oc8043147753.ibm.com (unknown [9.60.75.228]) by b03ledav003.gho.boulder.ibm.com (Postfix) with ESMTP id BCCEB6A03C; Tue, 14 Nov 2017 09:37:05 -0700 (MST) Subject: Re: [RFC 05/19] s390/zcrypt: base implementation of AP matrix device driver To: Cornelia Huck Cc: linux-s390@vger.kernel.org, linux-kernel@vger.kernel.org, kvm@vger.kernel.org, freude@de.ibm.com, 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, pmorel@linux.vnet.ibm.com, alifm@linux.vnet.ibm.com, mjrosato@linux.vnet.ibm.com, qemu-s390x@nongnu.org, jjherne@linux.vnet.ibm.com, thuth@redhat.com, pasic@linux.vnet.ibm.com References: <1507916344-3896-1-git-send-email-akrowiak@linux.vnet.ibm.com> <1507916344-3896-6-git-send-email-akrowiak@linux.vnet.ibm.com> <20171114134040.3fcd6efd.cohuck@redhat.com> From: Tony Krowiak Date: Tue, 14 Nov 2017 11:37:05 -0500 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.2.0 MIME-Version: 1.0 In-Reply-To: <20171114134040.3fcd6efd.cohuck@redhat.com> Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit Content-Language: en-US X-TM-AS-GCONF: 00 x-cbid: 17111416-0024-0000-0000-0000177C08CD X-IBM-SpamModules-Scores: X-IBM-SpamModules-Versions: BY=3.00008066; HX=3.00000241; KW=3.00000007; PH=3.00000004; SC=3.00000240; SDB=6.00945809; UDB=6.00477361; IPR=6.00726106; BA=6.00005690; NDR=6.00000001; ZLA=6.00000005; ZF=6.00000009; ZB=6.00000000; ZP=6.00000000; ZH=6.00000000; ZU=6.00000002; MB=3.00018012; XFM=3.00000015; UTC=2017-11-14 16:37:11 X-IBM-AV-DETECTION: SAVI=unused REMOTE=unused XFE=unused x-cbparentid: 17111416-0025-0000-0000-00004D7F78D3 Message-Id: <06ddee4e-e1b8-ba17-5e3e-241e4dcf7cd0@linux.vnet.ibm.com> X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:,, definitions=2017-11-14_08:,, signatures=0 X-Proofpoint-Spam-Details: rule=outbound_notspam policy=outbound score=0 priorityscore=1501 malwarescore=0 suspectscore=0 phishscore=0 bulkscore=0 spamscore=0 clxscore=1015 lowpriorityscore=0 impostorscore=0 adultscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.0.1-1709140000 definitions=main-1711140225 Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On 11/14/2017 07:40 AM, Cornelia Huck wrote: > On Fri, 13 Oct 2017 13:38:50 -0400 > Tony Krowiak wrote: > >> Introduces a new AP matrix device driver. This device driver >> will ultimately perform the following functions: >> >> * Register with the AP bus to let it know that the matrix >> driver can control AP queue devices. This will allow >> an administrator to unbind an AP queue device from its >> device driver and bind it to the matrix device driver. >> This is how AP queue devices will be reserved for use >> by guest machines. >> >> * Register the matrix device created by the AP matrix bus >> with the VFIO mediated device framework. This will create >> the sysfs entries needed to create mediated matrix devices. >> Each mediated matrix device can be configured with a matrix >> of adapters, usage domains and control domains that can be >> accessed by a guest machine. >> >> * Process requests via ioctl calls defined for the mediated >> matrix device. The guest can access the ioctl calls via >> the mediated device's file descriptor to: >> >> * Grant access to the adapters, usage domains and >> control domains configured for the mediated matrix >> device. >> >> This device driver >> is built on the VFIO mediated device framework. The VFIO mediated >> device framework allows a mediated device to be dedicated exclusively >> to a single guest VM. >> >> Signed-off-by: Tony Krowiak >> --- >> MAINTAINERS | 2 + >> arch/s390/Kconfig | 13 +++ >> arch/s390/configs/default_defconfig | 1 + >> arch/s390/configs/gcov_defconfig | 1 + >> arch/s390/configs/performance_defconfig | 1 + >> arch/s390/defconfig | 1 + >> drivers/s390/crypto/Makefile | 6 +- >> drivers/s390/crypto/ap_matrix_bus.c | 8 ++ >> drivers/s390/crypto/ap_matrix_bus.h | 2 +- >> drivers/s390/crypto/vfio_ap_matrix_drv.c | 102 ++++++++++++++++++++++++++ >> drivers/s390/crypto/vfio_ap_matrix_private.h | 47 ++++++++++++ >> 11 files changed, 182 insertions(+), 2 deletions(-) >> create mode 100644 drivers/s390/crypto/vfio_ap_matrix_drv.c >> create mode 100644 drivers/s390/crypto/vfio_ap_matrix_private.h >> >> diff --git a/arch/s390/Kconfig b/arch/s390/Kconfig >> index 48af970..411c19a 100644 >> --- a/arch/s390/Kconfig >> +++ b/arch/s390/Kconfig >> @@ -722,6 +722,19 @@ config VFIO_CCW >> To compile this driver as a module, choose M here: the >> module will be called vfio_ccw. >> >> +config VFIO_AP_MATRIX >> + def_tristate m >> + prompt "Support for Adjunct Processor Matrix device interface" >> + depends on ZCRYPT >> + select VFIO >> + select MDEV >> + select VFIO_MDEV >> + select VFIO_MDEV_DEVICE >> + select IOMMU_API > I think the more common pattern is to depend on the VFIO configs > instead of selecting them. It's ironic because I originally changed from using 'depends on' and changed it based on review comments made on our internal mailing list. I'll go with 'depends on'. > >> + help >> + driver grants access to Adjunct Processor (AP) devices >> + via the VFIO mediated device interface. >> + >> endmenu >> >> menu "Dump support" >> diff --git a/drivers/s390/crypto/Makefile b/drivers/s390/crypto/Makefile >> index 87646ca..1983afa 100644 >> --- a/drivers/s390/crypto/Makefile >> +++ b/drivers/s390/crypto/Makefile >> @@ -13,4 +13,8 @@ obj-$(CONFIG_ZCRYPT) += zcrypt_pcixcc.o zcrypt_cex2a.o zcrypt_cex4.o >> >> # pkey kernel module >> pkey-objs := pkey_api.o >> -obj-$(CONFIG_PKEY) += pkey.o >> \ No newline at end of file >> +obj-$(CONFIG_PKEY) += pkey.o > Another change of that line. Will fix this > >> + >> +# adjunct processor matrix >> +vfio_ap_matrix-objs := vfio_ap_matrix_drv.o >> +obj-$(CONFIG_VFIO_AP_MATRIX) += vfio_ap_matrix.o >> diff --git a/drivers/s390/crypto/ap_matrix_bus.c b/drivers/s390/crypto/ap_matrix_bus.c >> index 4eb1e3c..66bfa54 100644 >> --- a/drivers/s390/crypto/ap_matrix_bus.c >> +++ b/drivers/s390/crypto/ap_matrix_bus.c >> @@ -75,10 +75,18 @@ static int ap_matrix_dev_create(void) >> return 0; >> } >> >> +struct ap_matrix *ap_matrix_get_device(void) >> +{ >> + return matrix; > See the comments I had for the previous patch. In particular, I think > it is better to retrieve a pointer to the matrix device via driver core > methods. I got some objections to creating a new bus and since there will only ever be a single AP matrix device, I decided there really wasn't a need for an AP matrix bus and got rid of it. I opted instead to create the matrix device in the init function of the vfio_ap_matrix driver. Rather than passing around a pointer, I put the following in vfio_ap_matrix_private.h: struct ap_matrix { struct device device; spinlock_t qlock; struct list_head queues; }; extern struct ap_matrix ap_matrix; ... and declared the ap_matrix in the driver (vfio_ap_matrix_drv.c) file as: struct ap_matrix ap_matrix; Does this seem like a reasonable approach? > >> +} >> +EXPORT_SYMBOL(ap_matrix_get_device); >> + >> int __init ap_matrix_init(void) >> { >> int ret; >> >> + matrix = NULL; >> + >> ap_matrix_root_device = root_device_register(AP_MATRIX_BUS_NAME); >> ret = PTR_RET(ap_matrix_root_device); >> if (ret) >> diff --git a/drivers/s390/crypto/ap_matrix_bus.h b/drivers/s390/crypto/ap_matrix_bus.h >> index 225db4f..c2aff23 100644 >> --- a/drivers/s390/crypto/ap_matrix_bus.h >> +++ b/drivers/s390/crypto/ap_matrix_bus.h >> @@ -16,6 +16,6 @@ struct ap_matrix { >> struct device device; >> }; >> >> -int ap_matrix_init(void); > So, was that not needed before? Forgot to remove it when I refactored a previous patch in which was introduced. > >> +struct ap_matrix *ap_matrix_get_device(void); >> >> #endif /* _AP_MATRIX_BUS_H_ */ >> diff --git a/drivers/s390/crypto/vfio_ap_matrix_drv.c b/drivers/s390/crypto/vfio_ap_matrix_drv.c >> new file mode 100644 >> index 0000000..760ed56 >> --- /dev/null >> +++ b/drivers/s390/crypto/vfio_ap_matrix_drv.c >> @@ -0,0 +1,102 @@ >> +/* >> + * VFIO based AP Matrix device driver >> + * >> + * Copyright IBM Corp. 2017 >> + * >> + * Author(s): Tony Krowiak >> + */ >> + >> +#include >> +#include >> +#include >> + >> +#include "ap_bus.h" >> +#include "ap_matrix_bus.h" >> +#include "vfio_ap_matrix_private.h" >> + >> +#define VFIO_AP_MATRIX_DRV_NAME "vfio_ap_queue" >> + >> +MODULE_AUTHOR("IBM Corporation"); >> +MODULE_DESCRIPTION("AP Matrix device driver, Copyright IBM Corp. 2017"); >> +MODULE_LICENSE("GPL v2"); >> + >> +static struct ap_device_id ap_queue_ids[] = { >> + { .dev_type = AP_DEVICE_TYPE_CEX4, >> + .match_flags = AP_DEVICE_ID_MATCH_QUEUE_TYPE }, >> + { .dev_type = AP_DEVICE_TYPE_CEX5, >> + .match_flags = AP_DEVICE_ID_MATCH_QUEUE_TYPE }, >> + { .dev_type = AP_DEVICE_TYPE_CEX6, >> + .match_flags = AP_DEVICE_ID_MATCH_QUEUE_TYPE }, > So, you explicitly don't match to all devices, but only to the newer > ones? This needs an explaining comment. Okay > >> + { /* end of list */ }, >> +}; >> + >> +MODULE_DEVICE_TABLE(ap_matrix, ap_queue_ids); >> + >> +static struct ap_matrix_driver { >> + struct ap_driver ap_drv; >> + struct ap_matrix *ap_matrix; > Do you actually need that pointer to the matrix device? One usage is to > pass it as an parameter to the mdev registration in the next patch. As > you only support one matrix device, would it be better to move getting > that device into the mdev code? > > For the other usage, move getting it into find_vapq()? See my comments above regarding getting rid of the AP matrix bus. > >> +} vfio_ap_matrix_drv; >> + >> +static int ap_matrix_queue_dev_probe(struct ap_device *apdev) >> +{ >> + struct vfio_ap_queue *vapq; >> + struct ap_queue *apq = to_ap_queue(&apdev->device); >> + struct ap_matrix *ap_matrix = vfio_ap_matrix_drv.ap_matrix; >> + >> + vapq = kzalloc(sizeof(*vapq), GFP_KERNEL); >> + if (!vapq) >> + return -ENOMEM; >> + >> + INIT_LIST_HEAD(&vapq->list); >> + vapq->queue = apq; >> + spin_lock_bh(&ap_matrix->qlock); >> + list_add_tail(&vapq->list, &ap_matrix->queues); >> + spin_unlock_bh(&ap_matrix->qlock); >> + >> + return 0; >> +} >> + >> +static void ap_matrix_queue_dev_remove(struct ap_device *apdev) >> +{ >> + struct vfio_ap_queue *vapq; >> + struct ap_queue *apq = to_ap_queue(&apdev->device); >> + struct ap_matrix *ap_matrix = vfio_ap_matrix_drv.ap_matrix; >> + >> + vapq = find_vapq(ap_matrix, apq->qid); >> + >> + if (vapq) { >> + spin_lock_bh(&ap_matrix->qlock); >> + list_del_init(&vapq->list); >> + spin_unlock_bh(&ap_matrix->qlock); >> + kfree(vapq); >> + } >> +} >> + >> +int __init ap_matrix_init(void) >> +{ >> + >> + int ret; >> + >> + vfio_ap_matrix_drv.ap_matrix = ap_matrix_get_device(); >> + if (!vfio_ap_matrix_drv.ap_matrix) >> + return -ENODEV; >> + >> + vfio_ap_matrix_drv.ap_drv.probe = ap_matrix_queue_dev_probe; >> + vfio_ap_matrix_drv.ap_drv.remove = ap_matrix_queue_dev_remove; >> + vfio_ap_matrix_drv.ap_drv.ids = ap_queue_ids; > Can you use an static initializer for that? This is how its done for the AP bus drivers, for example; see zcrypt_cex4.c. > >> + >> + ret = ap_driver_register(&vfio_ap_matrix_drv.ap_drv, >> + THIS_MODULE, VFIO_AP_MATRIX_DRV_NAME); >> + if (ret) >> + return ret; >> + >> + return ret; >> +} >> + >> +void __exit ap_matrix_exit(void) >> +{ >> + ap_driver_unregister(&vfio_ap_matrix_drv.ap_drv); >> +} >> + >> +module_init(ap_matrix_init); >> +module_exit(ap_matrix_exit); >> diff --git a/drivers/s390/crypto/vfio_ap_matrix_private.h b/drivers/s390/crypto/vfio_ap_matrix_private.h >> new file mode 100644 >> index 0000000..11c5e02 >> --- /dev/null >> +++ b/drivers/s390/crypto/vfio_ap_matrix_private.h >> @@ -0,0 +1,47 @@ >> +/* >> + * Private data and functions for adjunct processor VFIO matrix driver. >> + * >> + * Copyright IBM Corp. 2016 >> + * Author(s): Tony Krowiak >> + */ >> + >> +#ifndef _VFIO_AP_PRIVATE_H_ >> +#define _VFIO_AP_PRIVATE_H_ >> + >> +#include >> + >> +#include "ap_bus.h" >> +#include "ap_matrix_bus.h" >> + >> +#define VFIO_AP_MATRIX_MODULE_NAME "vfio_ap_matrix" >> + >> +struct vfio_ap_queue { >> + struct ap_queue *queue; >> + struct list_head list; >> +}; >> + >> +static inline struct vfio_ap_queue *to_vapq(struct ap_device *ap_dev) >> +{ >> + struct ap_queue *ap_queue = to_ap_queue(&ap_dev->device); >> + struct vfio_ap_queue *vapq; >> + >> + vapq = container_of(&ap_queue, struct vfio_ap_queue, queue); > Why not just return container_of(...); ? Will change it. > >> + >> + return vapq; >> +} >> + >> +static inline struct vfio_ap_queue *find_vapq(struct ap_matrix *ap_matrix, >> + ap_qid_t qid) >> +{ >> + struct vfio_ap_queue *vapq; >> + >> + if (!list_empty(&ap_matrix->queues)) { >> + list_for_each_entry(vapq, &ap_matrix->queues, list) >> + if (vapq->queue->qid == qid) >> + return vapq; >> + } >> + >> + return NULL; >> +} >> + >> +#endif /* _VFIO_AP_PRIVATE_H_ */ From 1584045361100964696@xxx Tue Nov 14 12:42:56 +0000 2017 X-GM-THRID: 1581165332668656184 X-Gmail-Labels: Inbox,Category Forums,HistoricalUnread