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=-15.4 required=3.0 tests=BAYES_00,DKIMWL_WL_MED, DKIM_SIGNED,DKIM_VALID,DKIM_VALID_AU,FSL_HELO_FAKE, HEADER_FROM_DIFFERENT_DOMAINS,INCLUDES_PATCH,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 8B52BC636C9 for ; Thu, 15 Jul 2021 23:48:29 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [23.128.96.18]) by mail.kernel.org (Postfix) with ESMTP id 6A580613C9 for ; Thu, 15 Jul 2021 23:48:29 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S232546AbhGOXvU (ORCPT ); Thu, 15 Jul 2021 19:51:20 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:41702 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S232427AbhGOXvT (ORCPT ); Thu, 15 Jul 2021 19:51:19 -0400 Received: from mail-pf1-x42b.google.com (mail-pf1-x42b.google.com [IPv6:2607:f8b0:4864:20::42b]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 4C2F5C06175F for ; Thu, 15 Jul 2021 16:48:24 -0700 (PDT) Received: by mail-pf1-x42b.google.com with SMTP id m83so7213002pfd.0 for ; Thu, 15 Jul 2021 16:48:24 -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=5OQMDn6Hx/yHVRBDOLcOoarZgTpJ6ou0lJ0Voq0OG4M=; b=Xerp+3Ma+7CKr4/78JI541G8uYD8//jwvClMOF/fOO7QmiQm8HAEUnu6NpDbBLMH1q bZGV9qTn+NrOGGYaOzCjTB7B/aPpvd5It43hKuUVskOmztUVNBp7D+395FsS2sQvlrxq xVAo8FpFCDhowTVg4hGaiMCdbGyqn6qUNM0miSvgPCaSI49UBGL5vj48ibmF6+Rb17X0 w7C8AuBB8wkZlc1aeNQ5K9KigBlX9jYvbv1ccsercnerPpuW03IdweX4DvdjBnQR82bX e0jajjskDBGjMsxL7Fj/B+zCTGGj135zbVxs9kViMAV8ZYC/Kcwbxlf9wsPPlckGHHm4 ds+Q== 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=5OQMDn6Hx/yHVRBDOLcOoarZgTpJ6ou0lJ0Voq0OG4M=; b=j+8g77sJxMyFPMUr3cI/9M0CqEuXOG8SWHjiM0actgb6tk7mkpoRmZQ1Qn4SvO1d3G mbm6QT/YXXrGvv/xei9Vhp7qFYxi7Jlamv2w9y6fPH17L56tqVvMQvZDqU5rfT3xjfLF HHUszHJr29Ca0Sf54MhHvX3dInhDmONPcQwSc6p/POyrztRmOH2yoYRFpuVVokHSyexF mMrkDmSVSf6r4KTM9opgUMB/KAzohovR/Tpt8datSXguDoJM0hHO21mkE7mc9CttPWNg HknDP5s/btUcZreV7sKCz4l4bR4NVA/H1HmKfBKZhSimCap7EOj3MC3/OoR0zo+MlzXv VmYw== X-Gm-Message-State: AOAM530Pz0S38/bpgrnRO1ii2hFcB64nYAMKxnyW6r2+Wunp82B6foRw hEK2z1As894Sam9yzhzljeyVHg== X-Google-Smtp-Source: ABdhPJzB/aLwcMzRnzgFsmskaKhCj/u4SogoqFPq9x0TyUcwapKqqebbwl1vM0o7pXaHZ6NJDfrs4g== X-Received: by 2002:a63:4e5d:: with SMTP id o29mr275121pgl.379.1626392903572; Thu, 15 Jul 2021 16:48:23 -0700 (PDT) Received: from google.com (157.214.185.35.bc.googleusercontent.com. [35.185.214.157]) by smtp.gmail.com with ESMTPSA id o184sm8719553pga.18.2021.07.15.16.48.22 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Thu, 15 Jul 2021 16:48:22 -0700 (PDT) Date: Thu, 15 Jul 2021 23:48:19 +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 15/40] crypto: ccp: Handle the legacy TMR allocation when SNP is enabled Message-ID: References: <20210707183616.5620-1-brijesh.singh@amd.com> <20210707183616.5620-16-brijesh.singh@amd.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20210707183616.5620-16-brijesh.singh@amd.com> Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Wed, Jul 07, 2021, Brijesh Singh wrote: > The behavior and requirement for the SEV-legacy command is altered when > the SNP firmware is in the INIT state. See SEV-SNP firmware specification > for more details. > > When SNP is INIT state, all the SEV-legacy commands that cause the > firmware to write memory must be in the firmware state. The TMR memory It'd be helpful to spell out Trusted Memory Region, I hadn't seen that term before and for some reason my brain immediately thought "xAPIC register!". > is allocated by the host but updated by the firmware, so, it must be > in the firmware state. Additionally, the TMR memory must be a 2MB aligned > instead of the 1MB, and the TMR length need to be 2MB instead of 1MB. > The helper __snp_{alloc,free}_firmware_pages() can be used for allocating > and freeing the memory used by the firmware. None of this actually states what the patch does, e.g. it's not clear whether all allocations are being converted to 2mb or just the SNP. Looks like it's just SNP. Something like this? Allocate the Trusted Memory Region (TMR) as a 2mb sized/aligned region when SNP is enabled to satisfy new requirements for SNP. Continue allocating a 1mb region for !SNP configuration. > While at it, provide API that can be used by others to allocate a page > that can be used by the firmware. The immediate user for this API will > be the KVM driver. The KVM driver to need to allocate a firmware context > page during the guest creation. The context page need to be updated > by the firmware. See the SEV-SNP specification for further details. ... > @@ -1153,8 +1269,10 @@ static void sev_firmware_shutdown(struct sev_device *sev) > /* The TMR area was encrypted, flush it from the cache */ > wbinvd_on_all_cpus(); > > - free_pages((unsigned long)sev_es_tmr, > - get_order(SEV_ES_TMR_SIZE)); > + > + __snp_free_firmware_pages(virt_to_page(sev_es_tmr), > + get_order(sev_es_tmr_size), > + false); > sev_es_tmr = NULL; > } > > @@ -1204,16 +1322,6 @@ void sev_pci_init(void) > sev_update_firmware(sev->dev) == 0) > sev_get_api_version(); > > - /* Obtain the TMR memory area for SEV-ES use */ > - tmr_page = alloc_pages(GFP_KERNEL, get_order(SEV_ES_TMR_SIZE)); > - if (tmr_page) { > - sev_es_tmr = page_address(tmr_page); > - } else { > - sev_es_tmr = NULL; > - dev_warn(sev->dev, > - "SEV: TMR allocation failed, SEV-ES support unavailable\n"); > - } > - > /* > * If boot CPU supports the SNP, then first attempt to initialize > * the SNP firmware. > @@ -1229,6 +1337,16 @@ void sev_pci_init(void) > } > } > > + /* Obtain the TMR memory area for SEV-ES use */ > + tmr_page = __snp_alloc_firmware_pages(GFP_KERNEL, get_order(sev_es_tmr_size), false); > + if (tmr_page) { > + sev_es_tmr = page_address(tmr_page); > + } else { > + sev_es_tmr = NULL; > + dev_warn(sev->dev, > + "SEV: TMR allocation failed, SEV-ES support unavailable\n"); > + } I think your patch ordering got a bit wonky. AFAICT, the chunk that added sev_snp_init() and friends in the previous patch 14 should have landed above the TMR allocation, i.e. the code movement here should be unnecessary. > /* Initialize the platform */ > rc = sev_platform_init(&error); > if (rc && (error == SEV_RET_SECURE_DATA_INVALID)) { ... > @@ -961,6 +965,13 @@ static inline int snp_guest_dbg_decrypt(struct sev_data_snp_dbg *data, int *erro > return -ENODEV; > } > > +static inline void *snp_alloc_firmware_page(gfp_t mask) > +{ > + return NULL; > +} > + > +static inline void snp_free_firmware_page(void *addr) { } Hmm, I think we should probably bite the bullet and #ifdef and/or stub out large swaths of svm/sev.c before adding SNP support. sev.c is getting quite massive, and we're accumulating more and more stubs outside of KVM because its SEV code is compiled unconditionally.