From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mx0b-001b2d01.pphosted.com ([148.163.158.5]:41162 "EHLO mx0a-001b2d01.pphosted.com" rhost-flags-OK-OK-OK-FAIL) by vger.kernel.org with ESMTP id S1727049AbfGCAyD (ORCPT ); Tue, 2 Jul 2019 20:54:03 -0400 Received: from pps.filterd (m0098421.ppops.net [127.0.0.1]) by mx0a-001b2d01.pphosted.com (8.16.0.27/8.16.0.27) with SMTP id x62JvW76082520 for ; Tue, 2 Jul 2019 16:00:21 -0400 Received: from e06smtp07.uk.ibm.com (e06smtp07.uk.ibm.com [195.75.94.103]) by mx0a-001b2d01.pphosted.com with ESMTP id 2tgcpp2jmw-1 (version=TLSv1.2 cipher=AES256-GCM-SHA384 bits=256 verify=NOT) for ; Tue, 02 Jul 2019 16:00:21 -0400 Received: from localhost by e06smtp07.uk.ibm.com with IBM ESMTP SMTP Gateway: Authorized Use Only! Violators will be prosecuted for from ; Tue, 2 Jul 2019 21:00: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: Christian Borntraeger Date: Tue, 2 Jul 2019 22:00:14 +0200 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset="utf-8" Content-Language: en-US Content-Transfer-Encoding: 8bit Message-Id: <78617ca5-d822-ea4e-60ef-7a545b23ef15@de.ibm.com> Sender: linux-s390-owner@vger.kernel.org List-ID: To: Collin Walling , David Hildenbrand , cohuck@redhat.com, pbonzini@redhat.com, kvm@vger.kernel.org, linux-s390@vger.kernel.org On 02.07.19 21:50, Collin Walling wrote: > 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? But what happens if the guest ignores read scp info and executes diag318 anyway. It should get a specification exception, but it does not instead diag318 is executed.