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 7ECB7EB64DC for ; Mon, 3 Jul 2023 10:49:55 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id F2FB46B011D; Mon, 3 Jul 2023 06:49:54 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id EDFDA6B011F; Mon, 3 Jul 2023 06:49:54 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id DA7DC8E00BA; Mon, 3 Jul 2023 06:49:54 -0400 (EDT) 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 CB0236B011D for ; Mon, 3 Jul 2023 06:49:54 -0400 (EDT) Received: from smtpin28.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay08.hostedemail.com (Postfix) with ESMTP id 9259B14079F for ; Mon, 3 Jul 2023 10:49:54 +0000 (UTC) X-FDA: 80969980308.28.AFA8AE9 Received: from casper.infradead.org (casper.infradead.org [90.155.50.34]) by imf27.hostedemail.com (Postfix) with ESMTP id BDBBA4000E for ; Mon, 3 Jul 2023 10:49:52 +0000 (UTC) Authentication-Results: imf27.hostedemail.com; dkim=pass header.d=infradead.org header.s=casper.20170209 header.b=pLAZXR4p; dmarc=none; spf=none (imf27.hostedemail.com: domain of peterz@infradead.org has no SPF policy when checking 90.155.50.34) smtp.mailfrom=peterz@infradead.org ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1688381392; 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=Egmu4PcPG3YUkJp0tRZXJg7Ab4Gnh+DI3c4ffyVSY8s=; b=yEYVOSjYCZwgMMp8iRBg3BQ1VT5PgOPs925Ev7pxbKTYYkgjp1yMCoqa0QrELbdLOe3VE8 cYm+BD/5JlumthOXMUwh1srQ135MMrD728IVIWN4N/kanOnfw5WHPmkGGLiKUGgcfeVZ0r 5ByEfTt2lmb+dsLOvFbNrtQws7uRRsI= ARC-Authentication-Results: i=1; imf27.hostedemail.com; dkim=pass header.d=infradead.org header.s=casper.20170209 header.b=pLAZXR4p; dmarc=none; spf=none (imf27.hostedemail.com: domain of peterz@infradead.org has no SPF policy when checking 90.155.50.34) smtp.mailfrom=peterz@infradead.org ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1688381392; a=rsa-sha256; cv=none; b=KlM/VDHuGithk0xc7nN8YuuR8aSwIv85+cMFG/YuAr2jt2Z+/YTyHWdbvidMdcs3UeBBwu IR6mHJ80ZTVCaOhGN5xuO1I3mMf3v7woHjS8Y6IFRS6ZBE2rMAnVp5SMuyR6j5dQVGcdRF sbY4Ma38Jc5s+jcdJowk1T6HedoAkJA= DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=infradead.org; s=casper.20170209; h=In-Reply-To:Content-Type:MIME-Version: References:Message-ID:Subject:Cc:To:From:Date:Sender:Reply-To: Content-Transfer-Encoding:Content-ID:Content-Description; bh=Egmu4PcPG3YUkJp0tRZXJg7Ab4Gnh+DI3c4ffyVSY8s=; b=pLAZXR4pPvwfWO7Q6+RO4iVkSC 89KdYHUbzmv52oZQsddS68kNrKO1gS5HWOJ3mSnbApbQElGUoYWa1FfYTQZiGGdGI7ZoRuh3BiM5Z NakSPE6FSa14WvGpHUKF6yh1/t9P7ZZqJ6CEGahY/kTmKNkKRmsdgkGhV9AuIqrfQOvC6DmH6Jyl7 rgjJXdZBkj6XzBWdJC3kpV4JdCfV5Uvyib6Ix/fEoPmxFhOqhpUO5EXwEc1hHr7eM1+6soamrBdPH v355zIJglpkIRxKLkOVR+Q1tMAwkYQI/nij73qxWfoDB3GdWaFKYRjiZzDvot+3V2cr1mrUrT5/w3 bS4DQ97Q==; Received: from j130084.upc-j.chello.nl ([24.132.130.84] helo=noisy.programming.kicks-ass.net) by casper.infradead.org with esmtpsa (Exim 4.94.2 #2 (Red Hat Linux)) id 1qGH7n-008A7x-Ed; Mon, 03 Jul 2023 10:49:43 +0000 Received: from hirez.programming.kicks-ass.net (hirez.programming.kicks-ass.net [192.168.1.225]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits)) (Client did not present a certificate) by noisy.programming.kicks-ass.net (Postfix) with ESMTPS id BDA463002E1; Mon, 3 Jul 2023 12:49:42 +0200 (CEST) Received: by hirez.programming.kicks-ass.net (Postfix, from userid 1000) id A4CAF202A2A17; Mon, 3 Jul 2023 12:49:42 +0200 (CEST) Date: Mon, 3 Jul 2023 12:49:42 +0200 From: Peter Zijlstra To: Sean Christopherson Cc: Isaku Yamahata , Kai Huang , "kvm@vger.kernel.org" , Ashok Raj , Tony Luck , "david@redhat.com" , "bagasdotme@gmail.com" , Dave Hansen , "ak@linux.intel.com" , Rafael J Wysocki , "kirill.shutemov@linux.intel.com" , Reinette Chatre , "pbonzini@redhat.com" , "mingo@redhat.com" , "tglx@linutronix.de" , "linux-kernel@vger.kernel.org" , "linux-mm@kvack.org" , Isaku Yamahata , "nik.borisov@suse.com" , "hpa@zytor.com" , Sagi Shahar , "imammedo@redhat.com" , "bp@alien8.de" , Chao Gao , Len Brown , "sathyanarayanan.kuppuswamy@linux.intel.com" , Ying Huang , Dan J Williams , "x86@kernel.org" Subject: Re: [PATCH v12 07/22] x86/virt/tdx: Add skeleton to enable TDX on demand Message-ID: <20230703104942.GG4253@hirez.programming.kicks-ass.net> References: <104d324cd68b12e14722ee5d85a660cccccd8892.1687784645.git.kai.huang@intel.com> <20230628131717.GE2438817@hirez.programming.kicks-ass.net> <0c9639db604a0670eeae5343d456e43d06b35d39.camel@intel.com> <20230630092615.GD2533791@hirez.programming.kicks-ass.net> <2659d6eef84f008635ba300f4712501ac88cef2c.camel@intel.com> <20230630183020.GA4253@hirez.programming.kicks-ass.net> <20230630190514.GH3436214@ls.amr.corp.intel.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: X-Rspamd-Queue-Id: BDBBA4000E X-Rspam-User: X-Rspamd-Server: rspam05 X-Stat-Signature: 16h3wsgufqoqatp1mbpp91roxg7tfiuy X-HE-Tag: 1688381392-869740 X-HE-Meta: U2FsdGVkX18kYZchK5XizynDfVOyHd/im5+I+qysr1Axn8EMV9HIh8FB4QJiImEc/hMfwtNtK/BUFaBjHM+VXY8Qli84uWkasz6KoA2NMgcWpw/uv1IPcEj1r7bLFRFnNVBxoSDRB5B+9YFEvyhlUUx/dgSmuGctGLf/sXw6v4lZSkbavjK12zrz6n/kI0QG79/Je3MCTjdLpdr88GxjzNCc4oJtvVVJq3yYD5ItEKlgiNaezbn4U6CKW0czloSSdAUJ6Bx3sk9gOiWJ9c1Mxa9BqC7MG31kk80pLHFmAEk4AOd1eHiW/tw7BSOpZW6qxeeGrcDaGWli4m6vQXp/cFBFPMWmrPF1l+i0vfPzv0qQ2JGMCju7DZ1GzaOzP+2TTOgp4/lRP1/t+1+s0EvP/VqI5+1+0V7VekrH0z1S16fhDaARZtEjpaCye+FRNJ0iHkzTuQVeooove9Bq1OPNcdRY/ee/IKLRVvfIyfRaHg8dFBtD+2n2zdagrmfs3kcj/JiZhRe/TsFPI3UXZNhTFczq4vIwHIDX6czXX3vzlSzvDAZ0IZ4K5Yekvwa/lgKx5D2MVAJjcsbu2qEns2+xO4OjIq+py/zOzJ60Wcm3F3X49NTrm/p6SYLmuCpJc3D0NlqvNUD7HNzLjlqrKzILsr0r11/9jQtk58KLhJX8s9DO3jBGuW2k+OakFfiqUvDr0ib0Gq3ei4DpvWHD1hoNs0+eIFwoIldF97/0Ra+Ex0T05S38cxDMld8RZYAez4iFMhPOxTcoKahv861LfPbFqHfw/CchriIYyAzp6Bqk/tzv4N3wXBpqxooH2XzXmUA6GeBTtc6tlX35BsNF+qSN9bj5lNN7JoRAf6N54j9dmq2v/iTarbJByB/wwTKho6veYTNyFPeD5KsgqBUZP7GmpDDO3VGQnbJhjV7z1MK2P9n6U63LjhtFAmH5NGcj9NoKa8YWVU3QOVhDdJivc/M SbXKe8O0 GmQjqHs61TWT4jGyJ8eU/dlusA9buvPB3nbOG3PmB8JABjC9tlbBow3cdGJCivXe6JEPokYpvd1HFBjuddVTmFmFrcajZbifsS5I4nEiB1aMANO6UsKfekuSe/qOKFMOJmjqAW9tOpP6gyIMUBhCcWJRYgYpdS95VxO7Wk2LHR9+dGjG47kiM/fwyWuQvxl6QfQp5bXalHn1vV0pTx8/4eDMECHWEIdvLFRwirLE32s69OenQ9Pg0NMbgQMwphBSdK3Ua 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: On Fri, Jun 30, 2023 at 02:24:56PM -0700, Sean Christopherson wrote: > I dunno about that, *totally* killing TDX would make my life a lot simpler ;-) :-) > > > I don't get this obsession with doing at module load time :/ > > Waiting until userspace attempts to create the first TDX guest adds complexity > and limits what KVM can do to harden itself. Currently, all feature support in > KVM is effectively frozen at module load. E.g. most of the setup code is > contained in __init functions, many module-scoped variables are effectively > RO after init (though they can't be marked as such until we smush kvm-intel.ko > and kvm-amd.ko into kvm.ko, which is tentatively the long-term plan). All of > those patterns would get tossed aside if KVM waits until userspace attempts to > create the first guest. Pff, all that is perfectly possible, just a wee bit more work :-) I mean, we manage to poke text that's RO, surely we can poke a variable that supposedly RO. And I really wish we could put part of the kvm-intel/amd.ko things in the kernel proper and reduce the EXPORT_SYMBOL surface -- we're exporting a whole bunch of things that really shouldn't be, just for KVM :/ > The userspace experience would also be poor, as KVM can't know whether or TDX is > actually supported until the TDX module is fully loaded and configured. Quality that :-( > There are also latency and noisy neighbor concerns, e.g. we *really* don't want > to end up in a situation where creating a TDX guest for a customer can observe > arbitrary latency *and* potentially be disruptive to VMs already running on the > host. Well, that's a quality of implementation issue with the whole TDX crapola. Sounds like we want to impose latency constraints on the various TDX calls. Allowing it to consume arbitrary amounts of CPU time is unacceptable in any case. > Userspace can workaround the second and third issues by spawning a dummy TDX guest > as early as possible, but that adds complexity to userspace, especially if there's > any desire for it to be race free, e.g. with respect to reporting system capabilities > to the control plan. FWIW, I'm 100% behind pushing complexity into userspace if it makes for a simpler kernel. > On the flip side, limited hardware availability (unless Intel has changed its > tune) and the amount of enabling that's required in BIOS and whatnot makes it > highly unlikely that random Linux users are going to unknowingly boot with TDX > enabled. > > That said, if this is a sticking point, let's just make enable_tdx off by default, OK.