From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org X-Spam-Level: X-Spam-Status: No, score=-0.8 required=3.0 tests=HEADER_FROM_DIFFERENT_DOMAINS, MAILING_LIST_MULTI,SPF_PASS autolearn=ham autolearn_force=no version=3.4.0 Received: from mail.kernel.org (mail.kernel.org [198.145.29.99]) by smtp.lore.kernel.org (Postfix) with ESMTP id 66910ECE560 for ; Mon, 24 Sep 2018 16:13:17 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [209.132.180.67]) by mail.kernel.org (Postfix) with ESMTP id 122A72086B for ; Mon, 24 Sep 2018 16:13:17 +0000 (UTC) DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org 122A72086B Authentication-Results: mail.kernel.org; dmarc=fail (p=none dis=none) header.from=linux.ibm.com Authentication-Results: mail.kernel.org; spf=none smtp.mailfrom=linux-kernel-owner@vger.kernel.org Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1731104AbeIXWQI (ORCPT ); Mon, 24 Sep 2018 18:16:08 -0400 Received: from mx0b-001b2d01.pphosted.com ([148.163.158.5]:59760 "EHLO mx0a-001b2d01.pphosted.com" rhost-flags-OK-OK-OK-FAIL) by vger.kernel.org with ESMTP id S1730364AbeIXWQI (ORCPT ); Mon, 24 Sep 2018 18:16:08 -0400 Received: from pps.filterd (m0098419.ppops.net [127.0.0.1]) by mx0b-001b2d01.pphosted.com (8.16.0.22/8.16.0.22) with SMTP id w8OGCuoq140030 for ; Mon, 24 Sep 2018 12:13:13 -0400 Received: from e33.co.us.ibm.com (e33.co.us.ibm.com [32.97.110.151]) by mx0b-001b2d01.pphosted.com with ESMTP id 2mq36xr0mg-1 (version=TLSv1.2 cipher=AES256-GCM-SHA384 bits=256 verify=NOT) for ; Mon, 24 Sep 2018 12:13:09 -0400 Received: from localhost by e33.co.us.ibm.com with IBM ESMTP SMTP Gateway: Authorized Use Only! Violators will be prosecuted for from ; Mon, 24 Sep 2018 10:07:56 -0600 Received: from b03cxnp08026.gho.boulder.ibm.com (9.17.130.18) by e33.co.us.ibm.com (192.168.1.133) with IBM ESMTP SMTP Gateway: Authorized Use Only! Violators will be prosecuted; (version=TLSv1/SSLv3 cipher=AES256-GCM-SHA384 bits=256/256) Mon, 24 Sep 2018 10:07:53 -0600 Received: from b03ledav005.gho.boulder.ibm.com (b03ledav005.gho.boulder.ibm.com [9.17.130.236]) by b03cxnp08026.gho.boulder.ibm.com (8.14.9/8.14.9/NCO v10.0) with ESMTP id w8OG7oZe33358004 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=FAIL); Mon, 24 Sep 2018 09:07:50 -0700 Received: from b03ledav005.gho.boulder.ibm.com (unknown [127.0.0.1]) by IMSVA (Postfix) with ESMTP id 59155BE054; Mon, 24 Sep 2018 10:07:50 -0600 (MDT) Received: from b03ledav005.gho.boulder.ibm.com (unknown [127.0.0.1]) by IMSVA (Postfix) with ESMTP id 97C92BE051; Mon, 24 Sep 2018 10:07:47 -0600 (MDT) Received: from oc8043147753.ibm.com (unknown [9.85.130.123]) by b03ledav005.gho.boulder.ibm.com (Postfix) with ESMTP; Mon, 24 Sep 2018 10:07:47 -0600 (MDT) Subject: Re: [PATCH v10 11/26] s390: vfio-ap: implement mediated device open callback To: David Hildenbrand , Tony Krowiak , linux-s390@vger.kernel.org, linux-kernel@vger.kernel.org, kvm@vger.kernel.org Cc: freude@de.ibm.com, schwidefsky@de.ibm.com, heiko.carstens@de.ibm.com, borntraeger@de.ibm.com, cohuck@redhat.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, jjherne@linux.vnet.ibm.com, thuth@redhat.com, pasic@linux.vnet.ibm.com, berrange@redhat.com, fiuczy@linux.vnet.ibm.com, buendgen@de.ibm.com, frankja@linux.ibm.com References: <1536781396-13601-1-git-send-email-akrowiak@linux.vnet.ibm.com> <1536781396-13601-12-git-send-email-akrowiak@linux.vnet.ibm.com> <09a6b9e5-e335-14cf-debd-de0f92dafd5e@redhat.com> From: Tony Krowiak Date: Mon, 24 Sep 2018 12:07:46 -0400 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: <09a6b9e5-e335-14cf-debd-de0f92dafd5e@redhat.com> Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-US Content-Transfer-Encoding: 7bit X-TM-AS-GCONF: 00 x-cbid: 18092416-0036-0000-0000-00000A3DD861 X-IBM-SpamModules-Scores: X-IBM-SpamModules-Versions: BY=3.00009763; HX=3.00000242; KW=3.00000007; PH=3.00000004; SC=3.00000267; SDB=6.01093019; UDB=6.00564892; IPR=6.00873056; MB=3.00023483; MTD=3.00000008; XFM=3.00000015; UTC=2018-09-24 16:07:56 X-IBM-AV-DETECTION: SAVI=unused REMOTE=unused XFE=unused x-cbparentid: 18092416-0037-0000-0000-0000490D83FB Message-Id: X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10434:,, definitions=2018-09-24_09:,, 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 mlxscore=0 impostorscore=0 mlxlogscore=999 adultscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.0.1-1807170000 definitions=main-1809240158 Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On 09/24/2018 04:40 AM, David Hildenbrand wrote: > >> /** >> - * Verify that the AP instructions are available on the guest. This is >> indicated >> - * via the KVM_S390_VM_CPU_FEAT_AP CPU model feature. >> + * Verify that the AP instructions are being interpreted by firmware >> for the >> + * guest. This is indicated by the kvm->arch.crypto.apie flag. >> */ >> static int kvm_ap_validate_crypto_setup(struct kvm *kvm) >> { >> - if (test_bit_inv(KVM_S390_VM_CPU_FEAT_AP, kvm->arch.cpu_feat)) >> + if (kvm->arch.crypto.apie) >> return 0; > > I wonder if this check makes sense, because apie can be toggled during > runtime. I guess it would be sufficient to check if the ap control block > is available and apie is supported by the HW. I am not clear about what you are getting at here, but I'll attempt to respond. There is no need to check if the AP control block (CRYCB) is available as the address is set in the CRYCBD three instructions above, even if AP instructions are not available. Regarding whether apie is supported by the hardware, the value of vcpu->kvm->arch.crypto.apie can not be set unless it is supported by the HW. In the patch (24/26) that provides the VM attributes to toggle this value, it can only be turned on if the AP instructions are available. I might also note that the kvm_ap_validate_crypto_setup() function is called whenever one of the VM crypto attributes is changed, so it makes sense that decisions made in this function are based on a change to a VM crypto attribute. In my first pass at changing this function, I checked ap_instructions_available() here, but after considering all of the above, it made sense to me to check the apie flag. > >