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 4ECE5C07E95 for ; Mon, 19 Jul 2021 18:56:02 +0000 (UTC) Received: from kanga.kvack.org (kanga.kvack.org [205.233.56.17]) by mail.kernel.org (Postfix) with ESMTP id C34C26109E for ; Mon, 19 Jul 2021 18:56:01 +0000 (UTC) DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org C34C26109E 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 317686B017A; Mon, 19 Jul 2021 14:56:02 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id 2EDED6B017B; Mon, 19 Jul 2021 14:56:02 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 168158D00EC; Mon, 19 Jul 2021 14:56:02 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from forelay.hostedemail.com (smtprelay0164.hostedemail.com [216.40.44.164]) by kanga.kvack.org (Postfix) with ESMTP id E6D2C6B017A for ; Mon, 19 Jul 2021 14:56:01 -0400 (EDT) Received: from smtpin32.hostedemail.com (10.5.19.251.rfc1918.com [10.5.19.251]) by forelay02.hostedemail.com (Postfix) with ESMTP id 8380922865 for ; Mon, 19 Jul 2021 18:56:00 +0000 (UTC) X-FDA: 78380242080.32.DF994BD Received: from mail-pf1-f171.google.com (mail-pf1-f171.google.com [209.85.210.171]) by imf04.hostedemail.com (Postfix) with ESMTP id 43C1A50000A4 for ; Mon, 19 Jul 2021 18:56:00 +0000 (UTC) Received: by mail-pf1-f171.google.com with SMTP id c1so13448288pfc.13 for ; Mon, 19 Jul 2021 11:56:00 -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=lOc5+rloDVdT/oQx00DjmvvmSON6OrGGoIPjsiSNP8Y=; b=g4AlSOFhPm6hVf/7SR105tRah3Aea3+9KqN56Ke/OvVzbLLxQa+2FEdnRI5yCBDV+U 4E04weFnBKUQ3efnvzdPhRQY+2+Od5nqIyCKNKgiFX0wtkQXrweRsh5bUaswhmgDdflh twIaMTzdSaq840Cc7sDRoqigwkJn4mAzbH3OXS7gdeaYNQPustFoljMzhp71Jz/EDIPl iQ0u6pB02qRWEy9NOKHisJRFVf53eOgb0bPRjLegKpAPXdgUt4CSFJjUZQnOg29L//qi bWnnKN93uYWfM5tgm7e4zrwTJ+oo8OaLK8lCgwcR4sL6wlqDO3MXhRGr9K/4lw9CfxuI K3uA== 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=lOc5+rloDVdT/oQx00DjmvvmSON6OrGGoIPjsiSNP8Y=; b=gid9zzQC+Wtj8l8ZJ6kDsqmojAe9GME+rQaUo+D6ALbgz2frgbuJuY6zHm1DSdFh9v m/knLhtp/X36o/0BDlI+oYvdLxvGTWk9CqBR/tZQVV1Nagjf49hSP3Bz1NbY3DnOYsLx B1XtQBBcto5U19DcbSsO5/Oo2UzuhZtR2h8bDOJkog0IPlHR5kQsVRK+uM3DdRK3U/7g J8qrf/00RUYeyyC4ATauCq9yJpbdTVv6mSyj4F3m276m+nesV3t9DBTiaNveapgymZR1 Xbbd4zI+9rgh7An+r9nDZRNaGRZ5/am7lGRQkw6l/WYkMO7LHTxMp+egA5eEdMc1Jnkw eZRg== X-Gm-Message-State: AOAM531wzqoCHAGQ06FkzQ0bA1OqYdSGCcAfC1Fsr53qqCS3Rbz8Y3Ax 0w3lxxYbJB62Kq3NRAUR4VOslg== X-Google-Smtp-Source: ABdhPJxmSOu7+O2DfzTj7tTZcm5PtaeD09Hlmp3Y4R1m0EFLmxzdwqmHKXKDHGBPl5X7i0P9uc4f5A== X-Received: by 2002:a05:6a00:1951:b029:333:64d3:e1f1 with SMTP id s17-20020a056a001951b029033364d3e1f1mr24076104pfk.43.1626720959003; Mon, 19 Jul 2021 11:55:59 -0700 (PDT) Received: from google.com (157.214.185.35.bc.googleusercontent.com. [35.185.214.157]) by smtp.gmail.com with ESMTPSA id q17sm24643642pgd.39.2021.07.19.11.55.58 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Mon, 19 Jul 2021 11:55:58 -0700 (PDT) Date: Mon, 19 Jul 2021 18:55:54 +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 33/40] KVM: SVM: Add support to handle MSR based Page State Change VMGEXIT Message-ID: References: <20210707183616.5620-1-brijesh.singh@amd.com> <20210707183616.5620-34-brijesh.singh@amd.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: X-Rspamd-Server: rspam06 X-Rspamd-Queue-Id: 43C1A50000A4 X-Stat-Signature: 3jkdyjretnk9sxgou6cswc9qcguxtg33 Authentication-Results: imf04.hostedemail.com; dkim=pass header.d=google.com header.s=20161025 header.b=g4AlSOFh; spf=pass (imf04.hostedemail.com: domain of seanjc@google.com designates 209.85.210.171 as permitted sender) smtp.mailfrom=seanjc@google.com; dmarc=pass (policy=reject) header.from=google.com X-HE-Tag: 1626720960-957633 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 Mon, Jul 19, 2021, Brijesh Singh wrote: > > On 7/16/21 4:00 PM, Sean Christopherson wrote: > > On Wed, Jul 07, 2021, Brijesh Singh wrote: > > > +static int __snp_handle_psc(struct kvm_vcpu *vcpu, int op, gpa_t gpa, int level) > > > > I can live with e.g. GHCB_MSR_PSC_REQ, but I'd strongly prefer to spell this out, > > e.g. __snp_handle_page_state_change() or whatever. I had a hell of a time figuring > > out what PSC was the first time I saw it in some random context. > > Based on the previous review feedback I renamed from > __snp_handle_page_state_change to __snp_handle_psc(). I will see what others > say and based on that will rename accordingly. I've no objection to using PSC for enums and whatnot, and I'll happily defer to Boris for functions in the core kernel and guest, but for KVM I'd really like to spell out the name for the two or so main handler functions. > > > + while (gpa < gpa_end) { > > > + /* > > > + * Get the pfn and level for the gpa from the nested page table. > > > + * > > > + * If the TDP walk failed, then its safe to say that we don't have a valid > > > + * mapping for the gpa in the nested page table. Create a fault to map the > > > + * page is nested page table. > > > + */ > > > + if (!kvm_mmu_get_tdp_walk(vcpu, gpa, &pfn, &tdp_level)) { > > > + pfn = kvm_mmu_map_tdp_page(vcpu, gpa, PFERR_USER_MASK, level); > > > + if (is_error_noslot_pfn(pfn)) > > > + goto out; > > > + > > > + if (!kvm_mmu_get_tdp_walk(vcpu, gpa, &pfn, &tdp_level)) > > > + goto out; > > > + } > > > + > > > + /* Adjust the level so that we don't go higher than the backing page level */ > > > + level = min_t(size_t, level, tdp_level); > > > + > > > + write_lock(&kvm->mmu_lock); > > > > Retrieving the PFN and level outside of mmu_lock is not correct. Because the > > pages are pinned and the VMM is not malicious, it will function as intended, but > > it is far from correct. > > Good point, I should have retrieved the pfn and level inside the lock. > > > The overall approach also feels wrong, e.g. a guest won't be able to convert a > > 2mb chunk back to a 2mb large page if KVM mapped the GPA as a 4kb page in the > > past (from a different conversion). > > > > Maybe I am missing something, I am not able to follow 'guest won't be able > to convert a 2mb chunk back to a 2mb large page'. The page-size used inside > the guest have to relationship with the RMP/NPT page-size. e.g, a guest can > validate the page range as a 4k and still map the page range as a 2mb or 1gb > in its pagetable. The proposed code walks KVM's TDP and adjusts the RMP level to be the min of the guest+host levels. Once KVM has installed a 4kb TDP SPTE, that walk will find the 4kb TDP SPTE and thus operate on the RMP at a 4kb granularity. To allow full restoration of 2mb PTE+SPTE+RMP, KVM needs to zap the 4kb SPTE(s) at some point to allow rebuilding a 2mb SPTE.