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 7FD69C4332F for ; Wed, 13 Dec 2023 18:54:22 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 162486B0583; Wed, 13 Dec 2023 13:54:22 -0500 (EST) Received: by kanga.kvack.org (Postfix, from userid 40) id 1131C6B0584; Wed, 13 Dec 2023 13:54:22 -0500 (EST) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id EF4396B0585; Wed, 13 Dec 2023 13:54:21 -0500 (EST) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (smtprelay0016.hostedemail.com [216.40.44.16]) by kanga.kvack.org (Postfix) with ESMTP id E12DF6B0583 for ; Wed, 13 Dec 2023 13:54:21 -0500 (EST) Received: from smtpin30.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay01.hostedemail.com (Postfix) with ESMTP id B08E41C12EA for ; Wed, 13 Dec 2023 18:54:21 +0000 (UTC) X-FDA: 81562695522.30.CDCF0A4 Received: from mail.alien8.de (mail.alien8.de [65.109.113.108]) by imf04.hostedemail.com (Postfix) with ESMTP id 732984001E for ; Wed, 13 Dec 2023 18:54:18 +0000 (UTC) Authentication-Results: imf04.hostedemail.com; dkim=pass header.d=alien8.de header.s=alien8 header.b="EXaP/+Fb"; dmarc=pass (policy=none) header.from=alien8.de; spf=pass (imf04.hostedemail.com: domain of bp@alien8.de designates 65.109.113.108 as permitted sender) smtp.mailfrom=bp@alien8.de ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1702493659; a=rsa-sha256; cv=none; b=kQosYKS2EWf4OcMl3JuWuRhrDvLTd1If66LnHVdf47CwYTLk6NjBQkxgx3jcPX0hoivj7W 1Sa7+PbTC9cgTUTzGrABYQuKQ+UNPHcTmtUJ5xPuiyqwdGQMnWr419gQ+Fo7B7AoDHcgEk fG4LNjGjCiFVa76kJLvCvhG+Y8xV/Js= ARC-Authentication-Results: i=1; imf04.hostedemail.com; dkim=pass header.d=alien8.de header.s=alien8 header.b="EXaP/+Fb"; dmarc=pass (policy=none) header.from=alien8.de; spf=pass (imf04.hostedemail.com: domain of bp@alien8.de designates 65.109.113.108 as permitted sender) smtp.mailfrom=bp@alien8.de ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1702493659; 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=e8bfGWqQN7jlEtFTw8d4r238b6Fxps9y+tq5Io28pc4=; b=Wop0OHJYec/dWzgRP4rBpjpx1G377miBb6scPJzLgtyTHNsKzBipueTCCdr28Rn6ITGfmQ +GLiA8KOxEo27LncCbpTE3wgNZ5tAdfBGwpZoutWHZXVRe8q+E5WGdsmOBrwZGhMTXmPUv Thk2jv6UTkqiydgnE6kGbTaRMx0yDWs= Received: from localhost (localhost.localdomain [127.0.0.1]) by mail.alien8.de (SuperMail on ZX Spectrum 128k) with ESMTP id 4F63840E00CB; Wed, 13 Dec 2023 18:54:14 +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 zcoG-nFJKqRJ; Wed, 13 Dec 2023 18:54:12 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=alien8.de; s=alien8; t=1702493652; bh=e8bfGWqQN7jlEtFTw8d4r238b6Fxps9y+tq5Io28pc4=; h=Date:From:To:Cc:Subject:References:In-Reply-To:From; b=EXaP/+FbQNMwCok52oVms60raXIzpNrcn6C1msPBFP16C6xPhDXgtGL+GYz+x5E+0 l6AOXSLgWbEaGwG8GAjkmDLoR6eqKJZO8cb+AMzilLSoMazjwWHgf9STXDsOKtEh76 HimWjiZwf62VtXnzdU6Z/2/8dbeYqs2do8BuszSxR4mjBRbw126uAIGlVgPlK6iU7+ E7qi+bgtiMQaDzPdAGwZBnQdfThGizgdwCDclUEBLi+PpyDwSfS9CvSoEGzAI04+lO bZ9pROCPQIoAawMIS+9dPulUiYLN0zmTUh1unxtB/iShJTI5wI6BUtf3v59xd6eVN7 BY2lgPAGZl39yYzsNeHW6R2b650YUWykd0kkZdnMFPINLy8kiGqJpT7/FSii5eSHKC d4BnojkUm/Xy85qs4br4KoR1EYV7PqXCFjeKA4f6BlkAZRrGzFgg94AmPGgiQyELo3 l4YkkdKX3BHrefOYp3eXpygrDFySXD9IoQIoGDUmWAoNTc3F3U3ojcKX9Cvt2C+cYO 2f/o5KYscSu/daZcGnfboAa3C8DCDuyMQ8ert2AgryZ72eHmRB96dbAQx3IxJuzghS 0f00YqTMHhOWdaR0Z3Qtel14h1zTzT7Lk8TA8LQJs3SYDbjxEqaRtsncV0HN4XMC94 nLjoNX1NlmyFijuh9Sr5lavU= Received: from zn.tnic (pd95304da.dip0.t-ipconnect.de [217.83.4.218]) (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 73AE840E0140; Wed, 13 Dec 2023 18:53:30 +0000 (UTC) Date: Wed, 13 Dec 2023 19:53:25 +0100 From: Borislav Petkov To: Paolo Bonzini Cc: Michael Roth , kvm@vger.kernel.org, linux-coco@lists.linux.dev, linux-mm@kvack.org, linux-crypto@vger.kernel.org, x86@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, 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, dovmurik@linux.ibm.com, tobin@ibm.com, vbabka@suse.cz, kirill@shutemov.name, ak@linux.intel.com, tony.luck@intel.com, marcorr@google.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 , Jarkko Sakkinen Subject: Re: [PATCH v10 04/50] x86/cpufeatures: Add SEV-SNP CPU feature Message-ID: <20231213185325.GJZXn9pbqnjBGrQv4A@fat_crate.local> References: <20231016132819.1002933-5-michael.roth@amd.com> <0b2eb374-356c-46c6-9c4a-9512fbfece7a@redhat.com> <20231213131324.GDZXmt9LsMmJZyzCJw@fat_crate.local> <40915dc3-4083-4b9f-bc64-7542833566e1@redhat.com> <20231213133628.GEZXmzXFwA1p+crH/5@fat_crate.local> <9ac2311c-9ccc-4468-9b26-6cb0872e207f@redhat.com> <20231213134945.GFZXm2eTkd+IfdsjVE@fat_crate.local> <20231213154107.GGZXnQkxEuw6dJfbc7@fat_crate.local> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline In-Reply-To: X-Rspam-User: X-Rspamd-Server: rspam06 X-Rspamd-Queue-Id: 732984001E X-Stat-Signature: s3mr8amifc5u9nfd146zg3bt6x9toit5 X-HE-Tag: 1702493658-921184 X-HE-Meta: U2FsdGVkX1+GXdjVZqE3dL5yia6WZRLdPgOnuFdCr7EAaFJZXoqxXpjqoq72oanHwy5ksWYoqWtDBU1IoNH2TTgupGUJnbOIrHuDXM54TnTLJ3fzgwlYFL/jmD4s36JVklVDIzgl6O+r/uHYoWc75T73fDoh5O7LX/nxLLFL6sIRuwXqIejnGhY80sjpayIwumGNYcglcaDXJw2nhetqkZIzoUS3p6eTCmIo2VZ5YIC7gyXXxyJwj9tqv4z3zN+xF/NMWYarhYq1NhHvJhELkaaoqze/Q/Qu46i7oO+vvSJT5JZE4MbTCHRYqvStQGFafuKjx/Fqc2IOm5NdIcYphHy3HRuWrJsWnRjlpY7PdgrjOixHVG7zgxJDOgDSpq3QMpfFt1GX+j28hg72cSIArDL8V7MHkidqHrIQAsl/aHkfIZ8FBlg34V/00GgMPDGMbWuzTHcuLx6w8IYmm8ermPiKFqFsPuVWgJ9Dd9L7EXuaU2Oze0bNHResiO/1b9GgQ7u6Z80pnz5gTSoJvX2JbJYrDeh5H1a72vpNqFFGnprO2oL2Gyt4A2uzXZ6ub7/Vw0vg0zs2uxNH6qoJzwcP9AY3I9m7AjI7zkjrOfCXf2GGnG9L9ZY3jrvgVg7d/Fw7Er3ENGbkhvNYfwNrab178Pm0rz9jJbUP8SN18v3xTdpe9Xbq3xm+JLml0LQaTARf+OtAnNU7WcvxT+VEKw82H1+MVeJDmb3n8J0YQ2qhHgv6Rkn4gix5goxtadBEnOCRhJBOyuTnlVAxfchyo8dBaN6t9KOHT8ZSXe+N4c8+G7cUs3gdtv4cUm1tZrSNnI+t6PKmQH5/9BKMHKzHnvwVzKBL3alH4kYQewIsfKsdb1oVZ1UJM94ffXYYwy7ENXewOSiOnYSlq5mDgXHmGN5y4VfkacUcT3NYzMbiJ+HGniwsheMzfmg+f81BkgSyTUEVLu4V7nFAI0Ip6xDzvb2 NIdrI4g/ mj8iUhJ8mDvIHNvcJe3UtoZ9Eg9f+0Px7q3MkME5S1JPwvgNbUCymwYhtpxsjvDd5Gy0Z8Fhi+8bAZjMz/i9XuUy0TGl8TtSxCqVZ5BqRieBlID48NHY1ofhP+HK1LxvIctck6bLoTYMhzteg3/6ZTWd+fSYbnd9pRQ+JpFXmEMz1fIZOeYNJSOfeWdFJVg77ZanmSagsb/9c2Jw= 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 Wed, Dec 13, 2023 at 06:35:35PM +0100, Paolo Bonzini wrote: > 1) patch 4 should have unconditionally cleared the feature (until the > initialization code comes around in patch 6); and it should have mentioned > in the commit message that we don't want X86_FEATURE_SEV_SNP to be set, > unless SNP can be enabled via MSR_AMD64_SYSCFG. I guess. > 2) possibly, the commit message of patch 5 could have said something like > "at this point in the kernel SNP is never enabled". Sure. > 3) Patch 23 should have been placed before the SNP initialization, because > as things stand the patches (mildly) break bisectability. Ok, I still haven't reached that one. > Understood now. With the patch ordering and commit message edits I > suggested above, indeed I would not have picked up patch 4. In the future, please simply refrain from picking up x86 patches if you haven't gotten an explicit ACK. We could have conflicting changes in tip, we could be reworking that part of the code and the thing the patch touches could be completely gone, and so on and so on... Also, we want to have a full picture of what goes in. Exactly the same as how you'd like to have a full picture of what goes into kvm and how we don't apply kvm patches unless there's some extraordinary circumstance or we have received an explicit ACK. > But with your explanation, I would even say that "4/50 needs to go > together with the rest" *for correctness*, not just to mean something. Yes, but for ease of integration it would be easier if they go in two groups - kvm and x86 bits. Not: some x86 bits first, then kvm bits through your tree and then some more x86 bits. That would be a logistical nightmare. And even if you bisect and land at 4/50 and you disable AIBRS even without SNP being really enabled, that is not a big deal - you're only bisecting and not really using that kernel and it's not like it breaks builds so... Thx. -- Regards/Gruss, Boris. https://people.kernel.org/tglx/notes-about-netiquette