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 AF062C3DA6E for ; Mon, 8 Jan 2024 16:49:13 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 0123C6B0082; Mon, 8 Jan 2024 11:49:13 -0500 (EST) Received: by kanga.kvack.org (Postfix, from userid 40) id EDD5B8D0001; Mon, 8 Jan 2024 11:49:12 -0500 (EST) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id D56B86B0085; Mon, 8 Jan 2024 11:49:12 -0500 (EST) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (smtprelay0013.hostedemail.com [216.40.44.13]) by kanga.kvack.org (Postfix) with ESMTP id BFDCC6B0082 for ; Mon, 8 Jan 2024 11:49:12 -0500 (EST) Received: from smtpin03.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay05.hostedemail.com (Postfix) with ESMTP id 6388D40810 for ; Mon, 8 Jan 2024 16:49:12 +0000 (UTC) X-FDA: 81656728944.03.EE3406E Received: from linux.microsoft.com (linux.microsoft.com [13.77.154.182]) by imf09.hostedemail.com (Postfix) with ESMTP id 8FCEC14000B for ; Mon, 8 Jan 2024 16:49:10 +0000 (UTC) Authentication-Results: imf09.hostedemail.com; dkim=pass header.d=linux.microsoft.com header.s=default header.b="oL7/MFh4"; dmarc=pass (policy=none) header.from=linux.microsoft.com; spf=pass (imf09.hostedemail.com: domain of jpiotrowski@linux.microsoft.com designates 13.77.154.182 as permitted sender) smtp.mailfrom=jpiotrowski@linux.microsoft.com ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1704732550; h=from:from:sender:reply-to:subject:subject:date:date: message-id:message-id:to:to:cc:cc:mime-version:mime-version: content-type:content-type: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references:dkim-signature; bh=j5wUzzW0cb/Fpbwwk5abVFwIxNz3dOC7dlYfblMV53I=; b=K7Fpdep+eQ7zhiUgkKKuOZLmlTw7M7Ra0oUBnCiPhJt1EXqt5Cpv5DOHHXuu5cHvBqDKiq Y4n4dYa8UQcQpBjqUlnjxRCecjzTxSarW6/Kub4IIT0u3Op1EWlypatQePIdlMOle/YgjH Gx+J6gZq0JcZcHrH5Qz+DP+huVAc/Iw= ARC-Authentication-Results: i=1; imf09.hostedemail.com; dkim=pass header.d=linux.microsoft.com header.s=default header.b="oL7/MFh4"; dmarc=pass (policy=none) header.from=linux.microsoft.com; spf=pass (imf09.hostedemail.com: domain of jpiotrowski@linux.microsoft.com designates 13.77.154.182 as permitted sender) smtp.mailfrom=jpiotrowski@linux.microsoft.com ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1704732550; a=rsa-sha256; cv=none; b=sIn/guiCXBwAt+Dtt6soUvVnvM1q1B0/+OLcj251rvqtAadwsati9Pf+k1WuA9fVP+oMCX bpzXNQ2IYyYgqLHPws2T22tAOzfA/qrra8tOcQdc7ZLSlDX+CO5c5oqYQQ0JifrKOw2IXb ZciHLbAHQMTVjk0vrkKTtI3soBTfOHA= Received: from [192.168.1.212] (181-28-144-85.ftth.glasoperator.nl [85.144.28.181]) by linux.microsoft.com (Postfix) with ESMTPSA id 254D420B3CC1; Mon, 8 Jan 2024 08:49:02 -0800 (PST) DKIM-Filter: OpenDKIM Filter v2.11.0 linux.microsoft.com 254D420B3CC1 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=linux.microsoft.com; s=default; t=1704732549; bh=j5wUzzW0cb/Fpbwwk5abVFwIxNz3dOC7dlYfblMV53I=; h=Date:Subject:To:Cc:References:From:In-Reply-To:From; b=oL7/MFh4WwAqWCtS6MZAir1oxt++S6oXKWbLEXMz1KRawee2mKNFPNznQsNVLkDXl 1Acxk6vsRkIKA1NbV/62G8TwLpGAU5Sgqc/tXgNFDe9x3FIe9jeh/NCGKUW/GiRQnN ecpu2ijLzzeyXVOnIMVuycK7yrEY8ePWmEmRY3bc= Message-ID: <0c4aac73-10d8-4e47-b6a8-f0c180ba1900@linux.microsoft.com> Date: Mon, 8 Jan 2024 17:49:01 +0100 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: [PATCH v1 04/26] x86/sev: Add the host SEV-SNP initialization support Content-Language: en-US To: Borislav Petkov Cc: Michael Roth , x86@kernel.org, kvm@vger.kernel.org, linux-coco@lists.linux.dev, linux-mm@kvack.org, linux-crypto@vger.kernel.org, linux-kernel@vger.kernel.org, tglx@linutronix.de, mingo@redhat.com, jroedel@suse.de, thomas.lendacky@amd.com, hpa@zytor.com, ardb@kernel.org, pbonzini@redhat.com, seanjc@google.com, vkuznets@redhat.com, jmattson@google.com, luto@kernel.org, dave.hansen@linux.intel.com, slp@redhat.com, pgonda@google.com, peterz@infradead.org, srinivas.pandruvada@linux.intel.com, rientjes@google.com, tobin@ibm.com, vbabka@suse.cz, kirill@shutemov.name, ak@linux.intel.com, tony.luck@intel.com, sathyanarayanan.kuppuswamy@linux.intel.com, alpergun@google.com, jarkko@kernel.org, ashish.kalra@amd.com, nikunj.dadhania@amd.com, pankaj.gupta@amd.com, liam.merwick@oracle.com, zhi.a.wang@intel.com, Brijesh Singh References: <20231230161954.569267-1-michael.roth@amd.com> <20231230161954.569267-5-michael.roth@amd.com> <20240105160916.GDZZgprE8T6xbbHJ9E@fat_crate.local> <20240105162142.GEZZgslgQCQYI7twat@fat_crate.local> From: Jeremi Piotrowski In-Reply-To: <20240105162142.GEZZgslgQCQYI7twat@fat_crate.local> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit X-Rspamd-Queue-Id: 8FCEC14000B X-Rspam-User: X-Rspamd-Server: rspam04 X-Stat-Signature: 91a5zma6hczccbzydppqumg1hjxiumj5 X-HE-Tag: 1704732550-329210 X-HE-Meta: U2FsdGVkX19g+LVJYfflptFHMDSpi8q1sXWCjifqiGHe4NDwJNfDMsCMHZ+ogqWC/0eeb0Bj0Gw2mx0V/EEs75gu7234oKy3MfclAa5VMfCavgwh3NZFL7n8kaFOxegKBp/ivD4Vg19IKLESH89nnWBQ7cLJuioowUk8alO6PQg8WzzLWts+bV1qPnypJ45gLaLhUODVkJoSKSSrRsEnD/cpgAtUqH7rGRFo3IzE81FLJF7MSAhZ7AlOlUxwYg/PGAhSFLaS48gSP0X3umtSElZf4zckgs6vWSDsAbwQzVRV8L+uwroHmLYuc0AxnFU5vP3QHe1g6qvS4/WcTq7p6+E+upJsupn1sCP0asgjnKDKUDGfALjfo/DxPtj5ZbL9UwfAETOMG/xY+LiL7VXPxp4JzgsPw8GIjg30wWj54mbKZDdvpjgkXq6eq7Drgkhup7w62AYBim28c33LQ2sDCHZ8FizYFFn7IFc7x3vTMglRHlTr50P+HX3bS2j92F+oXD8sQ9PvX8SFEAnGvL2C9WPCz0PFQKPaijL8UT8jcGJ0+iQjyC8tYCmHJaNnRk9uWaTk57UkqjQr4CkxTuj21irpxLILTxDf76euTNUsLdMQTGNNAkD75iHiigMAXyi5Yd8AtjIcfGJJ+P5FkwplVmcRGziSE+mXP66JkKA0dzdaoI+J7WnHf9ITMjIUFcuSMa9usTgQfuRwhxXQz0HJBj+1m8UcJq7o8pKOExlq2xwXpqagCGVfzOYnyAVqPeDWU4JiQqEC3Ey21CP7FDsDaO/LBKV3vVKjoBv2vsYzgwv2p3tzECj6/HQp1Ig8HbleSAOpbdFWqSGs+Fr8Ag2EJnzWue+EAueV8npKrr+1YwvMaA/RO3YBXAotpVRsO8WWxW77WA30D0ax0zNZ7vZuDmsJYJ3J7bpR6tySkrFNz4cjmD5149ii9I7aOwBj83T4/jyBpp+XRCOpQhsZc59 4cw== 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: List-Subscribe: List-Unsubscribe: On 05/01/2024 17:21, Borislav Petkov wrote: > On Fri, Jan 05, 2024 at 05:09:16PM +0100, Borislav Petkov wrote: >> On Thu, Jan 04, 2024 at 12:05:27PM +0100, Jeremi Piotrowski wrote: >>> Is there a really good reason to perform the snp_probe_smptable_info() check at this >>> point (instead of in snp_rmptable_init). snp_rmptable_init will also clear the cap >>> on failure, and bsp_init_amd() runs too early to allow for the kernel to allocate the >>> rmptable itself. I pointed out in the previous review that kernel allocation of rmptable >>> is necessary in SNP-host capable VMs in Azure. >> >> What does that even mean?>> >> That function is doing some calculations after reading two MSRs. What >> can possibly go wrong?! > What I wrote: "allow for the kernel to allocate the rmptable". Until the kernel allocates a rmptable the two MSRs are not initialized in a VM. This is specific to SNP-host VMs because they don't have access to the system-wide rmptable (or a virtualized version of it), and the rmptable is only useful for kernel internal tracking in this case. So we don't strictly need one and could save the overhead but not having one would complicate the KVM SNP code so I'd rather allocate one for now. It makes most sense to perform the rmptable allocation later in kernel init, after platform detection and e820 setup. It isn't really used until device_initcall. https://lore.kernel.org/lkml/20230213103402.1189285-2-jpiotrowski@linux.microsoft.com/ (I'll be posting updated patches soon). > That could be one reason perhaps: > > "It needs to be called early enough to allow for AutoIBRS to not be disabled > just because SNP is supported. By calling it where it is currently called, the > SNP feature can be cleared if, even though supported, SNP can't be used, > allowing AutoIBRS to be used as a more performant Spectre mitigation." > > https://lore.kernel.org/r/8ec38db1-5ccf-4684-bc0d-d48579ebf0d0@amd.com > This logic seems twisted. Why use firmware rmptable allocation as a proxy for SEV-SNP enablement if BIOS provides an explicit flag to enable/disable SEV-SNP support. That would be a better signal to use to control AutoIBRS enablement.