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 073C8C001B3 for ; Mon, 3 Jul 2023 18:26:51 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 64A30280026; Mon, 3 Jul 2023 14:26:50 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id 5FA6F280001; Mon, 3 Jul 2023 14:26:50 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 4C1A9280026; Mon, 3 Jul 2023 14:26:50 -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 3C54A280001 for ; Mon, 3 Jul 2023 14:26:50 -0400 (EDT) Received: from smtpin09.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay10.hostedemail.com (Postfix) with ESMTP id 01207C041F for ; Mon, 3 Jul 2023 18:26:49 +0000 (UTC) X-FDA: 80971131780.09.C10DF99 Received: from mga07.intel.com (mga07.intel.com [134.134.136.100]) by imf15.hostedemail.com (Postfix) with ESMTP id D4B14A001D for ; Mon, 3 Jul 2023 18:26:46 +0000 (UTC) Authentication-Results: imf15.hostedemail.com; dkim=pass header.d=intel.com header.s=Intel header.b=SkUZqHV+; dmarc=pass (policy=none) header.from=intel.com; spf=pass (imf15.hostedemail.com: domain of dave.hansen@intel.com designates 134.134.136.100 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=1688408808; 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=rSE5s3t98YG7Ii6yZguC8u3f0Ge33icP9TGXp7pQjDg=; b=1Morw4LfHhq4fJbV/Y09fCMetwPRdFjEOG7E0kVJPfuo9bj3zFttwwuARAm6TXeJvU8nSS 6QGf7Hk/7YuU2yXKZH0V/Zcd+rLKbYUCopoiNMYft6cytsmVzWQPHafcKcTO8kMEEbuZpN dYQuqb7Gj/L9GfmZWMvZJb6AHUzCreM= ARC-Authentication-Results: i=1; imf15.hostedemail.com; dkim=pass header.d=intel.com header.s=Intel header.b=SkUZqHV+; dmarc=pass (policy=none) header.from=intel.com; spf=pass (imf15.hostedemail.com: domain of dave.hansen@intel.com designates 134.134.136.100 as permitted sender) smtp.mailfrom=dave.hansen@intel.com ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1688408808; a=rsa-sha256; cv=none; b=YbC5PP4+OYpYcoYQHmi+JzfOXa6ues4pIQayivn1xbUgnDNPmkE0+tV5K02JdoMd/qHOHY q6Rr83gids54rgRxEFWD2bvD4LwYXeTqYJo8HxIacUKsWg8XqLOfRqUX555EtkMbr2Z3kD OTRTHeLDl9KIxKWO58eKZ8hx1nLZhUY= DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=intel.com; i=@intel.com; q=dns/txt; s=Intel; t=1688408807; x=1719944807; h=message-id:date:mime-version:subject:to:cc:references: from:in-reply-to:content-transfer-encoding; bh=loPr+dzJ18Fhw1+ezR3lKISk94Z2wAYPGf8y4ACIrKE=; b=SkUZqHV+lnV3KsETyzkomU24oLKwRcW/gHy+CC++x3uAZxZq7iKqrhXE VPoZPOhemwgzN0scPpYhdNFjEh2lsr0SfIK3cXQmh0XzVVa+gZ211FLQf iwdDjamx6zFFk1ccK/u2TyAgzOfFAJ/eOmEw7zi5u3DOI+meCEOIy61sj TzrwVby2sFYmQF2fdKhG+EOXyOJJcvoeXprbYkDHDTRcPGCbBtulMn/Ks NPF9RNJdSfF3fdnC/yx/0bnNdtTuMYou+oYzROsxjMsoyofMvqmDcZAim Ef1mUaxEGeFAUs52QICEwxD9wUneWiZo1kAjqGb8I5kyZoGNyrQK4TJaJ Q==; X-IronPort-AV: E=McAfee;i="6600,9927,10760"; a="428985374" X-IronPort-AV: E=Sophos;i="6.01,178,1684825200"; d="scan'208";a="428985374" Received: from orsmga007.jf.intel.com ([10.7.209.58]) by orsmga105.jf.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 03 Jul 2023 11:26:45 -0700 X-ExtLoop1: 1 X-IronPort-AV: E=McAfee;i="6600,9927,10760"; a="712635074" X-IronPort-AV: E=Sophos;i="6.01,178,1684825200"; d="scan'208";a="712635074" Received: from lbates-mobl.amr.corp.intel.com (HELO [10.212.242.115]) ([10.212.242.115]) by orsmga007-auth.jf.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 03 Jul 2023 11:26:44 -0700 Message-ID: Date: Mon, 3 Jul 2023 11:26:43 -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: "kirill.shutemov@linux.intel.com" , Peter Zijlstra Cc: 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" 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> <20230703175556.nn5xozz7dzxjocqm@box.shutemov.name> From: Dave Hansen In-Reply-To: <20230703175556.nn5xozz7dzxjocqm@box.shutemov.name> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit X-Rspamd-Queue-Id: D4B14A001D X-Rspam-User: X-Rspamd-Server: rspam02 X-Stat-Signature: ki6xexeqw7coetcnp57btmgopyztr8h8 X-HE-Tag: 1688408806-907603 X-HE-Meta: U2FsdGVkX1+Lb6DZceymlspluKqJr0Or2MA5QJ4z8jIlPLV81iONXGfV8p5U4epww9nSr/u3syPfyMXTS64d6/Qr+R4Yu2gd1EFGgctMe6G13mIl2J5ZYEhZ65FbHYyFdCrHgY5iOBG7G/L+4YDpo0q7VBTR1L9MWE3S7yJ39LhxbQrCNl32HLqYsnZLtqWRZpQIaGASDuKDzgbZ1WFAiNexDiDXArxLDFuvRhiwEBCkHIaZ6/DO9TNQXEGDKYPSLjK4gojQ39Ug13Ldlv2HtjapfJQfGNan2nC8v1KljJmd43CADqZkA4SFALvIEWQ8eHUFCtMaLLQxE4wzyuDBDC31d+Y5ntDRCRcP+T65yfWL5lVvN2U/We2yuYcr68lHQxLSHRoCbmjX0d3LS/K7T75n50LOCaCd8ZRdddkzRjPtJo/XUlIgKx58WpJtrbtMqfCOl2ILm7FTDxzJsYoKMPqGs6qbGs52WoH2EeNSa5MliCFuN12eK1cBN0H/kV6fI6KNJwkss1aqg56jfGQMBzMFqpS2zKL/xxTiFTFckjjvK11E+H/Cd0LzZzJhrRIFOZWCRLo6zkpX7+0SMI96XNMP1EnNb4KWW62p+xC5txnHEF6QLmoQ731Dg5sD99vFmWeOGSYUCLu4TorLzeNEb1MsQAby550nlNh1CamRnPPPM9+jiVbMui4CMn9mPGAzFfRq932Cys3uOwQUW17H+e7j8EBBkbSCZDIWjt9Qj3kWk0pKu274q11DfNudzh7zgdzdyF9vdQsKTRQ26s/SiCWHf6HeqUjVylMlcLD/fS/vnsLs3KPYZQyLRKbg/+1xW8vpHlXNMOrUNz53S3JKr2nLwmefmORpnwSswo9H0OE+lA/KqkfBL/oGaVP9PrYd4xO8GzlSAMnxEGTIedWvkCOVPVQoYolxecpl1cLG874J7JxYWuO26unhqmvf3muTA7XYDviv/U8Mf14EVpr fMcoQhmr bWD6z65VXw4bMc0hPxIeEawNH8kOGkAQvgRXk/2lsSGUbO1cdpPA3Tx4StIXX7ELDc3cbBSQDP52srL4sF9rZcoy2lQcKonPHR1x5D0CBJArkUceDzeWnRuFsCEcOUbJDyYx+zXxnVYpLi5/M6bnwNpV1JvXMTjl9W4euPRPVBEPZIX4X5uSRTaDhyg9mJfaUAwAzZi9Bjsz2JMltBifBqyPsV0txflFz/ovvV9ArRklFechm53W954RYPQyOOLNNHnjgZTqt8ruu1sNncs9qMrLT4A== 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 10:55, kirill.shutemov@linux.intel.com wrote: >> 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. Well, for one, if the host stops the vCPU on a random instruction the host has to restore all the vCPU state. *ALL* of it. That means that after the host hands control back, the guest is perfectly ready to take all the interrupts that are pending. These TDCALLs are *VERY* different. The guest gets control back and has some amount of its state zapped, RBP being the most annoying current example of state that is lost. So the guest resumes control here and must handle all of its interrupts with some of its state (and thus ability to cleanly handle the interrupt) gone. The instructions after state is lost are very much special. Just look at the syscall gap.