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 Received: from kanga.kvack.org (kanga.kvack.org [205.233.56.17]) by smtp.lore.kernel.org (Postfix) with ESMTP id 0A1EDC433EF for ; Mon, 7 Feb 2022 23:48:19 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 32E706B0075; Mon, 7 Feb 2022 18:48:18 -0500 (EST) Received: by kanga.kvack.org (Postfix, from userid 40) id 2DE256B0078; Mon, 7 Feb 2022 18:48:18 -0500 (EST) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 17F806B007B; Mon, 7 Feb 2022 18:48:18 -0500 (EST) X-Delivered-To: linux-mm@kvack.org Received: from forelay.hostedemail.com (smtprelay0077.hostedemail.com [216.40.44.77]) by kanga.kvack.org (Postfix) with ESMTP id 0A0406B0075 for ; Mon, 7 Feb 2022 18:48:18 -0500 (EST) Received: from smtpin22.hostedemail.com (10.5.19.251.rfc1918.com [10.5.19.251]) by forelay04.hostedemail.com (Postfix) with ESMTP id C686D944FE for ; Mon, 7 Feb 2022 23:48:17 +0000 (UTC) X-FDA: 79117625034.22.71A6BE9 Received: from mail-pj1-f46.google.com (mail-pj1-f46.google.com [209.85.216.46]) by imf18.hostedemail.com (Postfix) with ESMTP id 6CC611C0004 for ; Mon, 7 Feb 2022 23:48:17 +0000 (UTC) Received: by mail-pj1-f46.google.com with SMTP id qe15so5037972pjb.3 for ; Mon, 07 Feb 2022 15:48:17 -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=DmAjZsfccwaVaNtes6EmfPZ2rG4blpFc0pyFaBFNy/c=; b=O48QwLhH9/EyfzfbZFDBuyW7NgAxpUfsKFo77vRIIp/J97PxXdR/Nfj2Q5oBXNcuPo Jf+QknfQrGr7pgD1rVD/n/xLnaeB/v8ecoI8tICXQpFrYlc8ZMljeCsh4aBWr+MUr3+G Z+isaq63CF1Tym+PBdMK6+axq9i8a6odmcOzGYnYQtwotEiike8g+3qsd0ovrJL+iHr9 IRWBaGik6wVgAJ2agrzQUCGB/xt89X7wnTl3AQVzdoaewv8FDh3sJaMY7Az0F+paU4cv ZGtrP1Ka76pG+mtfqeJGLgKYnsm2YYJsLXjwUbqakndlRzflCo3MlbsGS63DJb4uRxOi pbXQ== 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=DmAjZsfccwaVaNtes6EmfPZ2rG4blpFc0pyFaBFNy/c=; b=OwbUqGzFmrJL+54oPcarGHrWhMvqCar/FLFoX7CDUfucIHVXxsebNDU9yBxlmK2OPT xpuDYa5gTSrzP4rMhVp2xJTrvS09WQXIH1ABLQ06scQ3eqJIVUu0pdNdV51PCBFP/Gpa 3K5nsS2DjxqXbCu3dGxJC6Cob5fvjC7TIqnQWSD2bDj+0XN0itP5U1oxk7U0YYcrXS3y V/lI4rxGL4ENDJym2nTAhrGfLf7eYk9CWpSBR4wkipVTxawFCQti4qS5fx/Z2Vl3Q++O JPg5/WYkLLxAgW/Z/w5UwCzmaMC/pfz/U4My11b8IhDmSEDIq8Tygqj+djovfe39zFM1 LEOw== X-Gm-Message-State: AOAM53141KLqvOpO7mD34BLR38mKOqlK0RR2hfYhrHkZ+DO/AnFyuFZr D0sMzxcqzDAX4dTl84HL6LbjLg== X-Google-Smtp-Source: ABdhPJxqxfPIQtuam5GkZBepPAbS7V0Q8IGPcsrc+Vbtsq0AWBZ7iKtmXQsqTlN6H1uGOVjInIYmRw== X-Received: by 2002:a17:902:d487:: with SMTP id c7mr2089230plg.0.1644277695967; Mon, 07 Feb 2022 15:48:15 -0800 (PST) Received: from google.com (157.214.185.35.bc.googleusercontent.com. [35.185.214.157]) by smtp.gmail.com with ESMTPSA id u18sm13306160pfk.14.2022.02.07.15.48.15 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Mon, 07 Feb 2022 15:48:15 -0800 (PST) Date: Mon, 7 Feb 2022 23:48:11 +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, Thomas Gleixner , Ingo Molnar , Joerg Roedel , Tom Lendacky , "H. Peter Anvin" , Ard Biesheuvel , Paolo Bonzini , Vitaly Kuznetsov , 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 , "Kirill A . Shutemov" , Andi Kleen , "Dr . David Alan Gilbert" , brijesh.ksingh@gmail.com, tony.luck@intel.com, marcorr@google.com, sathyanarayanan.kuppuswamy@linux.intel.com Subject: Re: [PATCH v9 30/43] KVM: SEV: Add documentation for SEV-SNP CPUID Enforcement Message-ID: References: <20220128171804.569796-1-brijesh.singh@amd.com> <20220128171804.569796-31-brijesh.singh@amd.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20220128171804.569796-31-brijesh.singh@amd.com> Authentication-Results: imf18.hostedemail.com; dkim=pass header.d=google.com header.s=20210112 header.b=O48QwLhH; dmarc=pass (policy=reject) header.from=google.com; spf=pass (imf18.hostedemail.com: domain of seanjc@google.com designates 209.85.216.46 as permitted sender) smtp.mailfrom=seanjc@google.com X-Rspam-User: X-Rspamd-Server: rspam02 X-Rspamd-Queue-Id: 6CC611C0004 X-Stat-Signature: 1ub1hkixnnzpn14mj5aek81y6dxnk9r4 X-HE-Tag: 1644277697-976135 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 Fri, Jan 28, 2022, Brijesh Singh wrote: > From: Michael Roth > > Update the documentation with SEV-SNP CPUID enforcement. > > Signed-off-by: Michael Roth > Signed-off-by: Brijesh Singh > --- > .../virt/kvm/amd-memory-encryption.rst | 28 +++++++++++++++++++ > 1 file changed, 28 insertions(+) > > diff --git a/Documentation/virt/kvm/amd-memory-encryption.rst b/Documentation/virt/kvm/amd-memory-encryption.rst > index 1c6847fff304..0c72f44cc11a 100644 > --- a/Documentation/virt/kvm/amd-memory-encryption.rst > +++ b/Documentation/virt/kvm/amd-memory-encryption.rst This doc is specifically for KVM's host-side implemenation, whereas the below is (a) mostly targeted at the guest and (b) has nothing to do with KVM. Documentation/x86/amd-memory-encryption.rst isn't a great fit either. Since TDX will need a fair bit of documentation, and SEV-ES could retroactively use docs as well, what about adding a sub-directory: Documentation/virt/confidential_compute to match the "cc_platform_has" stuffr, and then we can add sev.rst and tdx.rst there? Or sev-es.rst, sev-snp.rst, etc... if we want to split things up more. It might be worth extracting the SEV details from x86/amd-memory-encryption.rst into virt/ as well. A big chunk of that file appears to be SEV specific, and it appears to have gotten a little out-of-whack. E.g. this section no longer makes sense as the last paragraph below appears to be talking about SME (bit 23 in MSR 0xc0010010), but walking back "this bit" would reference SEV. I suspect a mostly-standalone sev.rst would be easier to follow than an intertwined SME+SEV. If support for SME is present, MSR 0xc00100010 (MSR_AMD64_SYSCFG) can be used to determine if SME is enabled and/or to enable memory encryption:: 0xc0010010: Bit[23] 0 = memory encryption features are disabled 1 = memory encryption features are enabled If SEV is supported, MSR 0xc0010131 (MSR_AMD64_SEV) can be used to determine if SEV is active:: 0xc0010131: Bit[0] 0 = memory encryption is not active 1 = memory encryption is active Linux relies on BIOS to set this bit if BIOS has determined that the reduction in the physical address space as a result of enabling memory encryption (see CPUID information above) will not conflict with the address space resource requirements for the system. If this bit is not set upon Linux startup then Linux itself will not set it and memory encryption will not be possible.