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 7FB51C4332F for ; Tue, 7 Nov 2023 19:20:20 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 0601980009; Tue, 7 Nov 2023 14:20:20 -0500 (EST) Received: by kanga.kvack.org (Postfix, from userid 40) id 00F638D0001; Tue, 7 Nov 2023 14:20:19 -0500 (EST) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id E197580009; Tue, 7 Nov 2023 14:20:19 -0500 (EST) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (smtprelay0015.hostedemail.com [216.40.44.15]) by kanga.kvack.org (Postfix) with ESMTP id D2D898D0001 for ; Tue, 7 Nov 2023 14:20:19 -0500 (EST) Received: from smtpin12.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay08.hostedemail.com (Postfix) with ESMTP id 97D5C140A90 for ; Tue, 7 Nov 2023 19:20:19 +0000 (UTC) X-FDA: 81432124158.12.F6D18BE Received: from mail.alien8.de (mail.alien8.de [65.109.113.108]) by imf27.hostedemail.com (Postfix) with ESMTP id 97AF74001F for ; Tue, 7 Nov 2023 19:20:17 +0000 (UTC) Authentication-Results: imf27.hostedemail.com; dkim=pass header.d=alien8.de header.s=alien8 header.b=Mcjp72gf; spf=pass (imf27.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=1699384817; 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=45+Y4ZldnKZEWvtvZx7/+i+9LPa3k5MrmiBFv7on6aw=; b=fY63Hx36KUBq7gFK4mxhXFfUVlKL3s3qOg9s+K6vTfIKjdpCEYLr7hH/h0YMKKR1uDk3eD W971wPQLuEwjeItyRPYwD/ecIl2m7cw0cqQbV8idKb0lwSRFCFoahqE5RfgVSOxB4Sadc3 2EIIkf+yVbYmW3QphNk4JupEYCK95E4= ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1699384818; a=rsa-sha256; cv=none; b=wakpDxSNKMQf2S0vaOAP3XRY6Ch1O/3IcB+xYpO6uWi+55xJ1vFSySQDCYsIa7fCN9w4WZ L3IwuxBxvqazBx25xBApV2eN7NOYhhPTc+VjG5KW0t+rJf8Tbo8e4UtMDDOF2mj8/JmoYf llW9Fs0OY1ek7F45VjulD1uDODpMTdk= ARC-Authentication-Results: i=1; imf27.hostedemail.com; dkim=pass header.d=alien8.de header.s=alien8 header.b=Mcjp72gf; spf=pass (imf27.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 6476340E01A4; Tue, 7 Nov 2023 19:20: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 95wN8euUxzc8; Tue, 7 Nov 2023 19:20:12 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=alien8.de; s=alien8; t=1699384812; bh=45+Y4ZldnKZEWvtvZx7/+i+9LPa3k5MrmiBFv7on6aw=; h=Date:From:To:Cc:Subject:References:In-Reply-To:From; b=Mcjp72gfr5TIXzL3LOnywlS0Oc7dftWQNXzRJinscdoNgSnV/MTK4g3JQZUhvheZu KZSGTEjsek7HFioitGZaeM/aDsoGq7jNrfj1Fn2PvpK/gD+rzuE0clPUobE3fBBV83 +ByJ0SkyLFRFnnP/ddJ5ZCZ1lrVrUX4//6slNDkugyJruEPBitwnckl09v7MMjP11d wFKpPSTopH31YMCMfQmVzO4FjxNtCE47XLH4mjlSJlszErJWtjqlslGkOh3MxCrPae FYThLNAJc2xof/XXXLlJpGJxGzs0lvhtKRiwxHNDYyqlDYkPR4y3bCwn/7JbeHjiGr 47rNQGUtzeKjYQPpF5OKU0sSoIpY5hodnA58uyFFMEMeTgN+FDfKiuZHaFqRW1U46P CJWMGLWuRqhFYqgUaXvBGN9/VGmkF9kDiuLpt0iegWRSlKGG8qAhAe11tp0UbPZn5y WRTZBx7Wdx+v52nrsWkZgytOrM+OiKPkKdZHFbLyh/1hkOLmcZGvceTPsYQ7cDChME sYEzyM3+fZTULAVQIUJfxdk5szlVClAIH1HWpNchhR0zNpq8seYmwXpPf45vb2o1pz 4R4jSwqVR7gxmBqkznhzfEh2Su2UPQe7qddaicycaE6MZR9m4Xvd9gy0dvvawof5uB bC9MB+QAvPpbJxnkQuUuxom4= 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 C822D40E0191; Tue, 7 Nov 2023 19:19:31 +0000 (UTC) Date: Tue, 7 Nov 2023 20:19:31 +0100 From: Borislav Petkov To: "Kalra, Ashish" 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, 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, 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, nikunj.dadhania@amd.com, pankaj.gupta@amd.com, liam.merwick@oracle.com, zhi.a.wang@intel.com, Brijesh Singh Subject: Re: [PATCH v10 06/50] x86/sev: Add the host SEV-SNP initialization support Message-ID: <20231107191931.GCZUqNwxP8JcSbjZ0/@fat_crate.local> References: <20231016132819.1002933-1-michael.roth@amd.com> <20231016132819.1002933-7-michael.roth@amd.com> <20231107163142.GAZUpmbt/i3himIf+E@fat_crate.local> <4a2016d6-dc1f-ff68-9827-0b72b7c8eac2@amd.com> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline In-Reply-To: <4a2016d6-dc1f-ff68-9827-0b72b7c8eac2@amd.com> X-Stat-Signature: hu81pr8qo6epn6gso8hscr73iaaaujmh X-Rspamd-Server: rspam10 X-Rspamd-Queue-Id: 97AF74001F X-Rspam-User: X-HE-Tag: 1699384817-784364 X-HE-Meta: U2FsdGVkX18yk9SCEKMPCppL/UKfnLJuStm2llWnqIZ9JP8i1AwPKwbDkEkVVZ+7MD6CX4bZC32GQZ+DShIyQGXUmnjVsB514lt4vg6FjzyUMOSTys7GjWg9aF1IThN2EObZf03EhTnZ/rD2D2GbOU4qjJNs6I5Va3ptsifOeQDufspHDRISBok9yS89xefoRvwfWudpGA6S8rdWV4Sj5+QMZEwoJ2oGwhgVK5IwNFZpw8HXeIZPAJ2Oq0boVOqf7Nfwtlwz+NVKINJdiW3l1l490/9acvwZ6dqE5L5zzUdl46hjyeuBDR6u5pKSMitSuvoROAOAi2HGfQGTO6QtOpyVoRkYFiUajxJUS0aPL2sMU4PmmMZ0OjM9K0REXqZW2CUZ/NnMyz9Yxteouok4KJ5ah3S/8Y1hajXliEBFl1gGVmqsVq2d3yUO2EP7El7r5xw5WKSEXLTbFXQkBSXEaJ6JfEoqyoas0RpO5OfVUNw6wNhOOqSum4BcqWBJRIhiS57RJWtbOH6/gIgz6PxGEOvzK3LN4ATjO6qCcpR53gPqlijwsDC0Bs+XUDSQs6SjFerK54c1wAc2HLiP5L2IKh0Wes1bJq85n8xwP2O21sStLEO2I6HafpBSGolas4sjrsU2JxMBpYLlQINnFR+sB1H2wmQ/R00w0LFOR1vBrMo2fWD1hFQFf1yYsnV5rlJd2zpfkos8ML1DxJ1Fru6K/w2TDSNPFOL6FBRm2VDq80ZCLmtqKTIHdxfGGVmTafMX8UDANI7oYhOEnAI7JEdLkUaH/BSAYsDYPkOpONqrCnbX8XWxw8qBRGDB0+QZIYolCDOqV42GWxj58IfsbECY56rPzdRavrlcRD7M6qOQSo2mbsPiNkfp9+gbagTEl7jqvJrWSeFY0V15p+kxXQZOxK/aMM5tEJbYEaDHH5GAE/IeoaYIJnwblERETcTUrD2jOSRtGZepnNfMTXjnjSO RE6QaxOF flVDU1Fgg5XKKxNowZaJuJt9pqDIeYreXDY6rtJG+Ku7kQ5fNM2ExNXS/faoDkrJHwhbRh9bavQHvFxI6WiBsHuQVb+h2NiPD1ootdKi5y0jjIgSjxRKTd6wzcwDU/U/inFbo5ujzdvgpq8gYgOLSdHhW4Pr8tlAmubYnsniLH7w7+O4E8r6vIHtdOBe9pZz0uyYQbzPxi91ObyA= X-Bogosity: Ham, tests=bogofilter, spamicity=0.000001, 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, Nov 07, 2023 at 01:00:00PM -0600, Kalra, Ashish wrote: > > First of all, use the APM bit name here pls: MtrrFixDramModEn. > > > > And then, for the life of me, I can't find any mention in the APM why > > this bit is needed. Neither in "15.36.2 Enabling SEV-SNP" nor in > > "15.34.3 Enabling SEV". > > > > Looking at the bit defintions of WrMem an RdMem - read and write > > requests get directed to system memory instead of MMIO so I guess you > > don't want to be able to write MMIO for certain physical ranges when SNP > > is enabled but it'll be good to have this properly explained instead of > > a "this must happen" information-less sentence. > > This is a per-requisite for SNP_INIT as per the SNP Firmware ABI > specifications, section 8.8.2: Did you even read the text you're responding to? > > This looks backwards. AFAICT, the IOMMU code should call arch code to > > enable SNP at the right time, not the other way around - arch code > > calling driver code. > > > > Especially if the SNP table enablement depends on some exact IOMMU > > init_state: > > > > if (init_state > IOMMU_ENABLED) { > > pr_err("SNP: Too late to enable SNP for IOMMU.\n"); > > > > > > This is again as per SNP_INIT requirements, that SNP support is enabled in > the IOMMU before SNP_INIT is done. The above function snp_rmptable_init() > only calls the IOMMU driver to enable SNP support when it has detected and > enabled platform support for SNP. >v > It is not that IOMMU driver has to call the arch code to enable SNP at the > right time but it is the other way around that once platform support for SNP > is enabled then the IOMMU driver has to be called to enable the same for the > IOMMU and this needs to be done before the CCP driver is loaded and does > SNP_INIT. You again didn't read the text you're responding to. Arch code does not call drivers - arch code sets up the arch and provides facilities which the drivers use. -- Regards/Gruss, Boris. https://people.kernel.org/tglx/notes-about-netiquette