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 37E7CEB64DD for ; Wed, 5 Jul 2023 07:16:34 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id C5B316B0071; Wed, 5 Jul 2023 03:16:33 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id C0C286B0072; Wed, 5 Jul 2023 03:16:33 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id AAC7B6B0074; Wed, 5 Jul 2023 03:16:33 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (smtprelay0013.hostedemail.com [216.40.44.13]) by kanga.kvack.org (Postfix) with ESMTP id 9C50A6B0071 for ; Wed, 5 Jul 2023 03:16:33 -0400 (EDT) Received: from smtpin06.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay05.hostedemail.com (Postfix) with ESMTP id 6CD26401FE for ; Wed, 5 Jul 2023 07:16:33 +0000 (UTC) X-FDA: 80976700266.06.D683895 Received: from desiato.infradead.org (desiato.infradead.org [90.155.92.199]) by imf23.hostedemail.com (Postfix) with ESMTP id 19C1F140018 for ; Wed, 5 Jul 2023 07:16:30 +0000 (UTC) Authentication-Results: imf23.hostedemail.com; dkim=pass header.d=infradead.org header.s=desiato.20200630 header.b="DtgGzn/2"; spf=none (imf23.hostedemail.com: domain of peterz@infradead.org has no SPF policy when checking 90.155.92.199) smtp.mailfrom=peterz@infradead.org; dmarc=none ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1688541391; a=rsa-sha256; cv=none; b=YZES5oqFVsyIoWUbvFTgzD7LKCgiwGmSOVMGwqh8UQhNTmTq8/wgG2Uts7R4NacfTYvYY8 i1QOqTH9vLk5kBsxbNEVIAaQem6LmFih4N3fpySGX7WnRYGg8PrMSF1fllyatOq5dLIdCs czFQesplJTNhgQdjyaKveMYGjlmv9dk= ARC-Authentication-Results: i=1; imf23.hostedemail.com; dkim=pass header.d=infradead.org header.s=desiato.20200630 header.b="DtgGzn/2"; spf=none (imf23.hostedemail.com: domain of peterz@infradead.org has no SPF policy when checking 90.155.92.199) smtp.mailfrom=peterz@infradead.org; dmarc=none ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1688541391; 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=oCduNboc+Z/GXu+P5K5ealCYvHJhr9bE/XTSWcyXYU0=; b=P8zOZcGq/SlnW0DCJmDAIATlyJKj0dv6le6UwiGEPupEfyrMxSK+MrEIg+rPDo7d1IWLJG 0eYyTtLTjjtoiqN7oeufBP/Iw7y5xD8oztjuCOHb1yp/3LlonZJeirwIFmZyEsEKFLXSDF QPRGq0+AEsIJHJcErTZsHN7aRUMgNVU= DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=infradead.org; s=desiato.20200630; 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=oCduNboc+Z/GXu+P5K5ealCYvHJhr9bE/XTSWcyXYU0=; b=DtgGzn/2iSyk4rAQZePuRpGrwP tiTKW4fXbZoL5ClSF9V2NGWi/WsughnUEr2tOkB/UdVD/mQZn/A5E17x0ns6HhTO3EQaRWitIsMJz tVBfwrwQffccXTlAZHZrP1V/mHRU0v17phRidBMyycSxaZiHDx9ScTZFrkkcoGFBdO73PQH0TR0lo N8IcFt/OyUVlRayNpaetJJiANLqdGgtnif1Z+kXRuod7x1wA5Ptcc9oxRcXbYVYd7xn6KqotWcn4c 8lXvixxvB4D4MQklglElM/POaFZxTMgAdMTbtDcKMJPVyz/WKwhTQ1N+oXAhwR+q8mqr257XbIiHy ZWq57E/Q==; Received: from j130084.upc-j.chello.nl ([24.132.130.84] helo=noisy.programming.kicks-ass.net) by desiato.infradead.org with esmtpsa (Exim 4.96 #2 (Red Hat Linux)) id 1qGwkH-00Bzsx-1z; Wed, 05 Jul 2023 07:16:15 +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 B2ABD300274; Wed, 5 Jul 2023 09:16:12 +0200 (CEST) Received: by hirez.programming.kicks-ass.net (Postfix, from userid 1000) id A1E2C2028F056; Wed, 5 Jul 2023 09:16:12 +0200 (CEST) Date: Wed, 5 Jul 2023 09:16:12 +0200 From: Peter Zijlstra To: "Huang, Kai" Cc: "Christopherson,, Sean" , "kvm@vger.kernel.org" , "x86@kernel.org" , "Raj, Ashok" , "Hansen, Dave" , "david@redhat.com" , "bagasdotme@gmail.com" , "ak@linux.intel.com" , "Wysocki, Rafael J" , "linux-kernel@vger.kernel.org" , "Chatre, Reinette" , "mingo@redhat.com" , "kirill.shutemov@linux.intel.com" , "tglx@linutronix.de" , "linux-mm@kvack.org" , "pbonzini@redhat.com" , "nik.borisov@suse.com" , "Yamahata, Isaku" , "Luck, Tony" , "hpa@zytor.com" , "Shahar, Sagi" , "imammedo@redhat.com" , "bp@alien8.de" , "Gao, Chao" , "isaku.yamahata@gmail.com" , "Brown, Len" , "sathyanarayanan.kuppuswamy@linux.intel.com" , "Huang, Ying" , "Williams, Dan J" Subject: Re: [PATCH v12 07/22] x86/virt/tdx: Add skeleton to enable TDX on demand Message-ID: <20230705071612.GD462772@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> <20230704165836.GB462772@hirez.programming.kicks-ass.net> <0bd5a2f95a0f309ff35d511ce832c5f11abf6013.camel@intel.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <0bd5a2f95a0f309ff35d511ce832c5f11abf6013.camel@intel.com> X-Rspamd-Server: rspam08 X-Rspamd-Queue-Id: 19C1F140018 X-Stat-Signature: t68cbysuocru9irjxroeuusyxyk3fefr X-Rspam-User: X-HE-Tag: 1688541390-74706 X-HE-Meta: U2FsdGVkX1/THtHHEpSeGj2QEC6KGzRoF+h0MCesXFdfcfZAm+QaO3rVwcrZNx8cKwjv0PI9oQas8T0ZxaVDQQ9bTruO3OI9J7XgPLHzZ4u+P541RY0HLePtW/6lg078/GfqescnBe+Z/jNpr+x+qR+hovf531lrE8gsMBXBcufGM6tC44eeaWKrm8lwl5s0pe4vHIzbIsyJOVcdU3AzNPVzecbpoZf8sJAn0toKI8qU5gSSLBjQN/GlWzat/7GBhV5ORHUFNixKeDPKYM+2p3wARNMc9+rOUE9S+avKwCAWsNMNG6rlyulLwXplkxyjaiwmr6ltKSqmypv9hzbIQFO+bWnYR0nNulGNyabbdQuiZ3xS82HULrxXqyOErghY/ezD7hX64AXfUkm8Lxp01FqJ5vXa5FGDcjyKL2SRzgs1YWk6CMQ/8d490vdfwGDN6nSsXegUi77lr92lYlI9mfyo24F5w4Ew2spv5LMmpcAS++PiiEBUAf07PRJlFAz7DBt2A2e9A4LbGmo8u7VqPEkejPfGlpRJWyCgiUFr21Q6mSG9eci1O2Ge4EBhor5yE9j8UwDwu8A3ZCiGhfXvQ8a1X3K/e2P60HWp5agYwO49wuNqliXSdwStinOE+9Ahfa5eR9HWhTxM++RVA6bng1nd7e+sNyFJP6yKNa3bLu3ipuLi/YgY/XoRC5LG3mkBYSqWCHrHVqy5O9q7q5IEhY4ogiXzUB/3BDXuA7+CDsuFxDHxviCqkY5K28HbriwVgAvLO++HL58AA7ryy7i9QLtuHYO/6u++nMszAn3FX2JZif42L3XcKk9xHYq6jpzPPF5D3OsA8W1JfR49CJhfjZ5CxnYplYfNU9HCrnmn9kVF0wWgAuUned4LTBFq38EovOOfjH4c1++b6fUAVPkg0BgSCoUbet2byN5YGLG62vNqiJemiI4I8mpnerqKYArQxmvBJDR71T+8vBNcrzw fssz9X9/ u/Qcp7MWZzobvVBV4sMyAgyI49L1qMdRIIWw5cFXtAWCWmSmpdbRgIV+j+98U6nm2DvllTjN9iXdXkfjbdDQ3aBC84vUKHo4xBqM4L9wl/uVy91F1DvSYdUZlch/DWaTYudjKwtVBY+qju5Rhsr7RwmcAeuO2u7MXVAfFIlcgkDrB500aDgL0Mh6IffIynulCtDl5fsWoZKo2ruCu/bcTGF3QRrh+FKJSq0dyaKozgkkiR96wvq8C50Ih+sn+xtugnNfx X-Bogosity: Ham, tests=bogofilter, spamicity=0.000014, version=1.2.4 Sender: owner-linux-mm@kvack.org Precedence: bulk X-Loop: owner-majordomo@kvack.org List-ID: On Tue, Jul 04, 2023 at 09:50:22PM +0000, Huang, Kai wrote: > On Tue, 2023-07-04 at 18:58 +0200, Peter Zijlstra wrote: > > On Fri, Jun 30, 2023 at 02:24:56PM -0700, Sean Christopherson wrote: > > > > > 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. > > > > .... > > > > People got poked and the following was suggested: > > > > On boot do: > > > > TDH.SYS.INIT > > TDH.SYS.LP.INIT > > TDH.SYS.CONFIG > > TDH.SYS.KEY.CONFIG > > > > This should get TDX mostly sorted, but doesn't consume much resources. > > Then later, when starting the first TDX guest, do the whole > > > > TDH.TDMR.INIT > > > > dance to set up the PAMT array -- which is what gobbles up memory. From > > what I understand the TDH.TDMR.INIT thing is not one of those > > excessively long calls. > > The TDH.TDMR.INIT itself has it's own latency requirement implemented in the TDX > module, thus it only initializes a small chunk (1M I guess) in each call. > Therefore we need a loop to do bunch of TDH.TDMR.INIT in order to initialize all > PAMT entries for all TDX-usable memory, which can be time-consuming. Yeah, so you can put a cond_resched() in that loop and all is well, you do not negatively affect other tasks. Because *that* was the concern raised.