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 731A3C46CD2 for ; Tue, 9 Jan 2024 11:56:30 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id E6D136B008A; Tue, 9 Jan 2024 06:56:29 -0500 (EST) Received: by kanga.kvack.org (Postfix, from userid 40) id E1C696B008C; Tue, 9 Jan 2024 06:56:29 -0500 (EST) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id CE3E16B0092; Tue, 9 Jan 2024 06:56:29 -0500 (EST) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (smtprelay0012.hostedemail.com [216.40.44.12]) by kanga.kvack.org (Postfix) with ESMTP id BE4746B008A for ; Tue, 9 Jan 2024 06:56:29 -0500 (EST) Received: from smtpin17.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay04.hostedemail.com (Postfix) with ESMTP id 90DD21A08BF for ; Tue, 9 Jan 2024 11:56:29 +0000 (UTC) X-FDA: 81659620098.17.F36B033 Received: from linux.microsoft.com (linux.microsoft.com [13.77.154.182]) by imf30.hostedemail.com (Postfix) with ESMTP id 9D30B80012 for ; Tue, 9 Jan 2024 11:56:27 +0000 (UTC) Authentication-Results: imf30.hostedemail.com; dkim=pass header.d=linux.microsoft.com header.s=default header.b=leEnvgxm; spf=pass (imf30.hostedemail.com: domain of jpiotrowski@linux.microsoft.com designates 13.77.154.182 as permitted sender) smtp.mailfrom=jpiotrowski@linux.microsoft.com; dmarc=pass (policy=none) header.from=linux.microsoft.com ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1704801387; a=rsa-sha256; cv=none; b=JT+9MCyoeHpyhUx6aq2cgyO+WYfgwLvtsnQb0id0MsPIRDrFwAuwfaeaEKALML2byTKyRp dCJgIvwps4j2V4f+kzbMryGuDs0ocXAyT+JQa5DCDa8ZI8bfqUSc14YNTnxu2cjt9+gBtk SdyxMgklssfteW/hzefc9Sd+GaKoE/g= ARC-Authentication-Results: i=1; imf30.hostedemail.com; dkim=pass header.d=linux.microsoft.com header.s=default header.b=leEnvgxm; spf=pass (imf30.hostedemail.com: domain of jpiotrowski@linux.microsoft.com designates 13.77.154.182 as permitted sender) smtp.mailfrom=jpiotrowski@linux.microsoft.com; dmarc=pass (policy=none) header.from=linux.microsoft.com ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1704801387; 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=qTrKm5gfDaGVKWMebrVJloyB8rgSl281DiQxs9lsdz4=; b=KJmvMwIUct6XFR6UYGt/r3awfGxZ14mhDkN3H9WkhNpSo8YvSIkhKcjcT/X/ksP2qFbmjf OYZyH9mrX5DG3HPGN8LinrzCItntsE4FwzH3EphtBH4NnVGWIFb5zm2kGcFe4TBSWNQVoV yif8+/roPAIBDc3/vawqDWXno/2ZHwQ= Received: from [192.168.1.210] (181-28-144-85.ftth.glasoperator.nl [85.144.28.181]) by linux.microsoft.com (Postfix) with ESMTPSA id 5DA60209AF69; Tue, 9 Jan 2024 03:56:19 -0800 (PST) DKIM-Filter: OpenDKIM Filter v2.11.0 linux.microsoft.com 5DA60209AF69 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=linux.microsoft.com; s=default; t=1704801386; bh=qTrKm5gfDaGVKWMebrVJloyB8rgSl281DiQxs9lsdz4=; h=Date:Subject:To:Cc:References:From:In-Reply-To:From; b=leEnvgxmqMyQcS71Cg/lDkkVYOlAo1MdVzP4smUzAvnnaHz4jrz2ndUmu4HVjlYiQ pQ9ufr8kiXyrTyy7o8s4h6REGjMhslEU9OG1i/Gy8bxqDNExlO0wS6czjMnGF8TyoQ P4TKIMEclkSk/uRWSxMfgue1qpFPR6T4Eu81gM/Y= Message-ID: Date: Tue, 9 Jan 2024 12:56:17 +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> <0c4aac73-10d8-4e47-b6a8-f0c180ba1900@linux.microsoft.com> <20240108170418.GDZZwrEiIaGuMpV0B0@fat_crate.local> From: Jeremi Piotrowski In-Reply-To: <20240108170418.GDZZwrEiIaGuMpV0B0@fat_crate.local> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit X-Rspamd-Server: rspam08 X-Rspamd-Queue-Id: 9D30B80012 X-Stat-Signature: tst8ki87nkt4g39i6h3d9hkbhppr7sbr X-Rspam-User: X-HE-Tag: 1704801387-901429 X-HE-Meta: U2FsdGVkX19CAASBSj/R8itqQMK/iLdDum/sMVyN5ZQMjrsxCLOSA9bw2BEwcNQ3gc+vTp3y2j6gx0F4CCczegCPbQ2AQVjnmkVaPhKtqOSQSSSYtsd1jQEBGacLxv+EL1smp63m9lrPW/GaDNvKdap99IPA4Vyo92epwdn4x3ehLM+lc9SImN3JlWYy+wK3ATS1IGfZOuHeZv+cuWNRYYIAdmn8pn3mqbzVuHsLw8zSil/MQZvl/PZOVrukCRJuYWwpsWjHE9IL3UBQ1rBiANlJinjSxaLjtboqSeXqR/Gzf0/46kd5v+k0RzaDTSSU81Fr8zG58lyqdZomLPx5Ux/my60RO5UyoxywRsalpLTQzRf68PWRTbkAalDfAC4+H0PCrUUFfXPuPToztgBwstd6SPa9kxQJJi5SmL6GDCgj7Bhv0RxsXWWmsdaOWinc5dg0h92j+E2jf9TGFWZ9QMrGXUTas9mvKfNsgBrDzI3SX3aobz8+7AFxv4Y+A0SXZmUDS6YikjF6yBFDFvOVkMxb6yhfOsByZLfQNzr5auKGLySDDYSdnU5m2PMCcVNKZKo80opJIf135JawVIXGBLyo83JJe3afjj6Gw0/z4rnN9mvoXmUOY/G8sIS9Bb8a3GvVn/QKeUQuQooJ4baj3Osw09QfA/gpzf8N2eDL2FmqN8fDByaffW9XZo1FiomOQCWKPbHmjN7e8bTWRx/mNdCRygZxcdeXNUhFMQhcpSd5qWG9wBEV3m/D2bX1zUF+MB3I+SrBb72aVU5q4uDO9AAOAUX6FNQDqrELNu45nnCtwI05Y5uLmujCnN0U1pGFyyJccZNxR85ifcOacXYlF3VJk9MyVKZLodXqPFaZGUb3nUwnz/slgLRgwxkfPBrfacwrPtjAQ5zZdJ1me04s+jqb9LPCslI51metxnbknxISRsixxxxZZAkDVh/wDfScunEZKxzFDvIqgopg5wa gokf5SyC uE9GFO7Ig4NnCLWFEF6aZoDjpqpkek2RsyO3y5rpwVvC+VKJ959lDd3MPaIiRM2mfLcnKzp/1xCT1av38O17gxfgpVdAj68fypVFVCuTh189FOHe/yYtwqwZUdy+rSrq2nn7jXjxVpu6nAosvZ/QhN/8lm4olSBu69vQndw0TKVuF0qZ0GzRxOcdyDnUHoVy5ZsXqzdFx1HTupWfFnyeY1L7hDJ4XImCcIXkswCh/aCwQuKOifzi8nlajuqCkj0zb9k19 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 08/01/2024 18:04, Borislav Petkov wrote: > On Mon, Jan 08, 2024 at 05:49:01PM +0100, Jeremi Piotrowski wrote: >> What I wrote: "allow for the kernel to allocate the rmptable". > > What?! > > "15.36.5 Hypervisor RMP Management > > ... > > Because the RMP is initialized by the AMD-SP to prevent direct access to > the RMP, the hypervisor must use the RMPUPDATE instruction to alter the > entries of the RMP. RMPUPDATE allows the hypervisor to alter the > Guest_Physical_Address, Assigned, Page_Size, Immutable, and ASID fields > of an RMP entry." >> What you want is something that you should keep far and away from the > upstream kernel. > Can we please not assume I am acting in bad faith. I am explicitly trying to integrate nicely with AMD's KVM SNP host patches to cover an additional usecase and get something upstreamable. Let's separate RMP allocation from who (and how) maintains the entries. """ 15.36.4 Initializing the RMP ... Software must program RMP_BASE and RMP_END identically for each core in the system and before enabling SEV-SNP globally. """ KVM expects UEFI to do this, Hyper-V does the allocation itself (on bare-metal). Both are valid. Afaik it is the SNP_INIT command that hands over control of the RMP from software to AMD-SP. When it comes to "who and how maintains the rmp" - that is of course the AMD-SP and hypervisor issues RMPUPDATE instructions. The paragraph you cite talks about the physical RMP and AMD-SP - not virtualized SNP (aka "SNP-host VM"/nested SNP). AMD specified an MSR-based RMPUPDATE for us for that usecase (15.36.19 SEV-SNP Instruction Virtualization). The RMP inside the SNP-host VM is not related to the physical RMP and is an entirely software based construct. The RMP in nested SNP is only used for kernel bookkeeping and so its allocation is optional. KVM could do without reading the RMP directly altogether (by tracking the assigned bit somewhere) but that would be a design change and I'd rather see the KVM SNP host patches merged in their current shape. Which is why the patch I linked allocates a (shadow) RMP from the kernel. I would very much appreciate if we would not prevent that usecase from working - that's why I've been reviewing and testing multiple revisions of these patches and providing feedback all along.