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=-10.8 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 45EC4C07E95 for ; Tue, 20 Jul 2021 22:06:39 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [23.128.96.18]) by mail.kernel.org (Postfix) with ESMTP id 312FB61009 for ; Tue, 20 Jul 2021 22:06:39 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S229818AbhGTVZ6 (ORCPT ); Tue, 20 Jul 2021 17:25:58 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:32978 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S229830AbhGTVZy (ORCPT ); Tue, 20 Jul 2021 17:25:54 -0400 Received: from mail-pj1-x102c.google.com (mail-pj1-x102c.google.com [IPv6:2607:f8b0:4864:20::102c]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 70641C061766 for ; Tue, 20 Jul 2021 15:06:29 -0700 (PDT) Received: by mail-pj1-x102c.google.com with SMTP id v18-20020a17090ac912b0290173b9578f1cso2596058pjt.0 for ; Tue, 20 Jul 2021 15:06:29 -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:content-transfer-encoding:in-reply-to; bh=BB0NGsGv3epWhxiQYCc03cLFHcDOFlK36/5xOhr9iGo=; b=G60QHWuyRH6eWtLou5HaWRxEN7Yq6nKV9T1iAIqyAq6fVrq1WWQgHIEV53g1ohgNc9 EQohQSGMoRnwcSERx2WtsFUY2oBHP2L7o6RLWdjM/8DnxS/jS2gR62e2ZdzQzsD/Cfqi t26NKDlXSIHcL8jfXQ4F7qrg5pPOvQuoI2mBqA5sqIxf4jaH3gQ080WBkK8r5zzKZj6Q G/9z8dSeMgvga8DzcwvEltKCTyVWefclmiDtlzTovNTWLqmL4Y7wltkF8n7JL2lbJV27 Rqq2Y/zqOcIZ3UnQEC1ynwVVGlNk1MtMr3wIXyYacV1olaGdhCMiOjk/TQIOvra62SgO XgXg== 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:content-transfer-encoding :in-reply-to; bh=BB0NGsGv3epWhxiQYCc03cLFHcDOFlK36/5xOhr9iGo=; b=fA+MtbUpDw0bmhwqEa+9Ryhfqb2hMgkMlQgTZbOrq2L+2wtcKOZcZKw+DyCKoEvvvD QATILSMtJ1Cp7wcqGyMQ7rMz5N1u/LVuNBK8pLtI74Z1hWEKN/YcRv53C3/iWr89j+G/ pckdQemDzYYs5wqwifn6qdx8vuW0S3RbrsfmMcwPcA1ioy1qKN7M670UC9GwbYQyyvMb FcyDbO8qrTeIkVidgUHjk8p8tLmWuA9BJSus3d+1QDNXihSqPpsB+UPwyJG2ej+5OTn7 ffcdfMppv3lU0xWmXahqHcyFoFBgjN/cbKNk0Zj/47AfM0PbAec0OD+lI6zIfe0ksJIJ u6fA== X-Gm-Message-State: AOAM533+NKKDzl8hKWESEHR8SJyRw0HrBaIwdhAdPw8VOq9Jow9aUlk/ +LxZMMTT5L3zCMDmwH3Fb60W/w== X-Google-Smtp-Source: ABdhPJwDD9+zuJ6DYICNGOinctEj1Edxq+hD2yj+AdZXjLWVr+ao/12i42Q3S8W5xw+1pKf5QwmK4Q== X-Received: by 2002:a17:90a:4295:: with SMTP id p21mr30863822pjg.149.1626818788641; Tue, 20 Jul 2021 15:06:28 -0700 (PDT) Received: from google.com (157.214.185.35.bc.googleusercontent.com. [35.185.214.157]) by smtp.gmail.com with ESMTPSA id w184sm419793pfw.85.2021.07.20.15.06.27 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Tue, 20 Jul 2021 15:06:27 -0700 (PDT) Date: Tue, 20 Jul 2021 22:06:24 +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 05/40] x86/sev: Add RMP entry lookup helpers Message-ID: References: <20210707183616.5620-1-brijesh.singh@amd.com> <20210707183616.5620-6-brijesh.singh@amd.com> <437a5230-64fc-64ab-9378-612c34e1b641@amd.com> <39be0f79-e8e4-fd4a-5c4a-47731c61740d@amd.com> MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: <39be0f79-e8e4-fd4a-5c4a-47731c61740d@amd.com> Precedence: bulk List-ID: X-Mailing-List: kvm@vger.kernel.org On Fri, Jul 16, 2021, Brijesh Singh wrote: > > On 7/15/21 2:28 PM, Brijesh Singh wrote: > >> Looking at the future patches, dump_rmpentry() is the only power user, > >> e.g. everything else mostly looks at "assigned" and "level" (and one > >> ratelimited warn on "validated" in snp_make_page_shared(), but I suspect > >> that particular check can and should be dropped). > > > > Yes, we need "assigned" and "level" and other entries are mainly for > > the debug purposes. > > > For the debug purposes, we would like to dump additional RMP entries. If > we go with your proposed function then how do we get those information > in the dump_rmpentry()? As suggested below, move dump_rmpentry() into sev.c so that it can use the microarchitectural version. For debug, I'm pretty that's what we'll want anyways, e.g. dump the raw value along with the meaning of various bits. > How about if we provide two functions; the first > function provides architectural format and second provides the raw > values which can be used by the dump_rmpentry() helper. > > struct rmpentry *snp_lookup_rmpentry(unsigned long paddr, int *level); > > The 'struct rmpentry' uses the format defined in APM Table 15-36. > > struct _rmpentry *_snp_lookup_rmpentry(unsigned long paddr, int *level); > > The 'struct _rmpentry' will use include the PPR definition (basically > what we have today in this patch). > > Thoughts ? Why define an architectural "struct rmpentry"? IIUC, there isn't a true architectural RMP entry; the APM defines architectural fields but doesn't define a layout. Functionally, making up our own struct isn't a problem, I just don't see the point since all use cases only care about Assigned and Page-Size, and we can do them a favor by translating Page-Size to X86_PG_LEVEL. > >> /* > >>   * Returns 1 if the RMP entry is assigned, 0 if it exists but is not > >> * assigned, and -errno if there is no corresponding RMP entry. > >>   */ > >> int snp_lookup_rmpentry(struct page *page, int *level) > >> { > >>     unsigned long phys = page_to_pfn(page) << PAGE_SHIFT; > >>     struct rmpentry *entry, *large_entry; > >>     unsigned long vaddr; > >> > >>     if (!cpu_feature_enabled(X86_FEATURE_SEV_SNP)) > >>         return -ENXIO; > >> > >>     vaddr = rmptable_start + rmptable_page_offset(phys); > >>     if (unlikely(vaddr > rmptable_end)) > >>         return -EXNIO; > >> > >>     entry = (struct rmpentry *)vaddr; > >> > >>     /* Read a large RMP entry to get the correct page level used in > >> RMP entry. */ > >>     vaddr = rmptable_start + rmptable_page_offset(phys & PMD_MASK); > >>     large_entry = (struct rmpentry *)vaddr; > >>     *level = RMP_TO_X86_PG_LEVEL(rmpentry_pagesize(large_entry)); > >> > >>     return !!entry->assigned; > >> } > >> > >> > >> And then move dump_rmpentry() (or add a helper) in sev.c so that "struct > >> rmpentry" can be declared in sev.c.