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 809C3C3063F for ; Mon, 3 Jul 2023 17:56:12 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id A9AF3280022; Mon, 3 Jul 2023 13:56:11 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id A4AE5280001; Mon, 3 Jul 2023 13:56:11 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 9129C280022; Mon, 3 Jul 2023 13:56:11 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (smtprelay0010.hostedemail.com [216.40.44.10]) by kanga.kvack.org (Postfix) with ESMTP id 80E8A280001 for ; Mon, 3 Jul 2023 13:56:11 -0400 (EDT) Received: from smtpin26.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay04.hostedemail.com (Postfix) with ESMTP id 3B1671A0760 for ; Mon, 3 Jul 2023 17:56:11 +0000 (UTC) X-FDA: 80971054542.26.948CD13 Received: from mga12.intel.com (mga12.intel.com [192.55.52.136]) by imf04.hostedemail.com (Postfix) with ESMTP id 8341540009 for ; Mon, 3 Jul 2023 17:56:08 +0000 (UTC) Authentication-Results: imf04.hostedemail.com; dkim=pass header.d=intel.com header.s=Intel header.b=RwH4N1OF; dmarc=pass (policy=none) header.from=intel.com; spf=none (imf04.hostedemail.com: domain of kirill.shutemov@linux.intel.com has no SPF policy when checking 192.55.52.136) smtp.mailfrom=kirill.shutemov@linux.intel.com ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1688406969; 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=WUqCjP8gyJBYyL/pVgvq58bWuy2Whhbm7i+atiqWTnA=; b=iAjXnEQttby2aPaqYa2ypKgRYW/aoypAZq6yujGWIXyq2jaiV1mf72v4eK/KQX1wBK6qxm 1zH7DuuAqDXVvwVFIkioNGv7zwlEPy11lv1lNictDNFMd7h5H11Gp23wyh4/CHxOguiw/g VSTA0eZ4FD5shcJgXh8nt8Dl3uV+T8U= ARC-Authentication-Results: i=1; imf04.hostedemail.com; dkim=pass header.d=intel.com header.s=Intel header.b=RwH4N1OF; dmarc=pass (policy=none) header.from=intel.com; spf=none (imf04.hostedemail.com: domain of kirill.shutemov@linux.intel.com has no SPF policy when checking 192.55.52.136) smtp.mailfrom=kirill.shutemov@linux.intel.com ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1688406969; a=rsa-sha256; cv=none; b=vaXFx9FwtunmCpuOjdOovYc7dU9gwusfe4FY/QZHFbggw/hzkVcvHEluqFlpbKnbtovuEx Gd/CnIy8pe7UJbGEPR5XD3ls2uS9mRohvKEm7Xgt+vubJnbXJaD/ZHKXtu8FUcbitaXuon wt5LgeBqjzaiKAQSGiQpScBvQX8wbAM= DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=intel.com; i=@intel.com; q=dns/txt; s=Intel; t=1688406968; x=1719942968; h=date:from:to:cc:subject:message-id:references: mime-version:in-reply-to; bh=tXCkUV57n+k42/6WNxCUqFu0N3OYKzthRacRkqM/8M4=; b=RwH4N1OFC2v2tjWs3dRtSMiTyOEH6iJ1PDXpvlBmzjA4RcN/VGSOHL5+ JZPKoaNXfV0dVlxj4PlAmYTm3wotBZtWC5uK25WEQAdKO3Gh7jHjYp1ce sIkmcN+0FTpLw1q99aufBmWo+irvrJt2RHBhyJoTLtzZlYBa7VluwSyso D+i0xk0ypnVhATY5DGpBsx8GX1bwGDPXM/Bqfe4HObwWoeZ+zS1WW+mQv hRZb2fl/7YvUsTL8amONgKX2Geo3cxR0Xuz4u3NCJ21aQ0rBgvBaRp1pz xCAGBUi3NWGPUz17+9xLOHaTMsiwPNiNbW3TUeZAQnUiBYNP/5dBWDM8l A==; X-IronPort-AV: E=McAfee;i="6600,9927,10760"; a="342528982" X-IronPort-AV: E=Sophos;i="6.01,178,1684825200"; d="scan'208";a="342528982" Received: from fmsmga004.fm.intel.com ([10.253.24.48]) by fmsmga106.fm.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 03 Jul 2023 10:56:06 -0700 X-ExtLoop1: 1 X-IronPort-AV: E=McAfee;i="6600,9927,10760"; a="788597117" X-IronPort-AV: E=Sophos;i="6.01,178,1684825200"; d="scan'208";a="788597117" Received: from foliveix-mobl5.amr.corp.intel.com (HELO box.shutemov.name) ([10.251.218.218]) by fmsmga004-auth.fm.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 03 Jul 2023 10:55:59 -0700 Received: by box.shutemov.name (Postfix, from userid 1000) id B504410955C; Mon, 3 Jul 2023 20:55:56 +0300 (+03) Date: Mon, 3 Jul 2023 20:55:56 +0300 From: "kirill.shutemov@linux.intel.com" To: Peter Zijlstra Cc: Dave Hansen , Sean Christopherson , 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 , 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: <20230703175556.nn5xozz7dzxjocqm@box.shutemov.name> References: <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> <20230703150330.GA83892@hirez.programming.kicks-ass.net> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20230703150330.GA83892@hirez.programming.kicks-ass.net> X-Rspam-User: X-Rspamd-Server: rspam12 X-Rspamd-Queue-Id: 8341540009 X-Stat-Signature: m7paypd7cgz9gnm6udermmactx45hcc1 X-HE-Tag: 1688406968-28934 X-HE-Meta: U2FsdGVkX1/p09wwvxny9fI+0x39KHpODKUf3fCvhbs5SpjLbNMMUF0gOqaWsgPNkM6qUGhf41pX9WZN06cm6Vtm2GA3iYm0Rf7hpEZy+WT0K+/nR/d1ioDBF/+3xcFo/ZRDfhBqwh/nHaUNrVbM99TrOK4tsBRRYPG4XiiNBk4TCioZCiAhiNUboPdrtZ46pREX3tebU5nd5SsLzy3Iwx7dMyEkP/dgg1AWi3iU+q7E0VenRabeFX8hFau31kJyvm4hxnvBiSEYugERu3mRRr8hWRzAOHdZ0VLFIdXoRbGones0XHQxQM6kCkp83CbxuIQQ6BNB2JQ/8V6YUW7tVlK6PMBfOn+5dIARjOedYyPGKR/r8SnInrR32Gd0RgLmvd9h1IcJcgyd+B1KHZq108+ALTMRR6VALO0HH5E83A3Kdwmd9zLpaiYXI/VLvlI3jKKjf4L55GitEwE9OyXFRwhEPrSJq2IaXdMMPt+bLC6FyV70280BvRQnhUBspMBEpHJYpLvQTSAuDwCIvCrnoQHPBSzDUookObAGvwS4IhA3wd4ZESUxl5QF/8Dk8luTemqhIKGFqLjFGam7zMnaXyZ5utWUdGWKkeYOoOGqyzrYD2uxB2a+w5/Obuofq1bBM/FDUat0RVq5T3HivnNrr1TTrHJgfcQM4BzA3S18Rj35DnnV+Cqo3jrPWmQoIGjx5twLvnQs0SsJ4wUn6ADMLD77SUW5jf0taCIZjDH8VOYJ8xPT/vfNu92e+rr7fkbHWyPVhjHV/lPpdPqN0plvuIauK2BsjRG6UeRYzNwLEn2/bB6QfT7/z2CJ8fgMSjsrtGywdRO0GMOakgFUf/ReR/VimhAz62XZvy492HzpkHPAlaaCmo7cbBIU+wJl8Erz5X31fcuGhEGxrlscdcSXUiMD0P4YiVV7kliuNEiihUZ8G8RKq/lw3Kivzxnn2GuqZQX7p22sM3xr4V4tnLf aSxlRDu6 l9xUE6vRfRh9Xxyum/cdNtyTv6ULKt8O4iyH18xDYZyQwS3JAcCSQZBouECoZ3mXN1k7LD4CToItcEQnWdWm2jFMjrahN3L6tp1ekduQDzyGA8ypotnd2O2kURrro9xoF8V64zN59pf8iyJzKNJs+DjcbFCdw+LLHkOZ32mf01Y7zpzT1KoLTIcSr8vscs2Dd3X6flRhKSBetwdjakTP5BJm1YgZP2bl9fkbYqsq3Y+i4e6A= 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 Mon, Jul 03, 2023 at 05:03:30PM +0200, Peter Zijlstra wrote: > On Mon, Jul 03, 2023 at 07:40:55AM -0700, Dave Hansen wrote: > > 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? > > I'm thikning we want something along the lines of the Xen preemptible > hypercalls, except less crazy. Where the caller does: > > for (;;) { > ret = tdcall(fn, args); > if (ret == -EAGAIN) { > cond_resched(); > continue; > } > break; > } > > And then the TDX black box provides a guarantee that any one tdcall (or > seamcall or whatever) never takes more than X ns (possibly even > configurable) and we get to raise a bug report if we can prove it > actually takes longer. TDG.VP.VMCALL TDCALL can take arbitrary amount of time as it handles over control to the host/VMM. But I'm not quite follow how it is different from the host stopping scheduling vCPU on a random instruction. It can happen at any point and TDCALL is not special from this PoV. -- Kiryl Shutsemau / Kirill A. Shutemov