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 BC31BC47DA2 for ; Tue, 16 Jan 2024 18:23:10 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 2418C6B0080; Tue, 16 Jan 2024 13:23:10 -0500 (EST) Received: by kanga.kvack.org (Postfix, from userid 40) id 1CCA56B0081; Tue, 16 Jan 2024 13:23:10 -0500 (EST) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 01D1A6B0082; Tue, 16 Jan 2024 13:23:09 -0500 (EST) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (smtprelay0017.hostedemail.com [216.40.44.17]) by kanga.kvack.org (Postfix) with ESMTP id E15936B0080 for ; Tue, 16 Jan 2024 13:23:09 -0500 (EST) Received: from smtpin29.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay09.hostedemail.com (Postfix) with ESMTP id 9944080B3D for ; Tue, 16 Jan 2024 18:23:09 +0000 (UTC) X-FDA: 81685996098.29.6327C30 Received: from mail.alien8.de (mail.alien8.de [65.109.113.108]) by imf26.hostedemail.com (Postfix) with ESMTP id 6EF6C140026 for ; Tue, 16 Jan 2024 18:23:07 +0000 (UTC) Authentication-Results: imf26.hostedemail.com; dkim=pass header.d=alien8.de header.s=alien8 header.b="iT/Igi1V"; dmarc=pass (policy=none) header.from=alien8.de; spf=pass (imf26.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=1705429387; 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=UZ6G+J6ye64gzMjmC6lSx1WhjVghiKPeCR0bIv9HV54=; b=4/k13Mt6cwry+RpUlAd6QUw/1HmXLr5yKkN0m91UeC+2+MBg+ZnAmiEkVM/Kr6gK1G/JvZ 1S2NDEj3bERD4PgOKYIjkIq8fs5O9v8BRa8uQ6NeDWtbJUXzViSkCqsVJ+h5aQcR0sXQBe yE6/YY8BsWR0wlI0hsEpWO87IumraCo= ARC-Authentication-Results: i=1; imf26.hostedemail.com; dkim=pass header.d=alien8.de header.s=alien8 header.b="iT/Igi1V"; dmarc=pass (policy=none) header.from=alien8.de; spf=pass (imf26.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=1705429387; a=rsa-sha256; cv=none; b=sl+KiF7mlHg3CXwbRPHPWU/YZyLFrE69RT2k7a7djUObp4StYLxX4TFOT2KlxTUPE7cTUQ pv8yDbWj/8D4o5+Pj2B9iDaPqRcfnXeBzFf0qZLzmIHvHlOGUgdg1X7Xec/RDLi0/cSMaR 3BADgq06iTYbVzvC5OPJ0Zm5JG4/jUE= Received: from localhost (localhost.localdomain [127.0.0.1]) by mail.alien8.de (SuperMail on ZX Spectrum 128k) with ESMTP id 0579F40E01B2; Tue, 16 Jan 2024 18:22:58 +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 3FYGSk50diAZ; Tue, 16 Jan 2024 18:22:55 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=alien8.de; s=alien8; t=1705429375; bh=UZ6G+J6ye64gzMjmC6lSx1WhjVghiKPeCR0bIv9HV54=; h=Date:From:To:Cc:Subject:References:In-Reply-To:From; b=iT/Igi1VvZ6a4grjasUBsQ3NdbxVO1LZMf2kXl82VNfinMdUS0Ec9PcrPGaD1XYXR YdA48WrCcriSh2e1xb52ISkIy8H1Rrm524EZxg9aoINEgy9OXUaWhXGJa1lV94hImP YaODpfGf/w+A/eInOmc3DpCH5vcKshzQ9Mg3VBfLUNHhIWpa8jsF9ZzU5wtjD6WPhn DAIloOlghiaeyvEcwwen2OpIDhV0kjqSYj1GWUQm+vN63O24M4KXlaRkaruNlOwWGo h6tUDG57RTqsPMq+wIcj6Z+Z9NZ0DRB624YhMEin4N8pz2z7AbqUUiuXPHv878xWwL xULI9qMNlhWlYjI0zUTMS4dOnss7cKROp32wMTohATsxLHoXcYZR7FvUImvS6ECkrh CHT7ArPtEgM1vD2isJU2OhQk9QnEo9ikZJUhZDBpg2E9bK66pHThR7OpdEhIrDCpy6 GthkzXZNIYojH/h4s6yJMI6OwM4NHagRA0EuKgVwLbu2rXVZIybUYjMnw3NLd+1bXM Ujlxrws7Vk6QaiuBPnZ8+jgrI1UrwQm2aN9MZWjwjp8Zd9ZnOKPKTi/CovQK0x5Wu/ AuGWt9P+gEXnoQ0GUpRPlDUDUkghNjB1kzTfdx1ZoDopAUpzAca3zMaweDB0gIZUZr sFqXK/o7GqQGyHT5mb3FRkRU= 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 EA5AD40E01A9; Tue, 16 Jan 2024 18:22:15 +0000 (UTC) Date: Tue, 16 Jan 2024 19:22:10 +0100 From: Borislav Petkov To: Michael Roth Cc: Dave Hansen , Tom Lendacky , 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, 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, Brijesh Singh , rppt@kernel.org Subject: Re: [PATCH v1 11/26] x86/sev: Invalidate pages from the direct map when adding them to the RMP table Message-ID: <20240116182158.GHZabJRqUMAEidcee1@fat_crate.local> References: <20231230161954.569267-1-michael.roth@amd.com> <20231230161954.569267-12-michael.roth@amd.com> <20240112200751.GHZaGcF0-OZVJiIB7y@fat_crate.local> <63297d29-bb24-ac5e-0b47-35e22bb1a2f8@amd.com> <336b55f9-c7e6-4ec9-806b-cb3659dbfdc3@intel.com> <20240116161909.msbdwiyux7wsxw2i@amd.com> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline In-Reply-To: <20240116161909.msbdwiyux7wsxw2i@amd.com> X-Rspam-User: X-Stat-Signature: bs338pp1u8r1oroeqnbezchphyg58jw7 X-Rspamd-Server: rspam07 X-Rspamd-Queue-Id: 6EF6C140026 X-HE-Tag: 1705429387-348603 X-HE-Meta: U2FsdGVkX18Bll12juzo6DvMXfDL0wzDpcQT+rQPnat7FVHW+yEcnHVySMxrtW7E3bl6RPzpVz0EpjO3gSP4gvE6BDwWmK10vS2L73kuljtkMkT5nw29aMxbxf7kA5Rfozl5HdvdJZymXt6vsUB3gJkPjchyAjO2FDyNvM2eWlPBOIWSj+Lt0BNkC1WxYB566n+Sk/jKV3fIxkXyT3W+6xmc7E1NKsLWFP7SRfSlhZeG58A98BK/KSP/5TiUQhROwQHhVtGkA4eYOAQmZqDekJDVWj+XVgEwt3PM9UO/6ntz/gUx2Nj6SqCZ4HgPAoeFLvSGWEgv7GMI+ljgU5yLIU+pZlz14I3xgVLwzl9Xig9x9e/TrABFTpmaTuelxgudpbXgCPuJmAwLlV0Gvieu5RF5w0OGXcLrHTGunzlOvppuqWxHXRf5Ba6AiiC40qAXNsP2DQEqwEI0oj4K7UXw6HeSSVTJMtbWstB7WZlITf6yOdl1S71wWGMLTRVUBOSe54p9Ot+EsBS4tgaZKOLJ5NOSYD/nNFxnOyPx9AKYUd9eIFM9DBiKEvJLeaV3lD/VwlAq9lFFVS/lsVYxkdPqwjaellhsN2HZCYnvHGjbodrHktELjixWfZL05M15NEGsu1gR3m6JowVs4yjecTkAdTc3ZUAM3U+P/gStJRwcJ62DKfYDCBqpyQ9nB3nO4GF2jDGEicnz3KQRCttfiHmhkRcNYMwXTAZM2oOF+ZhqN9vRJoUZ6SZlFk66vUu6VOXBK4gC66VKKQrIGePiGUnkmAnUL6QdGjQ4HqTYJfJASO8pjchrabOFDBfhwWBT9AK3zB7WvZiRoZuKN6ZeIb2eIrOFar8Q0p3Wylu9Wq3fj0Uo2GYY+05KQkc7qye5X6VLkqKNsAB6acMrY088WtG0jiVMuVB5NnRSLSE+qw8GMR8bQmCr1/RSc98TljyDvL6ugYDbeq0YDaR/Ccp/8O7 6LB/MuUw cP4dpUe4sqJrvb+vxN7+DqPo/L30JBRr6PXIWmBcNoyQauHnC9oveWcgY71hgPWt3xxX66QEzZoZGX978+PnpHjj5j3fN2yc1nrOZZYx+KM3Acfw2H0dhdqeTvxW3DEt6rnWpHReXLpHQ34CQqG05Q6G1RrHKQJ8aTVxAf7WXiE51atN/kdNQQ1BXMx6y+1xB3UULbtnQ1/YT3Er2Mqtt/5XdTP748tTwlKamwisTYOrgSL7kn57A5n2t1MLSBPxmnrEGbE5Xc5e/PH/ULM3uUe75ag== 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 16, 2024 at 10:19:09AM -0600, Michael Roth wrote: > So at the very least, if we went down this path, we would be worth > investigating the following areas in addition to general perf testing: > > 1) Only splitting directmap regions corresponding to kernel-allocatable > *data* (hopefully that's even feasible...) > 2) Potentially deferring the split until an SNP guest is actually > run, so there isn't any impact just from having SNP enabled (though > you still take a hit from RMP checks in that case so maybe it's not > worthwhile, but that itself has been noted as a concern for users > so it would be nice to not make things even worse). So the gist of this whole explanation why we end up doing what we end up doing eventually should be in the commit message so that it is clear *why* we did it. > After further discussion I think we'd concluded it wasn't necessary. Maybe > that's worth revisiting though. If it is necessary, then that would be > another reason to just pre-split the directmap because the above-mentioned > lazy acceptance workload/bottleneck would likely get substantially worse. The reason for that should also be in the commit message. And to answer: https://lore.kernel.org/linux-mm/20221219150026.bltiyk72pmdc2ic3@amd.com/ yes, you should add a @npages variant. See if you could use/extend this, for example: https://lore.kernel.org/r/20240116022008.1023398-3-mhklinux@outlook.com Thx. -- Regards/Gruss, Boris. https://people.kernel.org/tglx/notes-about-netiquette