Received: by 2002:a05:6a10:206:0:0:0:0 with SMTP id 6csp3478174pxj; Mon, 24 May 2021 07:39:05 -0700 (PDT) X-Google-Smtp-Source: ABdhPJwcmpNhxIUuXvOsbqBSOyhQSZEYhA95i8Vk3HvH2Xv3MOwMuEzKWmAlraUr7XTlSaikbMBF X-Received: by 2002:a17:906:d7a8:: with SMTP id pk8mr24257689ejb.74.1621867145474; Mon, 24 May 2021 07:39:05 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1621867145; cv=none; d=google.com; s=arc-20160816; b=Uxtvj16EotTi2UZAq4Pz3ia1aSn6rKLcfKDd5toiNLLi5xLiuOULP/mz0YjjgzP2+4 2rBXVExcJMveTLnpgAQYRA7gOlyNE/dQ5ANXNjN0MCKngBbXC+7dkL1OdPOp2eIne7Pt bE5aTkmx0afaV+tg+Hiccjy8XR1OnfhWU76YD6ROjhxW5X5v49zZgsZpgDaloFZMtNiG 2rCC2yp8mGUc19DxzJAr6srl24lvIGmXJbEjHGiMQcZzpaIXxbpRJs+F3AFBVL4e5CQX dBLIrqRFWNKzxGgFBYBzpbHPfg9JWCi+sBSvmlMYX8N7alJG7Cj6cAsicSa8UCz7EP6R oDbw== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:content-transfer-encoding:content-language :in-reply-to:mime-version:user-agent:date:message-id:organization :from:references:cc:to:subject:reply-to:dkim-signature; bh=qiGLtExK2d9UEaFhiSzXGydhB/xUyM2qKG7kqm1Po7A=; b=IwXB2+XMRCcbN/u6wxMdhWMiiNBLNugL3SswpWLrkt9hz8ZsykgVQb6Sw2JtW3fUl3 tHG6VJpBOq6ektY1vAblwPVwb5E96fno/fTEodt5eiRGBNSjTwJsobOMUxEOE3+RTty3 idkUHi1f/+9eqhVGNN3jhDDsnvnZfbmCwe5D9+4oVxmPVp4gd50UPvQ8FlHJLBHUu2Lm eqMpImL5BPaad3ANoP+nnaXet9mfjFFrmxLxBt716LHRC77KszM348K9NwpJbGrTnM6k O6BfeL1ltX7tUC1Ju2tQB4qqzZSLuRRqogtFT7BwH8Gvb1ZWPqjMLdDK+g99IP/Z/QJ2 HnUA== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@ibm.com header.s=pp1 header.b=nVdJF9PK; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=ibm.com Return-Path: Received: from vger.kernel.org (vger.kernel.org. [23.128.96.18]) by mx.google.com with ESMTP id w6si10584474edd.217.2021.05.24.07.38.42; Mon, 24 May 2021 07:39:05 -0700 (PDT) Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) client-ip=23.128.96.18; Authentication-Results: mx.google.com; dkim=pass header.i=@ibm.com header.s=pp1 header.b=nVdJF9PK; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=ibm.com Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S232983AbhEXOjE (ORCPT + 99 others); Mon, 24 May 2021 10:39:04 -0400 Received: from mx0a-001b2d01.pphosted.com ([148.163.156.1]:27318 "EHLO mx0a-001b2d01.pphosted.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S232662AbhEXOjD (ORCPT ); Mon, 24 May 2021 10:39:03 -0400 Received: from pps.filterd (m0098409.ppops.net [127.0.0.1]) by mx0a-001b2d01.pphosted.com (8.16.0.43/8.16.0.43) with SMTP id 14OEXnOI069039; Mon, 24 May 2021 10:37:33 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ibm.com; h=reply-to : subject : to : cc : references : from : message-id : date : mime-version : in-reply-to : content-type : content-transfer-encoding; s=pp1; bh=qiGLtExK2d9UEaFhiSzXGydhB/xUyM2qKG7kqm1Po7A=; b=nVdJF9PKah3fmlWlmGtqQhOYWETzWz+0S3IHiaa3tv4wIJFnpoox2r1dzmGRMxfVCw2s ym498pkS+2J+BxUu1vUh8JAfHA7Il8qEKGin9JyC2JiGanNFBfPPhB7g/Vu8/Cy/0HaO JVji4g7BTAE5M+Z6pCl6p1GgUiAzJk9rUrRSuiVTIJYsHt9BJSuKWVWXZIr33EcP1IrB H2t3yzY4w79lix0YcJwTHPS1LHxbEZUo1P+PuZmzjJuqetIIqsS8rG5rnkJDPH32+gF0 J3Y4+7B2xP32lBH9c0PAG1hXA3g143iaR5VccjjJ//uc8opZIngQjF1xMI+SUk7GgPa8 JQ== Received: from pps.reinject (localhost [127.0.0.1]) by mx0a-001b2d01.pphosted.com with ESMTP id 38rcp6jq8s-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Mon, 24 May 2021 10:37:32 -0400 Received: from m0098409.ppops.net (m0098409.ppops.net [127.0.0.1]) by pps.reinject (8.16.0.43/8.16.0.43) with SMTP id 14OEZQak078053; Mon, 24 May 2021 10:37:32 -0400 Received: from ppma03dal.us.ibm.com (b.bd.3ea9.ip4.static.sl-reverse.com [169.62.189.11]) by mx0a-001b2d01.pphosted.com with ESMTP id 38rcp6jq7v-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Mon, 24 May 2021 10:37:32 -0400 Received: from pps.filterd (ppma03dal.us.ibm.com [127.0.0.1]) by ppma03dal.us.ibm.com (8.16.0.43/8.16.0.43) with SMTP id 14OES4ph004652; Mon, 24 May 2021 14:37:31 GMT Received: from b01cxnp22033.gho.pok.ibm.com (b01cxnp22033.gho.pok.ibm.com [9.57.198.23]) by ppma03dal.us.ibm.com with ESMTP id 38psk8uhpp-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Mon, 24 May 2021 14:37:31 +0000 Received: from b01ledav006.gho.pok.ibm.com (b01ledav006.gho.pok.ibm.com [9.57.199.111]) by b01cxnp22033.gho.pok.ibm.com (8.14.9/8.14.9/NCO v10.0) with ESMTP id 14OEbURt32178562 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=OK); Mon, 24 May 2021 14:37:30 GMT Received: from b01ledav006.gho.pok.ibm.com (unknown [127.0.0.1]) by IMSVA (Postfix) with ESMTP id B1E42AC05B; Mon, 24 May 2021 14:37:30 +0000 (GMT) Received: from b01ledav006.gho.pok.ibm.com (unknown [127.0.0.1]) by IMSVA (Postfix) with ESMTP id 3C278AC059; Mon, 24 May 2021 14:37:30 +0000 (GMT) Received: from [9.85.129.37] (unknown [9.85.129.37]) by b01ledav006.gho.pok.ibm.com (Postfix) with ESMTP; Mon, 24 May 2021 14:37:30 +0000 (GMT) Reply-To: jjherne@linux.ibm.com Subject: Re: [PATCH v4 2/2] s390/vfio-ap: control access to PQAP(AQIC) interception handler To: Tony Krowiak , linux-s390@vger.kernel.org, linux-kernel@vger.kernel.org Cc: borntraeger@de.ibm.com, cohuck@redhat.com, pasic@linux.vnet.ibm.com, jgg@nvidia.com, alex.williamson@redhat.com, kwankhede@nvidia.com, frankja@linux.ibm.com, david@redhat.com, imbrenda@linux.ibm.com, hca@linux.ibm.com References: <20210521193648.940864-1-akrowiak@linux.ibm.com> <20210521193648.940864-3-akrowiak@linux.ibm.com> From: "Jason J. Herne" Organization: IBM Message-ID: <5d15fdf2-aee8-4e6c-c3e1-f07c76ce5974@linux.ibm.com> Date: Mon, 24 May 2021 10:37:29 -0400 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:68.0) Gecko/20100101 Thunderbird/68.1.0 MIME-Version: 1.0 In-Reply-To: <20210521193648.940864-3-akrowiak@linux.ibm.com> Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-US Content-Transfer-Encoding: 7bit X-TM-AS-GCONF: 00 X-Proofpoint-GUID: Gh3eRF05AJL4dIKt3kY4Me_bNdevfKmh X-Proofpoint-ORIG-GUID: E73HcYud6QteG_CBEWq1GhvSGDbV1Fi6 X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10434:6.0.391,18.0.761 definitions=2021-05-24_08:2021-05-24,2021-05-24 signatures=0 X-Proofpoint-Spam-Details: rule=outbound_notspam policy=outbound score=0 impostorscore=0 priorityscore=1501 bulkscore=0 phishscore=0 adultscore=0 lowpriorityscore=0 clxscore=1011 mlxlogscore=999 malwarescore=0 mlxscore=0 spamscore=0 suspectscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.12.0-2104190000 definitions=main-2105240092 Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On 5/21/21 3:36 PM, Tony Krowiak wrote: > The function pointer to the handler that processes interception of the > PQAP instruction is contained in the mdev. If the mdev is removed and > its storage de-allocated during the processing of the PQAP instruction, > the function pointer could get wiped out before the function is called > because there is currently nothing that controls access to it. > > This patch introduces two new functions: > * The kvm_arch_crypto_register_hook() function registers a function pointer > for processing intercepted crypto instructions. > * The kvm_arch_crypto_register_hook() function un-registers a function > pointer that was previously registered. Typo: You meant kvm_arch_crypto_UNregister_hook() in the second bullet. Just one overall observation on this one. The whole hook system seems kind of over-engineered if this is our only use for it. It looks like a kvm_s390_crypto_hook is meant to link a specific module with a function pointer. Do we really need this concept? I think a simpler design could be to just place a mutex and a function pointer in the kvm_s390_crypto struct. Then you can grab the mutex in vfio_ap_ops.c when registering/unregistering. You would also grab the mutex in priv.c when calling the function pointer. What I am suggesting is essentially the exact same scheme you have implemented here, but simpler and with less infrastructure. With that said, I'll point out that I am relative new to this code (and this patch series) so maybe I've missed something and the extra complexity is needed for some reason. But if it is not, I'm all in favor of keeping things simple. -- -- Jason J. Herne (jjherne@linux.ibm.com)