Received: by 2002:a05:6359:c8b:b0:c7:702f:21d4 with SMTP id go11csp2869312rwb; Mon, 19 Sep 2022 11:10:46 -0700 (PDT) X-Google-Smtp-Source: AMsMyM5Uolnc5NFnjs/IbYZH4rChfQ6aOWWy7L1Qday2i6T6CeUT+LJ+AuDzymz8T1Gt3xtjHFRt X-Received: by 2002:a63:2c2:0:b0:439:4581:d2af with SMTP id 185-20020a6302c2000000b004394581d2afmr16760707pgc.497.1663611046113; Mon, 19 Sep 2022 11:10:46 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1663611046; cv=none; d=google.com; s=arc-20160816; b=SxgO0p1mifmjBXFYWkcwcordrCskckdfb5w7rRbg60DdY2fo7bNqR3dwNdaTjfI641 Jg+MB+mPdpmuR5lE6FnoeIAfhVqDCg/O3oR+7zD+h7UAWQBACuVcq22HFi2j76leJwh5 C5/ynA1woR/nL20rN0Z0/reDl7i8lZFQ3NOsFqXtVZIiKhzIKw04IP151bQS28pB2De8 9NfFJQrvXQzGGUvU/qCcKz+XK+Fc23WN8PiUBl9jNLg5t1J2uvAkRRGuxCqiIAjJvfG4 48s2akgajcM17QpCR9VtVcbRdRaQGoh0Dvq6vH10sQejJGD3/4waw7zqyN7uGjVXke+W xKBw== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:cc:to:subject:message-id:date:from:in-reply-to :references:mime-version:dkim-signature; bh=/cf7B/KTsLD75IcdMZipBXm6ofpyaTAcEkMwbp5iR00=; b=NrbMUtDDz1RwHICCKxfZCxuBT1v0O4vZ2L8l8jk+im1+6FAp5DuVS5a5JslyMW+r2s KOFJ4cje8NyoHNG2jAuTaXNacyxZHHXkxwnzWWW7qNK0rjeZcZnHBOxvtjq1jKCgm/Tp JmA+/U4ZstyOpGlbcPS1e5+qnY+J6tvkUyVQiM+jTA7XylL3X3FsFkSIzdkX1EDMF5UD XfB/D/pA0h73C2/rniWVv6A0d66QZyHZizumLw2PWL/Bevpt5cTF7HPdO688/up6C0mQ y4hb6C8Omdk/oNx3qTueh5biXLFNmX+AH9pukCt1LB7ujbyaFrgiSPKCVz+W57o1eGD2 +Ngw== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@google.com header.s=20210112 header.b=R8mhDvft; spf=pass (google.com: domain of linux-crypto-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) smtp.mailfrom=linux-crypto-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 c1-20020aa79521000000b00535c451053esi28997822pfp.296.2022.09.19.11.10.25; Mon, 19 Sep 2022 11:10:46 -0700 (PDT) Received-SPF: pass (google.com: domain of linux-crypto-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=R8mhDvft; spf=pass (google.com: domain of linux-crypto-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) smtp.mailfrom=linux-crypto-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 S229741AbiISRyI (ORCPT + 99 others); Mon, 19 Sep 2022 13:54:08 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:43650 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S229762AbiISRyG (ORCPT ); Mon, 19 Sep 2022 13:54:06 -0400 Received: from mail-il1-x136.google.com (mail-il1-x136.google.com [IPv6:2607:f8b0:4864:20::136]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 74ADA4457F for ; Mon, 19 Sep 2022 10:54:02 -0700 (PDT) Received: by mail-il1-x136.google.com with SMTP id a9so49505ilh.1 for ; Mon, 19 Sep 2022 10:54:02 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20210112; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:from:to:cc:subject:date; bh=/cf7B/KTsLD75IcdMZipBXm6ofpyaTAcEkMwbp5iR00=; b=R8mhDvftQzWNGK0iyvTa9nSIWZrFtnkIInr7JSr2ggsBoL0OTaAAJ8tWbpkuAvy5uz /KUqKCF6s6xS0GQg0bWo7WW2V5rhJSdcyvJdj3QJ8g7jcGbxnddmPgRlFFig95paopv9 JJitEjoyNVAtyNOz4042FtJmsLF6F0qY3daW/gDjQH/PduCqhXQvCb4a4wsPlcIyO9d2 OO/7Mv1YzGbaTOiX3ImsaQ+5viwPfIzfyLecupDW8Q+rHJrno580i7K6KH0ODQsvfAYl 5W6sni6L8cuSeTVcAsYL23+NoDAUfHl1n82XX047aOmMYGSl7IPD6AXuHbyOys0rn2Ji ZM2Q== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:x-gm-message-state:from:to:cc:subject:date; bh=/cf7B/KTsLD75IcdMZipBXm6ofpyaTAcEkMwbp5iR00=; b=bS2eeqTk2E/M/tVkzFhSpLBHA+/x585bjzapht5Dezj9VY968iwVKeA8bKQxEZs6h5 RG+goETCqi4/oTXviTbkj88/hmO2/mim4Mw7nftLMmh8/GVmjUSylGsyK9PLImVmxCdH CM0GPZlJuI/zFz9+tD/R1WBliuE+nlJxv7n1YVCQ2+tZK5XSObzc3o4tx3UFA2et+zOH WSWytUnQjTBqXQ49O6Pvob4UbuuZZxELmsTNIeKJyUZEq+EMQQ0/TEH1MvVi9RGS7IZU hpLzgRtXPuQL+rX/deZHBOlV2Oc4fV0Wo2eE8FGTgXPH4m3WTL/O4DP4ifikHk1hnWsz YEhg== X-Gm-Message-State: ACrzQf2dYV60dPJqqei0inPwMOAMbXk7a8gjVdDM7j3ffhGWJ9YXfVid rkX21Uzpf8I+9wHRKwhW2EVVt55wHuuYV7wicpzxMQ== X-Received: by 2002:a92:ca49:0:b0:2f5:30:bfc1 with SMTP id q9-20020a92ca49000000b002f50030bfc1mr6478814ilo.224.1663610040996; Mon, 19 Sep 2022 10:54:00 -0700 (PDT) MIME-Version: 1.0 References: <78e30b5a25c926fcfdcaafea3d484f1bb25f20b9.1655761627.git.ashish.kalra@amd.com> In-Reply-To: From: Alper Gun Date: Mon, 19 Sep 2022 10:53:49 -0700 Message-ID: Subject: Re: [PATCH Part2 v6 37/49] KVM: SVM: Add support to handle MSR based Page State Change VMGEXIT To: Peter Gonda Cc: Ashish Kalra , "the arch/x86 maintainers" , LKML , kvm list , linux-coco@lists.linux.dev, Linux Memory Management List , Linux Crypto Mailing List , Thomas Gleixner , Ingo Molnar , Joerg Roedel , "Lendacky, Thomas" , "H. Peter Anvin" , Ard Biesheuvel , Paolo Bonzini , Sean Christopherson , Vitaly Kuznetsov , Jim Mattson , Andy Lutomirski , Dave Hansen , Sergio Lopez , Peter Zijlstra , Srinivas Pandruvada , David Rientjes , Dov Murik , Tobin Feldman-Fitzthum , Borislav Petkov , Michael Roth , Vlastimil Babka , "Kirill A . Shutemov" , Andi Kleen , Tony Luck , Marc Orr , Sathyanarayanan Kuppuswamy , "Dr. David Alan Gilbert" , jarkko@kernel.org Content-Type: text/plain; charset="UTF-8" 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_FILL_THIS_FORM_SHORT,USER_IN_DEF_DKIM_WL,USER_IN_DEF_SPF_WL autolearn=unavailable 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-crypto@vger.kernel.org On Fri, Aug 19, 2022 at 9:54 AM Peter Gonda wrote: > > > + > > +static int __snp_handle_page_state_change(struct kvm_vcpu *vcpu, enum psc_op op, gpa_t gpa, > > + int level) > > +{ > > + struct kvm_sev_info *sev = &to_kvm_svm(vcpu->kvm)->sev_info; > > + struct kvm *kvm = vcpu->kvm; > > + int rc, npt_level; > > + kvm_pfn_t pfn; > > + gpa_t gpa_end; > > + > > + gpa_end = gpa + page_level_size(level); > > + > > + while (gpa < gpa_end) { > > + /* > > + * If the gpa is not present in the NPT then build the NPT. > > + */ > > + rc = snp_check_and_build_npt(vcpu, gpa, level); > > + if (rc) > > + return -EINVAL; > > + > > + if (op == SNP_PAGE_STATE_PRIVATE) { > > + hva_t hva; > > + > > + if (snp_gpa_to_hva(kvm, gpa, &hva)) > > + return -EINVAL; > > + > > + /* > > + * Verify that the hva range is registered. This enforcement is > > + * required to avoid the cases where a page is marked private > > + * in the RMP table but never gets cleanup during the VM > > + * termination path. > > + */ > > + mutex_lock(&kvm->lock); > > + rc = is_hva_registered(kvm, hva, page_level_size(level)); > > + mutex_unlock(&kvm->lock); > > + if (!rc) > > + return -EINVAL; > > + > > + /* > > + * Mark the userspace range unmerable before adding the pages > > + * in the RMP table. > > + */ > > + mmap_write_lock(kvm->mm); > > + rc = snp_mark_unmergable(kvm, hva, page_level_size(level)); > > + mmap_write_unlock(kvm->mm); > > + if (rc) > > + return -EINVAL; > > + } > > + > > + write_lock(&kvm->mmu_lock); > > + > > + rc = kvm_mmu_get_tdp_walk(vcpu, gpa, &pfn, &npt_level); > > + if (!rc) { > > + /* > > + * This may happen if another vCPU unmapped the page > > + * before we acquire the lock. Retry the PSC. > > + */ > > + write_unlock(&kvm->mmu_lock); > > + return 0; > > + } > > I think we want to return -EAGAIN or similar if we want the caller to > retry, right? I think returning 0 here hides the error. > The problem here is that the caller(linux guest kernel) doesn't retry if PSC fails. The current implementation in the guest kernel is that if a page state change request fails, it terminates the VM with GHCB_TERM_PSC reason. Returning 0 here is not a good option because it will fail the PSC silently and will probably cause a nested RMP fault later. Returning an error also terminates the guest immediately with current guest implementation. I think the best approach here is adding a retry logic to this function. Retrying without returning an error should help it work because snp_check_and_build_npt will be called again and in the second attempt this should work. > > + > > + /* > > + * Adjust the level so that we don't go higher than the backing > > + * page level. > > + */ > > + level = min_t(size_t, level, npt_level); > > + > > + trace_kvm_snp_psc(vcpu->vcpu_id, pfn, gpa, op, level); > > + > > + switch (op) { > > + case SNP_PAGE_STATE_SHARED: > > + rc = snp_make_page_shared(kvm, gpa, pfn, level); > > + break; > > + case SNP_PAGE_STATE_PRIVATE: > > + rc = rmp_make_private(pfn, gpa, level, sev->asid, false); > > + break; > > + default: > > + rc = -EINVAL; > > + break; > > + } > > + > > + write_unlock(&kvm->mmu_lock); > > + > > + if (rc) { > > + pr_err_ratelimited("Error op %d gpa %llx pfn %llx level %d rc %d\n", > > + op, gpa, pfn, level, rc); > > + return rc; > > + } > > + > > + gpa = gpa + page_level_size(level); > > + } > > + > > + return 0; > > +} > > +