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=-11.6 required=3.0 tests=BAYES_00,DKIMWL_WL_MED, DKIM_SIGNED,DKIM_VALID,DKIM_VALID_AU,FSL_HELO_FAKE, HEADER_FROM_DIFFERENT_DOMAINS,MAILING_LIST_MULTI,SPF_HELO_NONE,SPF_PASS, USER_IN_DEF_DKIM_WL 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 B3D27C07E95 for ; Mon, 19 Jul 2021 16:54:52 +0000 (UTC) Received: from kanga.kvack.org (kanga.kvack.org [205.233.56.17]) by mail.kernel.org (Postfix) with ESMTP id 31E3761002 for ; Mon, 19 Jul 2021 16:54:52 +0000 (UTC) DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org 31E3761002 Authentication-Results: mail.kernel.org; dmarc=fail (p=reject dis=none) header.from=google.com Authentication-Results: mail.kernel.org; spf=pass smtp.mailfrom=owner-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix) id B5D778D00EC; Mon, 19 Jul 2021 12:54:52 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id B33ED6B019D; Mon, 19 Jul 2021 12:54:52 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 9D3D98D00EC; Mon, 19 Jul 2021 12:54:52 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from forelay.hostedemail.com (smtprelay0173.hostedemail.com [216.40.44.173]) by kanga.kvack.org (Postfix) with ESMTP id 748AA6B019C for ; Mon, 19 Jul 2021 12:54:52 -0400 (EDT) Received: from smtpin19.hostedemail.com (10.5.19.251.rfc1918.com [10.5.19.251]) by forelay05.hostedemail.com (Postfix) with ESMTP id 18AA6184956E7 for ; Mon, 19 Jul 2021 16:54:51 +0000 (UTC) X-FDA: 78379936782.19.2E9F7B4 Received: from mail-pf1-f180.google.com (mail-pf1-f180.google.com [209.85.210.180]) by imf14.hostedemail.com (Postfix) with ESMTP id DC0C6600198C for ; Mon, 19 Jul 2021 16:54:50 +0000 (UTC) Received: by mail-pf1-f180.google.com with SMTP id q10so16977228pfj.12 for ; Mon, 19 Jul 2021 09:54:50 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20161025; h=date:from:to:cc:subject:message-id:references:mime-version :content-disposition:in-reply-to; bh=pHb5bkAVRB42TqiPWwfLPH1AL+uUpnACNe29QjGSxaY=; b=wWjAGEqCZT2SqkCZwd6sWt/7nsE3FDiXvtXZl03cKrrWqWxHoKPQIrsffQjKJ13WG3 EtmnIKLF+iUOmpw/nICZRgWdRYzg5CVsZ4JGG31bckuuXW2KmDIrtW0aUWPbywlk+Re+ ysYfGknbrkm6/fCX4e++AOlHrp85izifA31B0RM/WNmTyYeytvj3aGvaPOIheZbXd6Qg +f65RrcEPsNUtrQthvx/IqpwUYrZZlqBFKSDm3xxgdP4+/YqaSNRZrvRYVhpZxne3Fe3 4pVNYC8FKZniaUHFqa3DGzuzMaVvBRv5hVoqiViY8Pgmw9z/gHkKcxQSKlLSDnwzB6Eb AujA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:date:from:to:cc:subject:message-id:references :mime-version:content-disposition:in-reply-to; bh=pHb5bkAVRB42TqiPWwfLPH1AL+uUpnACNe29QjGSxaY=; b=Np8xraOvowOaKl2hiTRfEkbHHEOC5X9nmWnt38d6ChmH2MKqeSH4H26jxV7UjNm2uL WxeqjLgOWxzmthmTqoHV0P7q1M8cuIUn3WD2+gg/jxMqs+vlXkJ/hbs3WyNtoga2mTj+ FMgZqj12zOXFwcCykIhS/kY6pkIzThCa0EVQ3xT2SrY4HY0tjonFqoDf9f6RmXZ1EdW3 YxoUDevv1nIxBAiabhCbjPn74VZ7tN6ujCLwzqN73+VoWxEEmn94Rc/DbggheTW8unwx cSgNowiUNoe3MgYjHJcX6PbvgMCYL1S97HYzyHv0FZ58RuyHZVftmyFmNAWsnPbTWjGb nI4A== X-Gm-Message-State: AOAM531ViFfjGb2SiQwlexorsQCaXRmoEceB3PopCUjBtcC7xaA+mJ14 Cq02Cwa1A4CXaHmFPXxCmFjNyQ== X-Google-Smtp-Source: ABdhPJzjdliagIIxw89Ud0WLqDwORLqyx5dLKpfYjX5Qr2Jo5aV2ovPM9l2YmkMyXrKafSxH6Usw+Q== X-Received: by 2002:a65:648f:: with SMTP id e15mr26154606pgv.165.1626713689551; Mon, 19 Jul 2021 09:54:49 -0700 (PDT) Received: from google.com (157.214.185.35.bc.googleusercontent.com. [35.185.214.157]) by smtp.gmail.com with ESMTPSA id q11sm25570pjd.30.2021.07.19.09.54.48 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Mon, 19 Jul 2021 09:54:48 -0700 (PDT) Date: Mon, 19 Jul 2021 16:54:45 +0000 From: Sean Christopherson To: Brijesh Singh Cc: x86@kernel.org, linux-kernel@vger.kernel.org, kvm@vger.kernel.org, linux-efi@vger.kernel.org, platform-driver-x86@vger.kernel.org, linux-coco@lists.linux.dev, linux-mm@kvack.org, linux-crypto@vger.kernel.org, Thomas Gleixner , Ingo Molnar , Joerg Roedel , Tom Lendacky , "H. Peter Anvin" , Ard Biesheuvel , Paolo Bonzini , Vitaly Kuznetsov , Wanpeng Li , Jim Mattson , Andy Lutomirski , Dave Hansen , Sergio Lopez , Peter Gonda , Peter Zijlstra , Srinivas Pandruvada , David Rientjes , Dov Murik , Tobin Feldman-Fitzthum , Borislav Petkov , Michael Roth , Vlastimil Babka , tony.luck@intel.com, npmccallum@redhat.com, brijesh.ksingh@gmail.com Subject: Re: [PATCH Part2 RFC v4 26/40] KVM: SVM: Add KVM_SEV_SNP_LAUNCH_FINISH command Message-ID: References: <20210707183616.5620-1-brijesh.singh@amd.com> <20210707183616.5620-27-brijesh.singh@amd.com> <9ee5a991-3e43-3489-5ee1-ff8c66cfabc1@amd.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <9ee5a991-3e43-3489-5ee1-ff8c66cfabc1@amd.com> X-Rspamd-Server: rspam06 X-Rspamd-Queue-Id: DC0C6600198C X-Stat-Signature: qw4a8ckm1m9q594xmt81gfk7nk6nnds9 Authentication-Results: imf14.hostedemail.com; dkim=pass header.d=google.com header.s=20161025 header.b=wWjAGEqC; spf=pass (imf14.hostedemail.com: domain of seanjc@google.com designates 209.85.210.180 as permitted sender) smtp.mailfrom=seanjc@google.com; dmarc=pass (policy=reject) header.from=google.com X-HE-Tag: 1626713690-480975 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 Fri, Jul 16, 2021, Brijesh Singh wrote: > > On 7/16/21 3:18 PM, Sean Christopherson wrote: > > On Wed, Jul 07, 2021, Brijesh Singh wrote: > >> + data->gctx_paddr = __psp_pa(sev->snp_context); > >> + ret = sev_issue_cmd(kvm, SEV_CMD_SNP_LAUNCH_FINISH, data, &argp->error); > > Shouldn't KVM unwind everything it did if LAUNCH_FINISH fails? And if that's > > not possible, take steps to make the VM unusable? > > Well, I am not sure if VM need to unwind. If the command fail but VMM decide > to ignore the error then VMRUN will probably fail and user will get the KVM > shutdown event. The LAUNCH_FINISH command finalizes the VM launch process, > the firmware will probably not load the memory encryption keys until it moves > to the running state. Within reason, KVM needs to provide consistent, deterministic behavior. Yes, more than likely failure at this point will be fatal to the VM, but that doesn't justify leaving the VM in a random/bogus state. In addition to being a poor ABI, it also makes it more difficult to reason about what is/isn't possible in KVM. > >> + */ > >> + if (sev_snp_guest(vcpu->kvm)) { > >> + struct rmpupdate e = {}; > >> + int rc; > >> + > >> + rc = rmpupdate(virt_to_page(svm->vmsa), &e); > > So why does this not need to go through snp_page_reclaim()? > > As I said in previous comments that by default all the memory is in the > hypervisor state. if the rmpupdate() failed that means nothing is changed in > the RMP and there is no need to reclaim. The reclaim is required only if the > pages are assigned in the RMP table. I wasn't referring to RMPUPDATE failing here (or anywhere). This is the vCPU free path, which I think means the svm->vmsa page was successfully updated in the RMP during LAUNCH_UPDATE. snp_launch_update_vmsa() goes through snp_page_reclaim() on LAUNCH_UPDATE failure, whereas this happy path does not. Is there some other transition during teardown that obviastes the need for reclaim? If so, a comment to explain that would be very helpful.