Received: by 10.213.65.68 with SMTP id h4csp1266448imn; Wed, 14 Mar 2018 14:58:45 -0700 (PDT) X-Google-Smtp-Source: AG47ELvAyRwBrSqQlgJtSSxm4dnMFXGI7thukF5ynQkh7Wwvha5UtzEh5Em5nkQBoMNp15gHKlPW X-Received: by 2002:a17:902:9a45:: with SMTP id x5-v6mr5419033plv.18.1521064725603; Wed, 14 Mar 2018 14:58:45 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1521064725; cv=none; d=google.com; s=arc-20160816; b=juQ9xwflG3uppK6zRt6Z0c7u3WkR1V3VtRP3L2/umh0xe5CifX/ffWD70qzC/b0vvq i0zjUIe42FoVkBp+2nHXyywaRiO+E6a2fwYzjAq8fpm+t4a4zjCRIzLO0ihGieuJcjNE 43Cu3TFUDaDZ3G1mrokFWoI0zzY4bpVpEEAhnTe2GuNeN0BW7Lp2+ZRSqJgJ6+5SmsRn GoM2tjt+p/8cs6pxCL/fHuxYXkBog6czcmtW/pqge+KghePh/7j+JanPQjj1PJ6gPeTU jXbwauFXeqDCLpKBr794K+Eonrgf8oxbztlDWP02lOgOKxEjVvjoHgKE4s+B1CS1zqv4 HswA== 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-transfer-encoding :content-language:in-reply-to:mime-version:user-agent:date :references:cc:to:subject:from:arc-authentication-results; bh=HIY0dpJhGpGk6ZcWZBzsVKyBj+UqEU6HAxVqSAvQuyg=; b=HWqjRrMos6xzRz5Kr2m11KtQwZbPZ2RGfmkN96wxR1e8Nu4MT0JxIC1iNT0f8oUOpv xruYdLBkNJevqep9NzoqalQUn7R8ugb9M7dLZPpTdqj3Sj5z3DgHEltnbuGWsy1aUtKF 6II0J1vMyxY8w0SnW+6KqSOnrCqAVIHLScrRhr+GVMY434Wka0+O4LEyTZUsVSJORI/N 6u95RQw8arWoRZTxcKddU0vSVg6jnqqEUPH6afUr6k24uZu+w3RU/auaLESISzwnwHL/ IcCFQ5Scfk86A8AfcSfvAmPDm9BFi7shsQDhPcK64+lLtAImb+CBVIuEQA34nOcwXoHg XfyQ== 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 v21-v6si2609068plo.621.2018.03.14.14.58.31; Wed, 14 Mar 2018 14:58:45 -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=ibm.com Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1751588AbeCNV5g (ORCPT + 99 others); Wed, 14 Mar 2018 17:57:36 -0400 Received: from mx0a-001b2d01.pphosted.com ([148.163.156.1]:32950 "EHLO mx0a-001b2d01.pphosted.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1750779AbeCNV5d (ORCPT ); Wed, 14 Mar 2018 17:57:33 -0400 Received: from pps.filterd (m0098410.ppops.net [127.0.0.1]) by mx0a-001b2d01.pphosted.com (8.16.0.22/8.16.0.22) with SMTP id w2ELuFkb110631 for ; Wed, 14 Mar 2018 17:57:33 -0400 Received: from e06smtp10.uk.ibm.com (e06smtp10.uk.ibm.com [195.75.94.106]) by mx0a-001b2d01.pphosted.com with ESMTP id 2gqa9ykwaw-1 (version=TLSv1.2 cipher=AES256-SHA256 bits=256 verify=NOT) for ; Wed, 14 Mar 2018 17:57:33 -0400 Received: from localhost by e06smtp10.uk.ibm.com with IBM ESMTP SMTP Gateway: Authorized Use Only! Violators will be prosecuted for from ; Wed, 14 Mar 2018 21:57:30 -0000 Received: from b06cxnps3074.portsmouth.uk.ibm.com (9.149.109.194) by e06smtp10.uk.ibm.com (192.168.101.140) with IBM ESMTP SMTP Gateway: Authorized Use Only! Violators will be prosecuted; Wed, 14 Mar 2018 21:57:27 -0000 Received: from d06av25.portsmouth.uk.ibm.com (d06av25.portsmouth.uk.ibm.com [9.149.105.61]) by b06cxnps3074.portsmouth.uk.ibm.com (8.14.9/8.14.9/NCO v10.0) with ESMTP id w2ELvRZN64553096; Wed, 14 Mar 2018 21:57:27 GMT Received: from d06av25.portsmouth.uk.ibm.com (unknown [127.0.0.1]) by IMSVA (Postfix) with ESMTP id 3B3C611C04C; Wed, 14 Mar 2018 21:50:05 +0000 (GMT) Received: from d06av25.portsmouth.uk.ibm.com (unknown [127.0.0.1]) by IMSVA (Postfix) with ESMTP id BFE7D11C04A; Wed, 14 Mar 2018 21:50:03 +0000 (GMT) Received: from oc3836556865.ibm.com (unknown [9.145.172.162]) by d06av25.portsmouth.uk.ibm.com (Postfix) with ESMTP; Wed, 14 Mar 2018 21:50:03 +0000 (GMT) From: Halil Pasic Subject: Re: [PATCH v3 04/14] KVM: s390: device attribute to set AP interpretive execution To: 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, berrange@redhat.com, fiuczy@linux.vnet.ibm.com, buendgen@de.ibm.com References: <1521051954-25715-1-git-send-email-akrowiak@linux.vnet.ibm.com> <1521051954-25715-5-git-send-email-akrowiak@linux.vnet.ibm.com> Date: Wed, 14 Mar 2018 22:57:25 +0100 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.6.0 MIME-Version: 1.0 In-Reply-To: <1521051954-25715-5-git-send-email-akrowiak@linux.vnet.ibm.com> Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: 8bit X-TM-AS-GCONF: 00 x-cbid: 18031421-0040-0000-0000-000004208E72 X-IBM-AV-DETECTION: SAVI=unused REMOTE=unused XFE=unused x-cbparentid: 18031421-0041-0000-0000-000026239529 Message-Id: X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:,, definitions=2018-03-14_11:,, 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=1011 lowpriorityscore=0 impostorscore=0 adultscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.0.1-1709140000 definitions=main-1803140234 Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On 03/14/2018 07:25 PM, Tony Krowiak wrote: > The VFIO AP device model exploits interpretive execution of AP > instructions (APIE) to provide guests passthrough access to AP > devices. This patch introduces a new device attribute in the > KVM_S390_VM_CRYPTO device attribute group to set APIE from > the VFIO AP device defined on the guest. > > Signed-off-by: Tony Krowiak > --- [..] > diff --git a/arch/s390/kvm/kvm-s390.c b/arch/s390/kvm/kvm-s390.c > index a60c45b..bc46b67 100644 > --- a/arch/s390/kvm/kvm-s390.c > +++ b/arch/s390/kvm/kvm-s390.c > @@ -815,6 +815,19 @@ static int kvm_s390_vm_set_crypto(struct kvm *kvm, struct kvm_device_attr *attr) > sizeof(kvm->arch.crypto.crycb->dea_wrapping_key_mask)); > VM_EVENT(kvm, 3, "%s", "DISABLE: DEA keywrapping support"); > break; > + case KVM_S390_VM_CRYPTO_INTERPRET_AP: > + if (attr->addr) { > + if (!test_kvm_cpu_feat(kvm, KVM_S390_VM_CPU_FEAT_AP)) Unlock mutex before returning? Maybe flip conditions (don't allow manipulating apie if feature not there). Clearing the anyways clear apie if feature not there ain't too bad, but rejecting the operation appears nicer to me. > + return -EOPNOTSUPP; > + kvm->arch.crypto.apie = 1; > + VM_EVENT(kvm, 3, "%s", > + "ENABLE: AP interpretive execution"); > + } else { > + kvm->arch.crypto.apie = 0; > + VM_EVENT(kvm, 3, "%s", > + "DISABLE: AP interpretive execution"); > + } > + break; > default: > mutex_unlock(&kvm->lock); > return -ENXIO; I wonder how the loop after this switch works for KVM_S390_VM_CRYPTO_INTERPRET_AP: kvm_for_each_vcpu(i, vcpu, kvm) { kvm_s390_vcpu_crypto_setup(vcpu); exit_sie(vcpu); } From not doing something like for KVM_S390_VM_CRYPTO_INTERPRET_AP if (kvm->created_vcpus) { mutex_unlock(&kvm->lock); return -EBUSY; and from the aforementioned loop I guess ECA.28 can be changed for a running guest. If there are running vcpus when KVM_S390_VM_CRYPTO_INTERPRET_AP is changed (set) these will be taken out of SIE by exit_sie(). Then for the corresponding threads the control probably goes to QEMU (the emulator in the userspace). And it puts that vcpu back into the SIE, and then that cpu starts acting according to the new ECA.28 value. While other vcpus may still work with the old value of ECA.28. I'm not saying what I describe above is necessarily something broken. But I would like to have it explained, why is it OK -- provided I did not make any errors in my reasoning (assumptions included). Can you help me understand this code? Regards, Halil [..]