Received: by 2002:a05:6a10:413:0:0:0:0 with SMTP id 19csp1754499pxp; Mon, 7 Mar 2022 01:29:23 -0800 (PST) X-Google-Smtp-Source: ABdhPJz8LM5ErUOQURJQ2iEnb2e8jhPP+e7rv4uQVjNtrKot4PUzh5nIQwq+kXgqfDEnqp+wFVOd X-Received: by 2002:a05:6402:2365:b0:415:ed07:70de with SMTP id a5-20020a056402236500b00415ed0770demr10192761eda.150.1646645363502; Mon, 07 Mar 2022 01:29:23 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; t=1646645363; cv=none; d=google.com; s=arc-20160816; b=uTKzJZd0U6kjnX9g9BOsUtbfoDdv2uYcZAwR/+PWo+pOOVrkX3GUw4gC0qPI1O/RYS k8AxE/mC4r8whk2KjrG6g5ghMmRnfRESKEzClmdWWGGJQJ8y5ogYddBIoozbT04QEJgB I0ZRD5pRGwiEvWKuztGv85GDhvCITJy/t2qExMn/rh2TCK4TW0lM+c0ZLeuy3YW5PqUb vMCWaTb65wMDxpGHfDi4CRBZ9KMQ4BaRXz9zXt+bAcaCbuIumR2sBugmnkoQNWSuIjIi rfJCDeMmzHmo+dbW+jHQsnl9DNEZ414qsRPArgYiNGQNUfRbfIglIi/M5gLVYtYYIhPR rfOg== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:in-reply-to:content-disposition:mime-version :references:message-id:subject:cc:to:from:date:dkim-signature; bh=gil5ranxrEJQ6Leg6l42UoKvzbmcu5Ve8XhC1QPDDh8=; b=tqWLBVTvXA1iaf9VfXZ5mEHusY/iX+whCiSqTmxiJXZVF2KgYUNJC0RToc/KXMneT3 xRy6te4GMFpv5BgD7llksi1lCc2yTeGaJmMWuPR2UMlfd+9ScRqtLJ3/nO7TRQ6OIOHz xhK/whmCONjZdOp1eg8gkLa/PntXRm+fqiXVgPwgdlzgdsKeasE2rCsoyz0sCNWd7njj Bq9Ttfszvl3CUnxzAO3e91Uqa63TUhctEqi4xlDUzja6ENRD+FrtdkOF9WP/IfurBM1g 3njR2muoKwipaB42eW7emoxmILd0BrvB332HkVhus8DTT9jX+mm4RsgVNt5kgENkvJWE KPSA== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@google.com header.s=20210112 header.b=Y8HpHgHE; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=REJECT sp=REJECT dis=NONE) header.from=google.com Return-Path: Received: from out1.vger.email (out1.vger.email. [2620:137:e000::1:20]) by mx.google.com with ESMTP id gn24-20020a1709070d1800b006da6efe6f05si7895318ejc.132.2022.03.07.01.28.59; Mon, 07 Mar 2022 01:29:23 -0800 (PST) Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) client-ip=2620:137:e000::1:20; Authentication-Results: mx.google.com; dkim=pass header.i=@google.com header.s=20210112 header.b=Y8HpHgHE; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=REJECT sp=REJECT dis=NONE) header.from=google.com Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S234191AbiCFUIO (ORCPT + 99 others); Sun, 6 Mar 2022 15:08:14 -0500 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:59166 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S232908AbiCFUIM (ORCPT ); Sun, 6 Mar 2022 15:08:12 -0500 Received: from mail-pj1-x1035.google.com (mail-pj1-x1035.google.com [IPv6:2607:f8b0:4864:20::1035]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 94D4423BE1 for ; Sun, 6 Mar 2022 12:07:19 -0800 (PST) Received: by mail-pj1-x1035.google.com with SMTP id fs4-20020a17090af28400b001bf5624c0aaso1276794pjb.0 for ; Sun, 06 Mar 2022 12:07:19 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20210112; h=date:from:to:cc:subject:message-id:references:mime-version :content-disposition:in-reply-to; bh=gil5ranxrEJQ6Leg6l42UoKvzbmcu5Ve8XhC1QPDDh8=; b=Y8HpHgHECt/Zx/Om11L0P313HOLC4xvjSlEdMDGyN80Kbp6fI7BJUX4GMLqOEsro1t qwV8njf8GH/M0ju7kRVfUeyOyOOAni5GhoUw4Q/nT9ILPtzqiHzEBioYxda4UJSG9n/k sjii8cyE+T6B5lQKE5m3+mzV8BQI96TIMoDrAx27orzo2pOuCZSrnfOLtum1KkHOZii4 8iFGBLAEDRnEdLZi67NYTqVylV4DCQ277DIEBHppKAwBUL7Jc7Z44gtPhGgKh+6B2qDF 3NtcTdkirnZav2k7Zaw7B6tTO8tjWBYCrNFVulRmqz97qyaBGTDlYlEPLZcVva8C2idB bjKg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:date:from:to:cc:subject:message-id:references :mime-version:content-disposition:in-reply-to; bh=gil5ranxrEJQ6Leg6l42UoKvzbmcu5Ve8XhC1QPDDh8=; b=YabPZYj3lpur47pggim76AOZQDbZIbxSkjCtIbAcfdkraeF7pfVCV7mY58elt3c/vJ SJRF1V1amvDXQbStKO/qLraOJ5lWECdCU5dLlHB79QraWhdzfIOrNnQg4uW/XTTDxC02 AyfkW7L6niLOlSpVzXjUSny6LXP+BdxQSbbFBOTxCiy0p0v5H951l7dDIHh+vP2MC/NH rgq6JUz1trjPegH7j9zBbNvFEKgns3aHJJIjj9ITCiRV16esLW2Xi8Pcx40814dW9XbO 1p/VjEgowiqTyVF+1DImLnGHJopKEKIhnmyMJ8r8leHOpoALCJbM+sBNmBcdw3iH1ZBU ncCw== X-Gm-Message-State: AOAM530FYfOCT7Qt1SHRZ4afKk3QqraUWrSvRZ0MTa6Bbpv6hdnV/i6P tvQmR0b1lUd7eJRg5OVR2wdqOw== X-Received: by 2002:a17:902:aa8d:b0:150:c60:29a4 with SMTP id d13-20020a170902aa8d00b001500c6029a4mr9015870plr.40.1646597238817; Sun, 06 Mar 2022 12:07:18 -0800 (PST) Received: from google.com (226.75.127.34.bc.googleusercontent.com. [34.127.75.226]) by smtp.gmail.com with ESMTPSA id p16-20020a056a000b5000b004f669806cd9sm13318385pfo.87.2022.03.06.12.07.18 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Sun, 06 Mar 2022 12:07:18 -0800 (PST) Date: Sun, 6 Mar 2022 20:07:14 +0000 From: Mingwei Zhang To: Nikunj A Dadhania Cc: Paolo Bonzini , Sean Christopherson , Vitaly Kuznetsov , Wanpeng Li , Jim Mattson , Joerg Roedel , Brijesh Singh , Tom Lendacky , Peter Gonda , kvm@vger.kernel.org, linux-kernel@vger.kernel.org Subject: Re: [RFC PATCH 0/6] KVM: SVM: Defer page pinning for SEV guests Message-ID: References: <20220118110621.62462-1-nikunj@amd.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20220118110621.62462-1-nikunj@amd.com> X-Spam-Status: No, score=-17.6 required=5.0 tests=BAYES_00,DKIMWL_WL_MED, DKIM_SIGNED,DKIM_VALID,DKIM_VALID_AU,DKIM_VALID_EF, ENV_AND_HDR_SPF_MATCH,RCVD_IN_DNSWL_NONE,SPF_HELO_NONE,SPF_PASS, T_SCC_BODY_TEXT_LINE,USER_IN_DEF_DKIM_WL,USER_IN_DEF_SPF_WL autolearn=ham autolearn_force=no version=3.4.6 X-Spam-Checker-Version: SpamAssassin 3.4.6 (2021-04-09) on lindbergh.monkeyblade.net Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Tue, Jan 18, 2022, Nikunj A Dadhania wrote: > SEV guest requires the guest's pages to be pinned in host physical > memory as migration of encrypted pages is not supported. The memory > encryption scheme uses the physical address of the memory being > encrypted. If guest pages are moved by the host, content decrypted in > the guest would be incorrect thereby corrupting guest's memory. > > For SEV/SEV-ES guests, the hypervisor doesn't know which pages are > encrypted and when the guest is done using those pages. Hypervisor > should treat all the guest pages as encrypted until the guest is > destroyed. "Hypervisor should treat all the guest pages as encrypted until they are deallocated or the guest is destroyed". Note: in general, the guest VM could ask the user-level VMM to free the page by either free the memslot or free the pages (munmap(2)). > > Actual pinning management is handled by vendor code via new > kvm_x86_ops hooks. MMU calls in to vendor code to pin the page on > demand. Metadata of the pinning is stored in architecture specific > memslot area. During the memslot freeing path guest pages are > unpinned. "During the memslot freeing path and deallocation path" > > Initially started with [1], where the idea was to store the pinning > information using the software bit in the SPTE to track the pinned > page. That is not feasible for the following reason: > > The pinned SPTE information gets stored in the shadow pages(SP). The > way current MMU is designed, the full MMU context gets dropped > multiple number of times even when CR0.WP bit gets flipped. Due to > dropping of the MMU context (aka roots), there is a huge amount of SP > alloc/remove churn. Pinned information stored in the SP gets lost > during the dropping of the root and subsequent SP at the child levels. > Without this information making decisions about re-pinnning page or > unpinning during the guest shutdown will not be possible > > [1] https://patchwork.kernel.org/project/kvm/cover/20200731212323.21746-1-sean.j.christopherson@intel.com/ > A general feedback: I really like this patch set and I think doing memory pinning at fault path in kernel and storing the metadata in memslot is the right thing to do. This basically solves all the problems triggered by the KVM based API that trusts the user-level VMM to do the memory pinning. Thanks. > Nikunj A Dadhania (4): > KVM: x86/mmu: Add hook to pin PFNs on demand in MMU > KVM: SVM: Add pinning metadata in the arch memslot > KVM: SVM: Implement demand page pinning > KVM: SEV: Carve out routine for allocation of pages > > Sean Christopherson (2): > KVM: x86/mmu: Introduce kvm_mmu_map_tdp_page() for use by SEV/TDX > KVM: SVM: Pin SEV pages in MMU during sev_launch_update_data() > > arch/x86/include/asm/kvm-x86-ops.h | 3 + > arch/x86/include/asm/kvm_host.h | 9 + > arch/x86/kvm/mmu.h | 3 + > arch/x86/kvm/mmu/mmu.c | 41 +++ > arch/x86/kvm/mmu/tdp_mmu.c | 7 + > arch/x86/kvm/svm/sev.c | 423 +++++++++++++++++++---------- > arch/x86/kvm/svm/svm.c | 4 + > arch/x86/kvm/svm/svm.h | 9 +- > arch/x86/kvm/x86.c | 11 +- > 9 files changed, 359 insertions(+), 151 deletions(-) > > -- > 2.32.0 >