From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mx0b-001b2d01.pphosted.com ([148.163.158.5]:4258 "EHLO mx0a-001b2d01.pphosted.com" rhost-flags-OK-OK-OK-FAIL) by vger.kernel.org with ESMTP id S1726291AbfGBTuW (ORCPT ); Tue, 2 Jul 2019 15:50:22 -0400 Received: from pps.filterd (m0098417.ppops.net [127.0.0.1]) by mx0a-001b2d01.pphosted.com (8.16.0.27/8.16.0.27) with SMTP id x62Jkge9035841 for ; Tue, 2 Jul 2019 15:50:20 -0400 Received: from e12.ny.us.ibm.com (e12.ny.us.ibm.com [129.33.205.202]) by mx0a-001b2d01.pphosted.com with ESMTP id 2tgb3tp46x-1 (version=TLSv1.2 cipher=AES256-GCM-SHA384 bits=256 verify=NOT) for ; Tue, 02 Jul 2019 15:50:20 -0400 Received: from localhost by e12.ny.us.ibm.com with IBM ESMTP SMTP Gateway: Authorized Use Only! Violators will be prosecuted for from ; Tue, 2 Jul 2019 20:50:19 +0100 Subject: Re: [PATCH v5 2/2] s390/kvm: diagnose 318 handling References: <1561475022-18348-1-git-send-email-walling@linux.ibm.com> <1561475022-18348-3-git-send-email-walling@linux.ibm.com> <19c73246-48dd-ddc6-c5b1-b93f15cbf2f0@redhat.com> <17fe3423-91b1-2351-54cb-26cd9e1b0e3f@de.ibm.com> From: Collin Walling Date: Tue, 2 Jul 2019 15:50:16 -0400 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-US Content-Transfer-Encoding: 7bit Message-Id: Sender: linux-s390-owner@vger.kernel.org List-ID: To: David Hildenbrand , Christian Borntraeger , cohuck@redhat.com, pbonzini@redhat.com, kvm@vger.kernel.org, linux-s390@vger.kernel.org On 6/26/19 10:31 AM, David Hildenbrand wrote: > On 26.06.19 16:30, Collin Walling wrote: >> On 6/26/19 6:28 AM, Christian Borntraeger wrote: >>> >>> >>> On 26.06.19 11:45, David Hildenbrand wrote: >>> >>>> >>>> BTW. there is currently no mechanism to fake absence of diag318. Should >>>> we have one? (in contrast, for CMMA we have, which is also a CPU feature) >>> >>> Yes, we want to be able to disable diag318 via a CPU model feature. That actually >>> means that the kernel must not answer this if we disable it. >>> >> Correct. If the guest specifies diag318=off, then the instruction >> shouldn't be executed (it is fenced off in the kernel by checking the >> Read SCP Info bit). > > But the guest *could* execute it and not get an exception. > IIUC, you're talking about the situation where QEMU supports diag318, but KVM does not. The worst case is the guest specifies diag318=on, and nothing will stop the guest from attempting to execute the instruction. However, this is fenced in my QEMU patches. In (v5), I have this following snippet: @@ -2323,6 +2345,13 @@ void kvm_s390_get_host_cpu_model(S390CPUModel *model, Error **errp) KVM_S390_VM_CRYPTO_ENABLE_APIE)) { set_bit(S390_FEAT_AP, model->features); } + + /* if KVM supports interception of diag318, then let's provide the bit */ + if (kvm_vm_check_attr(kvm_state, KVM_S390_VM_MISC, + KVM_S390_VM_MISC_DIAG318)) { + set_bit(S390_FEAT_DIAG318, model->features); + } + /* strip of features that are not part of the maximum model */ bitmap_and(model->features, model->features, model->def->full_feat, S390_FEAT_MAX); If the guest specifies diag318=on, and KVM does *not* support emulation, then the following message will be observed: qemu-system-s390x: Some features requested in the CPU model are not available in the configuration: diag318 and the guest will fail to start. Does this suffice?