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 AB1A6EB64DC for ; Mon, 3 Jul 2023 14:41:05 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 0F79C280008; Mon, 3 Jul 2023 10:41:05 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id 07FF3280001; Mon, 3 Jul 2023 10:41:04 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id E160E280008; Mon, 3 Jul 2023 10:41:04 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (smtprelay0014.hostedemail.com [216.40.44.14]) by kanga.kvack.org (Postfix) with ESMTP id CC7FD280001 for ; Mon, 3 Jul 2023 10:41:04 -0400 (EDT) Received: from smtpin15.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay06.hostedemail.com (Postfix) with ESMTP id A2A65B0166 for ; Mon, 3 Jul 2023 14:41:04 +0000 (UTC) X-FDA: 80970562848.15.24F8E01 Received: from mga02.intel.com (mga02.intel.com [134.134.136.20]) by imf30.hostedemail.com (Postfix) with ESMTP id 163AF80005 for ; Mon, 3 Jul 2023 14:41:00 +0000 (UTC) Authentication-Results: imf30.hostedemail.com; dkim=pass header.d=intel.com header.s=Intel header.b=QVnWL7Lk; dmarc=pass (policy=none) header.from=intel.com; spf=pass (imf30.hostedemail.com: domain of dave.hansen@intel.com designates 134.134.136.20 as permitted sender) smtp.mailfrom=dave.hansen@intel.com ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1688395261; 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:content-transfer-encoding: in-reply-to:in-reply-to:references:references:dkim-signature; bh=XdQWHRKu5mEIFz7ZyQDtjnFZDAKJFsNsQ+01JMfsL4o=; b=K6uBky7McSRLEgZnWNjuQsegM3if9XFOIasz5ZgrxHSvYcbhmEa2zczGkkusLzAScLI+xK LcwXsbp95GewefaHx15DBCiVHeOVxceLeYCOPKFbCTuYl6y4wDyIVBciktHCaU2LkT+IEQ XrPJLpeu4G3LLbtTaLusx5k99Cgo5Mw= ARC-Authentication-Results: i=1; imf30.hostedemail.com; dkim=pass header.d=intel.com header.s=Intel header.b=QVnWL7Lk; dmarc=pass (policy=none) header.from=intel.com; spf=pass (imf30.hostedemail.com: domain of dave.hansen@intel.com designates 134.134.136.20 as permitted sender) smtp.mailfrom=dave.hansen@intel.com ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1688395261; a=rsa-sha256; cv=none; b=2iJ0+3pPjaLRjXKqfwyzTvBp4wVLrRb049k2kipocyi4wM1KGN4KxCO88eJqx6QsQ3izX5 Zugim4Ijja1ycfDC3Z8hQ4l18SM4D4s+ZxKsFYKopARHDKmXnRagbAnetPt1jPRKxmIKx3 9UiP4NUlbO9Sa6yFlxcDnbxQgzXomsY= DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=intel.com; i=@intel.com; q=dns/txt; s=Intel; t=1688395261; x=1719931261; h=message-id:date:mime-version:subject:to:cc:references: from:in-reply-to:content-transfer-encoding; bh=oiAYYlrvhxpb7dxgLlbZm7axICahdWtDSJkHwBkZwWs=; b=QVnWL7LkuD1v83c3FDOvS20E/pu2aEP7+9NlAmlJx5PUhCfTARzOJ8AH RkeE8Spen3ueHkvQHP0igeYVdHznCX/d9wL6Ic9fpBuel7gV6m/Ho3ACx aNnUpx4M52WTgn6F+DQrnG2PnQFsWZaeMrSg2+wKp6q7ZHZ6Qqfm+EaNB 0mlipSqw3eNDI+zDcax5ryGD9CeYNapvoelq66Bly3EZrKSwcHy3O9B4z KmuOoV5OXiYKV57v3M5KVwqw6rNHMBNrf/l1WV/wFp12XwqIV+J6TGjrM pnmXu6E7cbhQ4oJlLpsg5m9Z73gnfQCu7rKQ9n4w/p4Rxstrd5MzntIhp g==; X-IronPort-AV: E=McAfee;i="6600,9927,10760"; a="352724305" X-IronPort-AV: E=Sophos;i="6.01,178,1684825200"; d="scan'208";a="352724305" Received: from fmsmga005.fm.intel.com ([10.253.24.32]) by orsmga101.jf.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 03 Jul 2023 07:40:58 -0700 X-ExtLoop1: 1 X-IronPort-AV: E=McAfee;i="6600,9927,10760"; a="1049112742" X-IronPort-AV: E=Sophos;i="6.01,178,1684825200"; d="scan'208";a="1049112742" Received: from lbates-mobl.amr.corp.intel.com (HELO [10.212.242.115]) ([10.212.242.115]) by fmsmga005-auth.fm.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 03 Jul 2023 07:40:56 -0700 Message-ID: Date: Mon, 3 Jul 2023 07:40:55 -0700 MIME-Version: 1.0 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:102.0) Gecko/20100101 Thunderbird/102.11.0 Subject: Re: [PATCH v12 07/22] x86/virt/tdx: Add skeleton to enable TDX on demand Content-Language: en-US To: Peter Zijlstra , Sean Christopherson Cc: Isaku Yamahata , Kai Huang , "kvm@vger.kernel.org" , Ashok Raj , Tony Luck , "david@redhat.com" , "bagasdotme@gmail.com" , "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" 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> <20230703104942.GG4253@hirez.programming.kicks-ass.net> From: Dave Hansen In-Reply-To: <20230703104942.GG4253@hirez.programming.kicks-ass.net> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit X-Rspamd-Queue-Id: 163AF80005 X-Rspam-User: X-Rspamd-Server: rspam04 X-Stat-Signature: xawoz8a1rgtj98ehkmizb3y717nbtjiy X-HE-Tag: 1688395260-724103 X-HE-Meta: U2FsdGVkX18R0Cm1hk0AI3iT/kZmjqtzsS4EtxdfxgoZ/5/5rqPAv9dL9JLyB5OVqWXihBOKlroWZSHSezrlYjAg71JTu8dkrkjI1W1ICI9fOnsa8sqlSZXtU727YgvEY+28/E1Cr3RK4HmBEM1HdSDq8wN+OPF++ZtP7vbS7UO5hBoVmMzE3w+XANHXHw9CIGVdzycJryU5UvRZwjCYiC1riSe9utNrnORJQBdm0elJcx7+tr2MeoKHy11cB+aTv4H+FGf20fUQkUWBiDNim5RKkmIzKhW0P1dASEt0TsflQTKkWzgCeniet7hnUzlrygWsah2MwqrqDhrKL7WV/5b0GC4DyrEiSqdJLWLmhyCTCDBMLaaPFEpkcsuM5bMmv7ukSIBTWTV19TS7yAPQLukTKnnZ6JxijdGyFE/jIVKBrLQAhAOSHfblg+BwWxwCdk5bCPnj8yTQxQ5zE6NeV0KU2u193O0WISvOe+UKdmoMI0Jl9unm1uS6D78ZsG+owGTn6lZbdK1q0y6vubVeEdOOGp81zZ3+MQ2xL7/j+VIIwZOtAwfTCCINHu6TjEiuP5nL09IMbuHLOUXvnyGnK7UOrRxqB6QQgIPmbwQMdBV7QPV2cs/lFR/NsAei6AO9P6eJmx2WVUs9rJTB3/5edrwxvRJKQIH6mUEh1NV6vuY0Emx1PRbQ5NcmSb8oAUtfiOQwN6k5kGSrWc+v+Zs39WgSo0GPGuKwnHiTs3KhMayl0yTw1KAkxkKcWdS3tb6pA02R+rCfSfZK5gFqw4k+TGHk35YFz1pFupHPbfuSBnpa3t1W83S0n3Id6N1exD93oOp14qgsM+A568XY+oEBBw0OQX2xx9UYyscDAR1lmSSF4IQmODBpg6Rxy9a9jQljobSK/CaS/svsEx4fzPMYh+F4AjcgzE4iAzEarARclH3PSkiWxSGkora0OMCSo6YlqAJE/2kK06fe8j275Zx iirQGf2a kPnwGxmbddoI2xGJss/xo/4wGoIaDiLRRhgmhMv72G4PHc+g0S7XQKXLzacPxmgbjdG8e7OLQu+xrPysR49SxcPdQhaBkte9x7xga+LPOEw3PM3XEgzVBtVvYuqxBpVzEd7gWVgMB3pvKgxKINwAekTL/OG98K+0STbdcAIZZK5eiF1k8crAzt93K4IYPyGPyIdgo7YK8MSnVQhPfarGMxU7L4aWmd2MPBl5dcD6LOIjsXPc5MFCLKjPEIt1MBfLFWFgM 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 7/3/23 03:49, Peter Zijlstra wrote: >> 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. For what it's worth, everybody knew that calling into the TDX module was going to be a black hole and that consuming large amounts of CPU at random times would drive people bat guano crazy. The TDX Module ABI spec does have "Leaf Function Latency" warnings for some of the module calls. But, it's basically a binary thing. A call is either normal or "longer than most". The majority of the "longer than most" cases are for initialization. The _most_ obscene runtime ones are chunked up and can return partial progress to limit latency spikes. But I don't think folks tried as hard on the initialization calls since they're only called once which actually seems pretty reasonable to me. Maybe we need three classes of "Leaf Function Latency": 1. Sane 2. "Longer than most" 3. Better turn the NMI watchdog off before calling this. :) Would that help?