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.4 required=3.0 tests=DKIM_SIGNED,DKIM_VALID, DKIM_VALID_AU,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 6534AC43331 for ; Mon, 11 Nov 2019 05:28:17 +0000 (UTC) Received: from kanga.kvack.org (kanga.kvack.org [205.233.56.17]) by mail.kernel.org (Postfix) with ESMTP id 2063A20656 for ; Mon, 11 Nov 2019 05:28:17 +0000 (UTC) Authentication-Results: mail.kernel.org; dkim=pass (2048-bit key) header.d=ozlabs.org header.i=@ozlabs.org header.b="tzO9kkm+" DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org 2063A20656 Authentication-Results: mail.kernel.org; dmarc=fail (p=none dis=none) header.from=ozlabs.org Authentication-Results: mail.kernel.org; spf=pass smtp.mailfrom=owner-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix) id AD4816B0005; Mon, 11 Nov 2019 00:28:16 -0500 (EST) Received: by kanga.kvack.org (Postfix, from userid 40) id A5D676B0006; Mon, 11 Nov 2019 00:28:16 -0500 (EST) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 94C106B0007; Mon, 11 Nov 2019 00:28:16 -0500 (EST) X-Delivered-To: linux-mm@kvack.org Received: from forelay.hostedemail.com (smtprelay0205.hostedemail.com [216.40.44.205]) by kanga.kvack.org (Postfix) with ESMTP id 7F93F6B0005 for ; Mon, 11 Nov 2019 00:28:16 -0500 (EST) Received: from smtpin05.hostedemail.com (10.5.19.251.rfc1918.com [10.5.19.251]) by forelay02.hostedemail.com (Postfix) with SMTP id 219B84417 for ; Mon, 11 Nov 2019 05:28:16 +0000 (UTC) X-FDA: 76142865792.05.river26_de9264f82748 X-HE-Tag: river26_de9264f82748 X-Filterd-Recvd-Size: 3051 Received: from ozlabs.org (bilbo.ozlabs.org [203.11.71.1]) by imf42.hostedemail.com (Postfix) with ESMTP for ; Mon, 11 Nov 2019 05:28:15 +0000 (UTC) Received: by ozlabs.org (Postfix, from userid 1003) id 47BKCY6XtWz9sPn; Mon, 11 Nov 2019 16:28:09 +1100 (AEDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=ozlabs.org; s=201707; t=1573450089; bh=Gk49bVSafO6qIOkqpX6nJCaX1ioKZx1OXiY1Eid0yQc=; h=Date:From:To:Cc:Subject:References:In-Reply-To:From; b=tzO9kkm++WvSl259JyipYeMhoPff9fwIU5yZswgTFotSFTW8+QyqmIoXIsPh8/GWx C1d7HZsIxm7gjhzHagA36jMYph6dSnsKJu4vtzSQpp/NvijxvGXUd14h13HucKCJnV P/Y+PyMcPtwNQr2pqrJgmCD9OmL7bQaTwBiW+p3Lne0GkchrCKb6S2sP+Je+g3YgQp 1zMuYge180wtE6ElW8JGmUgzb6CjWrpCCFL4TD1w6KshiemCO4opWIUzd6F+TVNquI qvtQ5FLv7KjaWBTKtAVWDy9a5bbcZCaJp1jxbphDRimvSNLEWgwj8xGkbf7PM+HiaL aS+a880rDPU/Q== Date: Mon, 11 Nov 2019 16:28:06 +1100 From: Paul Mackerras To: Bharata B Rao Cc: 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, linuxram@us.ibm.com, sukadev@linux.vnet.ibm.com, hch@lst.de Subject: Re: [PATCH v10 6/8] KVM: PPC: Support reset of secure guest Message-ID: <20191111052806.GC4017@oak.ozlabs.ibm.com> References: <20191104041800.24527-1-bharata@linux.ibm.com> <20191104041800.24527-7-bharata@linux.ibm.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20191104041800.24527-7-bharata@linux.ibm.com> User-Agent: Mutt/1.10.1 (2018-07-13) X-Bogosity: Ham, tests=bogofilter, spamicity=0.000128, version=1.2.4 Sender: owner-linux-mm@kvack.org Precedence: bulk X-Loop: owner-majordomo@kvack.org List-ID: On Mon, Nov 04, 2019 at 09:47:58AM +0530, Bharata B Rao wrote: > Add support for reset of secure guest via a new ioctl KVM_PPC_SVM_OFF. > This ioctl will be issued by QEMU during reset and includes the > the following steps: > > - Ask UV to terminate the guest via UV_SVM_TERMINATE ucall > - Unpin the VPA pages so that they can be migrated back to secure > side when guest becomes secure again. This is required because > pinned pages can't be migrated. Unpinning the VPA pages is normally handled during VM reset by QEMU doing set_one_reg operations to set the values for the KVM_REG_PPC_VPA_ADDR, KVM_REG_PPC_VPA_SLB and KVM_REG_PPC_VPA_DTL pseudo-registers to zero. Is there some reason why this isn't happening for a secure VM, and if so, what is that reason? If it is happening, then why do we need to unpin the pages explicitly here? > - Reinitialize guest's partitioned scoped page tables. These are > freed when guest becomes secure (H_SVM_INIT_DONE) It doesn't seem particularly useful to me to free the partition-scoped page tables when the guest becomes secure, and it feels like it makes things more fragile. If you don't free them then, then you don't need to reallocate them now. > - Release all device pages of the secure guest. > > After these steps, guest is ready to issue UV_ESM call once again > to switch to secure mode. Paul.