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=-2.2 required=3.0 tests=HEADER_FROM_DIFFERENT_DOMAINS, MAILING_LIST_MULTI,SPF_HELO_NONE,SPF_PASS,USER_AGENT_SANE_1 autolearn=no 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 F37C0C432C3 for ; Thu, 14 Nov 2019 07:02:38 +0000 (UTC) Received: from kanga.kvack.org (kanga.kvack.org [205.233.56.17]) by mail.kernel.org (Postfix) with ESMTP id 8E8532071B for ; Thu, 14 Nov 2019 07:02:38 +0000 (UTC) DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org 8E8532071B Authentication-Results: mail.kernel.org; dmarc=fail (p=none dis=none) header.from=us.ibm.com Authentication-Results: mail.kernel.org; spf=pass smtp.mailfrom=owner-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix) id E87636B0003; Thu, 14 Nov 2019 02:02:37 -0500 (EST) Received: by kanga.kvack.org (Postfix, from userid 40) id E5DFE6B0005; Thu, 14 Nov 2019 02:02:37 -0500 (EST) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id D74286B0006; Thu, 14 Nov 2019 02:02:37 -0500 (EST) X-Delivered-To: linux-mm@kvack.org Received: from forelay.hostedemail.com (smtprelay0180.hostedemail.com [216.40.44.180]) by kanga.kvack.org (Postfix) with ESMTP id C474C6B0003 for ; Thu, 14 Nov 2019 02:02:37 -0500 (EST) Received: from smtpin19.hostedemail.com (10.5.19.251.rfc1918.com [10.5.19.251]) by forelay02.hostedemail.com (Postfix) with SMTP id 81A3062D0 for ; Thu, 14 Nov 2019 07:02:37 +0000 (UTC) X-FDA: 76153989954.19.burn71_8b3a6feb93444 X-HE-Tag: burn71_8b3a6feb93444 X-Filterd-Recvd-Size: 8428 Received: from mx0a-001b2d01.pphosted.com (mx0b-001b2d01.pphosted.com [148.163.158.5]) by imf16.hostedemail.com (Postfix) with ESMTP for ; Thu, 14 Nov 2019 07:02:36 +0000 (UTC) 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 xAE6vi92006057 for ; Thu, 14 Nov 2019 02:02:35 -0500 Received: from e06smtp02.uk.ibm.com (e06smtp02.uk.ibm.com [195.75.94.98]) by mx0a-001b2d01.pphosted.com with ESMTP id 2w90uvjevm-1 (version=TLSv1.2 cipher=AES256-GCM-SHA384 bits=256 verify=NOT) for ; Thu, 14 Nov 2019 02:02:35 -0500 Received: from localhost by e06smtp02.uk.ibm.com with IBM ESMTP SMTP Gateway: Authorized Use Only! Violators will be prosecuted for from ; Thu, 14 Nov 2019 07:02:33 -0000 Received: from b06cxnps4076.portsmouth.uk.ibm.com (9.149.109.198) by e06smtp02.uk.ibm.com (192.168.101.132) with IBM ESMTP SMTP Gateway: Authorized Use Only! Violators will be prosecuted; (version=TLSv1/SSLv3 cipher=AES256-GCM-SHA384 bits=256/256) Thu, 14 Nov 2019 07:02:30 -0000 Received: from d06av25.portsmouth.uk.ibm.com (d06av25.portsmouth.uk.ibm.com [9.149.105.61]) by b06cxnps4076.portsmouth.uk.ibm.com (8.14.9/8.14.9/NCO v10.0) with ESMTP id xAE72SfB53411984 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=OK); Thu, 14 Nov 2019 07:02:29 GMT Received: from d06av25.portsmouth.uk.ibm.com (unknown [127.0.0.1]) by IMSVA (Postfix) with ESMTP id D13F711C06F; Thu, 14 Nov 2019 07:02:28 +0000 (GMT) Received: from d06av25.portsmouth.uk.ibm.com (unknown [127.0.0.1]) by IMSVA (Postfix) with ESMTP id A994111C050; Thu, 14 Nov 2019 07:02:25 +0000 (GMT) Received: from oc0525413822.ibm.com (unknown [9.85.181.122]) by d06av25.portsmouth.uk.ibm.com (Postfix) with ESMTPS; Thu, 14 Nov 2019 07:02:25 +0000 (GMT) Date: Wed, 13 Nov 2019 23:02:22 -0800 From: Ram Pai To: Paul Mackerras Cc: Bharata B Rao , linuxppc-dev@lists.ozlabs.org, kvm-ppc@vger.kernel.org, linux-mm@kvack.org, paulus@au1.ibm.com, aneesh.kumar@linux.vnet.ibm.com, jglisse@redhat.com, cclaudio@linux.ibm.com, sukadev@linux.vnet.ibm.com, hch@lst.de, Sukadev Bhattiprolu , Ram Pai Subject: Re: [PATCH v10 7/8] KVM: PPC: Implement H_SVM_INIT_ABORT hcall Reply-To: Ram Pai References: <20191112010158.GB5159@oc0525413822.ibm.com> <20191112053836.GB10885@oak.ozlabs.ibm.com> <20191112075215.GD5159@oc0525413822.ibm.com> <20191112113204.GA10178@blackberry> <20191112144555.GE5159@oc0525413822.ibm.com> <20191113001427.GA17829@oak.ozlabs.ibm.com> <20191113063233.GF5159@oc0525413822.ibm.com> <20191113211824.GA20535@blackberry> <20191113215042.GG5159@oc0525413822.ibm.com> <20191114050825.GB28382@oak.ozlabs.ibm.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20191114050825.GB28382@oak.ozlabs.ibm.com> User-Agent: Mutt/1.5.21 (2010-09-15) X-TM-AS-GCONF: 00 x-cbid: 19111407-0008-0000-0000-0000032EE21E X-IBM-AV-DETECTION: SAVI=unused REMOTE=unused XFE=unused x-cbparentid: 19111407-0009-0000-0000-00004A4DEF1E Message-Id: <20191114070222.GH5159@oc0525413822.ibm.com> X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10434:,, definitions=2019-11-14_01:,, 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-1910280000 definitions=main-1911140065 X-Bogosity: Ham, tests=bogofilter, spamicity=0.000000, version=1.2.4 Sender: owner-linux-mm@kvack.org Precedence: bulk X-Loop: owner-majordomo@kvack.org List-ID: On Thu, Nov 14, 2019 at 04:08:25PM +1100, Paul Mackerras wrote: > On Wed, Nov 13, 2019 at 01:50:42PM -0800, Ram Pai wrote: > > On Thu, Nov 14, 2019 at 08:18:24AM +1100, Paul Mackerras wrote: > > > On Tue, Nov 12, 2019 at 10:32:33PM -0800, Ram Pai wrote: > > > > On Wed, Nov 13, 2019 at 11:14:27AM +1100, Paul Mackerras wrote: > > > > > On Tue, Nov 12, 2019 at 06:45:55AM -0800, Ram Pai wrote: > > > > > > On Tue, Nov 12, 2019 at 10:32:04PM +1100, Paul Mackerras wrote: > > > > > > > On Mon, Nov 11, 2019 at 11:52:15PM -0800, Ram Pai wrote: > > > > > > > > There is subtle problem removing that code from the assembly. > > > > > > > > > > > > > > > > If the H_SVM_INIT_ABORT hcall returns to the ultravisor without clearing > > > > > > > > kvm->arch.secure_guest, the hypervisor will continue to think that the > > > > > > > > VM is a secure VM. However the primary reason the H_SVM_INIT_ABORT > > > > > > > > hcall was invoked, was to inform the Hypervisor that it should no longer > > > > > > > > consider the VM as a Secure VM. So there is a inconsistency there. > > > > > > > > > > > > > > Most of the checks that look at whether a VM is a secure VM use code > > > > > > > like "if (kvm->arch.secure_guest & KVMPPC_SECURE_INIT_DONE)". Now > > > > > > > since KVMPPC_SECURE_INIT_ABORT is 4, an if statement such as that will > > > > > > > take the false branch once we have set kvm->arch.secure_guest to > > > > > > > KVMPPC_SECURE_INIT_ABORT in kvmppc_h_svm_init_abort. So in fact in > > > > > > > most places we will treat the VM as a normal VM from then on. If > > > > > > > there are any places where we still need to treat the VM as a secure > > > > > > > VM while we are processing the abort we can easily do that too. > > > > > > > > > > > > Is the suggestion -- KVMPPC_SECURE_INIT_ABORT should never return back > > > > > > to the Ultravisor? Because removing that assembly code will NOT lead the > > > > > > > > > > No. The suggestion is that vcpu->arch.secure_guest stays set to > > > > > KVMPPC_SECURE_INIT_ABORT until userspace calls KVM_PPC_SVM_OFF. > > > > > > > > In the fast_guest_return path, if it finds > > > > (kvm->arch.secure_guest & KVMPPC_SECURE_INIT_ABORT) is true, should it return to > > > > UV or not? > > > > > > > > Ideally it should return back to the ultravisor the first time > > > > KVMPPC_SECURE_INIT_ABORT is set, and not than onwards. > > > > > > What is ideal about that behavior? Why would that be a particularly > > > good thing to do? > > > > It is following the rule -- "return back to the caller". > > That doesn't address the question of why vcpu->arch.secure_guest > should be cleared at the point where we do that. Ok. here is the sequence that I expect to happen. ------------------------------------------------------------------- 1) VM makes a ESM(Enter Secure Mode) ucall. 1A) UV does the H_SVM_INIT_START hcall... the chit-chat between UV and HV happens and somewhere in that chit-chat, UV decides that the ESM call cannot be successfully completed. Hence it calls H_SVM_INIT_ABORT to inform the Hypervisor. 1A_a) Hypervisor aborts the VM's transition and returns back to the ultravisor. 1B) UV cleans up the state of the VM on its side and returns back to the VM, with failure. VM is still in a normal VM state. Its MSR(S) is still 0. 2) VM gets a HDEC exception. 2A) Hypervisor receives that HDEC exception. It handles the exception and returns back to the VM. ------------------------------------------------------------------- If you agree with the above sequence than, the patch needs all the proposed changes. At step (1A_a) and step (2A), the hypervisor is faced with the question -- Where should the control be returned to? for step 1A_a it has to return to the UV, and for step 2A it has to return to the VM. In other words the control has to **return back to the caller**. It certainly has to rely on the vcpu->arch.secure_guest flag to do so. If any flag in vcpu->arch.secure_guest is set, it has to return to UV. Otherwise it has to return to VM. This is the reason, the proposed patch in the fast_guest_return path looks at the vcpu->arch.secure_guest. If it finds any flag set, it returns to UV. However before returning to UV, it also clears all the flags if H_SVM_INIT_ABORT is set. This is to ensure that HV does not return to the wrong place; i.e to UV, but returns to the VM at step 2A. RP