From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mx0a-001b2d01.pphosted.com ([148.163.156.1]:48566 "EHLO mx0a-001b2d01.pphosted.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1726555AbgEFX36 (ORCPT ); Wed, 6 May 2020 19:29:58 -0400 Subject: Re: [PATCH] KVM: s390: Remove false WARN_ON_ONCE for the PQAP instruction References: <20200505073525.2287-1-borntraeger@de.ibm.com> <20200505095332.528254e5.cohuck@redhat.com> <889a7e3d-8318-4c85-67c8-a42a665b56f4@linux.ibm.com> <39228085-aed6-2fe8-79bc-dfd21c8cf2e9@de.ibm.com> From: Tony Krowiak Message-ID: <889c7c6d-fa27-5e2f-b5bc-a1e3ed8a923b@linux.ibm.com> Date: Wed, 6 May 2020 19:29:55 -0400 MIME-Version: 1.0 In-Reply-To: <39228085-aed6-2fe8-79bc-dfd21c8cf2e9@de.ibm.com> Content-Type: text/plain; charset="utf-8"; format="flowed" Content-Transfer-Encoding: 8bit Content-Language: en-US Sender: linux-s390-owner@vger.kernel.org List-ID: To: Christian Borntraeger , Cornelia Huck Cc: Janosch Frank , KVM , David Hildenbrand , linux-s390 , Qian Cai , Pierre Morel On 5/6/20 2:08 AM, Christian Borntraeger wrote: > > On 06.05.20 00:34, Tony Krowiak wrote: >> >> On 5/5/20 3:55 AM, Christian Borntraeger wrote: >>> On 05.05.20 09:53, Cornelia Huck wrote: >>>> On Tue,  5 May 2020 09:35:25 +0200 >>>> Christian Borntraeger wrote: >>>> >>>>> In LPAR we will only get an intercept for FC==3 for the PQAP >>>>> instruction. Running nested under z/VM can result in other intercepts as >>>>> well, for example PQAP(QCI). So the WARN_ON_ONCE is not right. Let >>>>> us simply remove it. >>>> While I agree with removing the WARN_ON_ONCE, I'm wondering why z/VM >>>> gives us intercepts for those fcs... is that just a result of nesting >>>> (or the z/VM implementation), or is there anything we might want to do? >>> Yes nesting. >>> The ECA bit for interpretion is an effective one. So if the ECA bit is off >>> in z/VM (no crypto cards) our ECA bit is basically ignored as these bits >>> are ANDed. >>> I asked Tony to ask the z/VM team if that is the case here. >> I apologize, but I was on vacation yesterday and did not have a >> chance to look at this until today. I left a slack message for >> my z/VM contact, but have not yet gotten a response. >> >> The only AP virtualization support we currently provide with >> Linux on Z relies on AP interpretive execution. The ECA.28 >> bit in the SIE state description determines whether AP >> instructions executed on a guest are intercepted (0) or >> interpreted (1). The problem here is that ECA.28 is an >> effective control meaning that ECA.28 for the guest is >> logically ANDed with the host's. If linux is running as a >> guest of z/VM and z/VM is sets ECA.28 to zero, >> then ECA.28 for the guest will also be zero, in which case >> every AP instruction executed on the guest will be intercepted. >> >> The only AP instruction that has an interception handler is >> PQAP with function code 0x03 (AP-queue interruption control), so >> this warning is being issued for all other AP instructions being >> intercepted; so, maybe this is the right thing to do? After all, >> running a linux as a guest of z/VM that is setting ECA.28 to zero is not >> a supported configuration. >> >> Having said that, the root of the problem is the fact that >> a guest is allowed to start without AP interpretive execution >> turned on because that is the only currently supported configuration. >> If there is a way to determine the effective value of ECA.28 for a >> KVM guest, when KVM could respond appropriately when QEMU >> queries whether the KVM_S390_VM_CRYPTO_ENABLE_APIE attribute >> is available in the CPU model. If it is not, then QEMU does not set the >> S390_FEAT_AP (AP instructions installed) feature and a guest started >> with cpu model feature ap='on' will fail to start. > I think the problem is that there is no way to find out the effective value > of ECA_APIE (and I think this could even change during the lifetime of a > guest). So I see 3 options: > 1. check for z/VM and do not advertise crypto (ap=on will always fail). This > will disable the possibility to pass through a pass through device. (I think > if the zVM guest has an adapter APDEDICATED then z/VM does set ECA_APIE) > 2. reject all crypto instructions that do exit and are not fc==3 (PQAP ACIQ). > This is kind of not ideal as we will pass through facility stfle.12 (PQAP QCI) > but then fail to handle it. Linux does handle faults on these instructions just > fine, though. > 3. Implement emulation of crypto. I think this not what we want to do, especially > as this only makes sense for acceleration but not for any of the secure key > or protected key schemes. > > The WARN_ON is certainly something that must go as long as we construct cases > that can trigger this. > > So I would suggest to go with the miminal patch (variant 2) which basically just > removes the WARN_ON. > We can then think about doing a nicer variant on top. > e.g. implement PQAP QCI that just returns an empty config. I will look into this. Agree that the WARN_ON shall be removed with the caveat that a better solution will be pursued in the future. Reviewed-by: Tony Krowiak