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 vger.kernel.org (vger.kernel.org [23.128.96.18]) by smtp.lore.kernel.org (Postfix) with ESMTP id CE218C30654 for ; Mon, 3 Jul 2023 18:26:49 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S230389AbjGCS0s (ORCPT ); Mon, 3 Jul 2023 14:26:48 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:46808 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S229830AbjGCS0q (ORCPT ); Mon, 3 Jul 2023 14:26:46 -0400 Received: from mga07.intel.com (mga07.intel.com [134.134.136.100]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 04947D7; Mon, 3 Jul 2023 11:26:45 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=intel.com; i=@intel.com; q=dns/txt; s=Intel; t=1688408806; x=1719944806; h=message-id:date:mime-version:subject:to:cc:references: from:in-reply-to:content-transfer-encoding; bh=loPr+dzJ18Fhw1+ezR3lKISk94Z2wAYPGf8y4ACIrKE=; b=kWtc2nsl+9L+/nOEZXpTFwYRvliVyo3wZ46DdDLeLmwlVNvZbZBwFIpt +dr3BbEDZYiH4VUfhMCuou6XCCqQL1si5//5u9M/4gbu65ijc6QMtPp7d OCSpRvZNbnZrtB0oBDMDOk2io65OFHeR38TcbdC/+e4IuQsgk17H8V+wH 7Gq7/AXflJHC/q0n1aZDCu2TLo709g1yXRNFKo8TSsFWn0TLQ/4/zInRD JbZCyyfgLQn8QAKhQfXc6ad3ERN37FdeEjEIXtVb1AUco9DrPRv3kQWGY pEkRHfAy6/ILF81TuK9D9azvplAWM186+LBNbEdyfPu7G5GrLlT5ed85B g==; X-IronPort-AV: E=McAfee;i="6600,9927,10760"; a="428985376" X-IronPort-AV: E=Sophos;i="6.01,178,1684825200"; d="scan'208";a="428985376" 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 Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org 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.