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 27DC8C46CD2 for ; Tue, 9 Jan 2024 12:30:00 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 314EE6B0089; Tue, 9 Jan 2024 07:30:00 -0500 (EST) Received: by kanga.kvack.org (Postfix, from userid 40) id 29DC96B008C; Tue, 9 Jan 2024 07:30:00 -0500 (EST) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 118346B0092; Tue, 9 Jan 2024 07:30:00 -0500 (EST) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (smtprelay0010.hostedemail.com [216.40.44.10]) by kanga.kvack.org (Postfix) with ESMTP id ED2216B0089 for ; Tue, 9 Jan 2024 07:29:59 -0500 (EST) Received: from smtpin14.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay08.hostedemail.com (Postfix) with ESMTP id B5A0A14034F for ; Tue, 9 Jan 2024 12:29:59 +0000 (UTC) X-FDA: 81659704518.14.9C17C91 Received: from mail.alien8.de (mail.alien8.de [65.109.113.108]) by imf30.hostedemail.com (Postfix) with ESMTP id 5037480017 for ; Tue, 9 Jan 2024 12:29:57 +0000 (UTC) Authentication-Results: imf30.hostedemail.com; dkim=pass header.d=alien8.de header.s=alien8 header.b=e3uzqzD6; spf=pass (imf30.hostedemail.com: domain of bp@alien8.de designates 65.109.113.108 as permitted sender) smtp.mailfrom=bp@alien8.de; dmarc=pass (policy=none) header.from=alien8.de ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1704803398; 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: in-reply-to:in-reply-to:references:references:dkim-signature; bh=+Ncz7siEkTjAJGaRbmWjV3uElamE3ik/Pui2Em7ihyU=; b=us9rYynsva6G1m2UqGBwq+0aEnsvKjhg4im0n2VPKxMWLe9rkGjYYYbjntVsxyhttN8/Gf +duNfUN3pt7ekOqlCcpKy4CCNfJftiEDOfteB8cQaaUpP2M9KdHlgLkVF+tKr+0OtdO18o hKtUX4n66xiwCbHE3sailtrrgmV2cmU= ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1704803398; a=rsa-sha256; cv=none; b=aoXU9iL4Nu7MQTw2iCGbvtR81GaggeFhYtdFQ3SKy7izoY5pIg+Gfzs6urHcqVw2ygN8Oh 15MrpWZtysXTG4I8GHQyVN9wcdqIZ/grAjhUYC87+DNgg1YSN6IeiHinrZf6LH/x5DvrKT Nq5mXzT4+4iips82kj5P1SPKJvl7d5Q= ARC-Authentication-Results: i=1; imf30.hostedemail.com; dkim=pass header.d=alien8.de header.s=alien8 header.b=e3uzqzD6; spf=pass (imf30.hostedemail.com: domain of bp@alien8.de designates 65.109.113.108 as permitted sender) smtp.mailfrom=bp@alien8.de; dmarc=pass (policy=none) header.from=alien8.de Received: from localhost (localhost.localdomain [127.0.0.1]) by mail.alien8.de (SuperMail on ZX Spectrum 128k) with ESMTP id 29D7240E0196; Tue, 9 Jan 2024 12:29:53 +0000 (UTC) X-Virus-Scanned: Debian amavisd-new at mail.alien8.de Received: from mail.alien8.de ([127.0.0.1]) by localhost (mail.alien8.de [127.0.0.1]) (amavisd-new, port 10026) with ESMTP id 8LgGsJKL99AU; Tue, 9 Jan 2024 12:29:51 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=alien8.de; s=alien8; t=1704803390; bh=+Ncz7siEkTjAJGaRbmWjV3uElamE3ik/Pui2Em7ihyU=; h=Date:From:To:Cc:Subject:References:In-Reply-To:From; b=e3uzqzD6Sd0ujUJUSC7MRPxWi8vbuKwJ4aZJ/7hlC5WIahofUZyUqu6erDbkVtFKi /CFGubT/bagkKI2OzvP8iOpAbgvKCGUTWjZO2fXWeLrv01DN7vwzpg2LQuOg4SYQ5c rHNecCB5hRIycePIdkdlF2UbRLptkbp6CbKVs3/er+Ry1bO/1VV7Dau+807YKwMa6u jeL12ntBz1dCGaOaIznhk4bYEgy3OGYr2HRemzpEpQa6Q4tw4YsqULxGCo2TxZewvh EkZ8s1eqQzmkqEw/T4c3DnAg86Gs/xIiVJO1h+9el0i82Qlmgu1vraVH2f2D9rddnd 4DlViFsbCMmTT55sZIiZwvcahCDpMeUqODB0mDtobxwo1PTYIKOb/t2Baido8+qqPD ZanyMSPeFcah1u+N9U8Gbs7b8xonaGmffMjGWR+HPMsgRRa9+1T6QHBDzzEvR/3zHx ZPCkvdjka+ahnZPdOQfgsrfQphChY+NGwYX1/ZXljnBJkahyko326kvCZMr91kOuey TGQlBpHNhGX9t1haLmDSI4QK+fAdBe6qS12uCaTY7neuVUN4wJ8aOdWjAXaibVyfdm OZL1rADRWyLuz4u8IAUdY6MSY/14h/A6Ra70eDUxvNbWmcjE6vDDR+mV5NX3ecrDEr UqQzXXr459AV1ZddaxUfdVGA= Received: from zn.tnic (pd9530f8c.dip0.t-ipconnect.de [217.83.15.140]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange ECDHE (P-256) server-signature ECDSA (P-256) server-digest SHA256) (No client certificate requested) by mail.alien8.de (SuperMail on ZX Spectrum 128k) with ESMTPSA id 3868140E01F9; Tue, 9 Jan 2024 12:29:11 +0000 (UTC) Date: Tue, 9 Jan 2024 13:29:06 +0100 From: Borislav Petkov To: Jeremi Piotrowski 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 Subject: Re: [PATCH v1 04/26] x86/sev: Add the host SEV-SNP initialization support Message-ID: <20240109122906.GCZZ08Esh86vhGwVx1@fat_crate.local> 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> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline In-Reply-To: X-Rspamd-Queue-Id: 5037480017 X-Rspam-User: X-Rspamd-Server: rspam11 X-Stat-Signature: 594hhxana73az6i358pyjigfor9ffgeg X-HE-Tag: 1704803397-14115 X-HE-Meta: U2FsdGVkX19RddoERqS8Up9Zbqw7zkaVbw1rU7KF0Cc7A/kEREF7kNGya6tFVCht2D0oIts4LGKz49fvaGbMWKDGGEYyGZjoGUx99JFr9XE41kCBI9C+Y22oyk/p38X3QhDefNR5alLANTSkPfwl+9Wsi2CZNEJIx+hK7lrtOoH2hpqjLqxRD5RpImddkc0uTg9h0BVH0r9+nqG+fPtep74+eNBzrAdXjTIS8zfbedGydsKDmJas5cYeTyqpzYnb7rXlFofTuhclVEip7P28w75J8AiHkT/Q5OL7+1RX2xpDqeWO2/uL5iLbbX4if77mefOaAh0P+u444uHTDfTkILYR6sMXWXRJMuxLVVa1z0NZwNyXGQc6034UZeLvqC6ELyvugVB9R2JEqdzU7vqjUr4oFk+J3lL1HutaaI65kTKJ1Q3kFPhESbcru29LVhPYKfx586eiPXZ/9pzDyjLpbxlx7chARcyQPsMy0QK77sDphWrk9L88rXQ8tAWsafu6iXlncE+v/B049kagcb6CcK1Og/AdMkeOtcBBo8+vjwBug/Cgow0I+biJfLLHwUCKZSASckovhJSQnzNybApi89lJTimM9HKfjytM3WbzJTjELYQomLjKNakXYN9wPD5SIypAfcPBHNTRTid+xXpKZGewKVLA/YgTVYqOteAz1otEAZ/MeKx4H8urK6rNkBNP6mWVTfRH+nHY7ppH50kq4Bn7Prv77QBmWhXUCaOlNMrOUvl8akmtIjDSFLTkhDD7KKm/w1GKY17CHee2D3fyON0oDpMpuzlMmivicyvXCtwejffa4TU93lroOCy19+gzghzBsUnZn+3M8SgIpmPb4fdtgGjoX2e/ZmyePLBFEFN+h/0L+JH2t+bSxFJxPuNsUphP5QIs7XrQqZxXcX5K+oatGIcwFjnX7Kzq1WGgCgD8K8hyorjpteWX6V9mpWyH4B4w/0jXpsWI+PicP4S uPISJEjO 4S2A3dvWjm85tyI8eHLrPjME5gOU/KwwugD+f+Kfnryo0g9qG1QSsgLj66Ic4nc74ktiN0QQZpuFDWPlPUnIA6sD7cG22tCwBzmXbJUV2Kyuhk4uj2k9v6vIYaociwRFzY+N3//q1xMvSHCXM5fwAO4BTNAoFGvse08jjTXi1RJ9JKi9e3cEfEv0y5LMDRJtwA+Oy9bkQIEKJ2jg= 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 Tue, Jan 09, 2024 at 12:56:17PM +0100, Jeremi Piotrowski wrote: > Can we please not assume I am acting in bad faith. No you're not acting with bad faith. What you're doing, in my experience so far is, you come with some weird HV + guest models which has been invented somewhere, behind some closed doors, then you come with some desire that the upstream kernel should support it and you're not even documenting it properly and I'm left with asking questions all the time, what is this, what's the use case, blabla. Don't take this personally - I guess this is all due to NDAs, development schedules, and whatever else and yes, I've heard it all. But just because you want this, we're not going to jump on it and support it unconditionally. It needs to integrate properly with the rest of the kernel and if it doesn't, it is not going upstream. That simple. > I am explicitly trying to integrate nicely with AMD's KVM SNP host > patches to cover an additional usecase and get something upstreamable. And yet I still have no clue what your use case is. I always have to go ask behind the scenes and get some half-answers about *maybe* this is what they support. Looking at the patch you pointed at I see there a proper explanation of your nested SNP stuff. Finally! >From now on, please make sure your use case is properly explained before you come with patches. > 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. At least three issues I see with that: - the allocation can fail so it is a lot more convenient when the firmware prepares it - the RMP_BASE and RMP_END writes need to be verified they actially did set up the RMP range because if they haven't, you might as well throw SNP security out of the window. In general, letting the kernel do the RMP allocation needs to be verified very very thoroughly. - a future feature might make this more complicated > 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. I very much appreciate the help but we need to get the main SNP host stuff in first and then we can talk about modifications. -- Regards/Gruss, Boris. https://people.kernel.org/tglx/notes-about-netiquette