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 CE032EB64D9 for ; Thu, 29 Jun 2023 11:16:16 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 4D2918D0002; Thu, 29 Jun 2023 07:16:16 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id 4827A8D0001; Thu, 29 Jun 2023 07:16:16 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 34A1F8D0002; Thu, 29 Jun 2023 07:16:16 -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 259128D0001 for ; Thu, 29 Jun 2023 07:16:16 -0400 (EDT) Received: from smtpin10.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay09.hostedemail.com (Postfix) with ESMTP id CF6E080EAF for ; Thu, 29 Jun 2023 11:16:15 +0000 (UTC) X-FDA: 80955531510.10.64E16C7 Received: from mga03.intel.com (mga03.intel.com [134.134.136.65]) by imf03.hostedemail.com (Postfix) with ESMTP id 0CCC020024 for ; Thu, 29 Jun 2023 11:16:12 +0000 (UTC) Authentication-Results: imf03.hostedemail.com; dkim=pass header.d=intel.com header.s=Intel header.b=dCisbwDp; dmarc=pass (policy=none) header.from=intel.com; spf=none (imf03.hostedemail.com: domain of kirill.shutemov@linux.intel.com has no SPF policy when checking 134.134.136.65) smtp.mailfrom=kirill.shutemov@linux.intel.com ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1688037373; a=rsa-sha256; cv=none; b=5AU4MZss/EkMq1DGKr+mXH8eHgAefRip9Q9WoR1vGxFIvSYmy5bEUBD07Oz3ZGrOYmEat4 h02vmjy7lqbeEHQRVwWoJYuuWn/24SzAHH/HAiqvKpwAwljv5RnlYFwZZopWUk2+8DZ2Hd Kwy2bV//l+IFjoChy3JN3X2LPaGngww= ARC-Authentication-Results: i=1; imf03.hostedemail.com; dkim=pass header.d=intel.com header.s=Intel header.b=dCisbwDp; dmarc=pass (policy=none) header.from=intel.com; spf=none (imf03.hostedemail.com: domain of kirill.shutemov@linux.intel.com has no SPF policy when checking 134.134.136.65) 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=1688037373; 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=YvsizgO1mseHRYiIsDCgnTZgLMHD1ZuMvpA+mADb7bw=; b=4mS8k0EfmO3Rl1zd+ScHObAyDYj7hEZJthUl6uCoKHOY/BGTknpoa+v1rw0a9IWH8RhCpM XUHEWfTdqGhXGwobtzH5BhzhCxAEAQEjwuTDPNAgHx/XwhNp1Xj4YbkhU+ofe6FS2hJerq FUrQRn5vNE1SDSF4Kf+nFibkjz+BkN0= DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=intel.com; i=@intel.com; q=dns/txt; s=Intel; t=1688037373; x=1719573373; h=date:from:to:cc:subject:message-id:references: mime-version:in-reply-to; bh=AmSC6QSDI6fA0PB2pX5j89MVglE58ZfjBAk4Tqqgf7c=; b=dCisbwDpghYZJ1hMoz9/HOtnhPUYGQgReayBIyUMlyfHR3C88Xp/JJY+ Kjm3b6kV9gN/WrsnWeyyF6MUhm+T95yfJT+p3Df4njxYANW4iCRUd2ttm YFyqD1moIRYGYVDH+Chf9RKoNynI1ng8CefhDUpq7YXFQWFE4JJdpj/nS 0LDmvelZtAH+gSbFFX3bOXwYJMHtml9R4QKtdcSZbU+iY3z3s8vkYsAD+ kszYku8gYDpIufAEJZ72y3DiPF1kqKwN7yI2sY7VEMzPxI8ODZHoxU87P KCUIFbI0Tb0QD0BBxF8maVVqe61jwkDdX75J4Phkr93K9nur779i+5fso g==; X-IronPort-AV: E=McAfee;i="6600,9927,10755"; a="365545205" X-IronPort-AV: E=Sophos;i="6.01,168,1684825200"; d="scan'208";a="365545205" Received: from fmsmga004.fm.intel.com ([10.253.24.48]) by orsmga103.jf.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 29 Jun 2023 04:16:10 -0700 X-ExtLoop1: 1 X-IronPort-AV: E=McAfee;i="6600,9927,10755"; a="787334581" X-IronPort-AV: E=Sophos;i="6.01,168,1684825200"; d="scan'208";a="787334581" Received: from aperepel-mobl.ger.corp.intel.com (HELO box.shutemov.name) ([10.249.47.231]) by fmsmga004-auth.fm.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 29 Jun 2023 04:16:03 -0700 Received: by box.shutemov.name (Postfix, from userid 1000) id 9AC471095DD; Thu, 29 Jun 2023 14:16:00 +0300 (+03) Date: Thu, 29 Jun 2023 14:16:00 +0300 From: kirill.shutemov@linux.intel.com To: Peter Zijlstra Cc: Kai Huang , linux-kernel@vger.kernel.org, kvm@vger.kernel.org, linux-mm@kvack.org, x86@kernel.org, dave.hansen@intel.com, tony.luck@intel.com, tglx@linutronix.de, bp@alien8.de, mingo@redhat.com, hpa@zytor.com, seanjc@google.com, pbonzini@redhat.com, david@redhat.com, dan.j.williams@intel.com, rafael.j.wysocki@intel.com, ashok.raj@intel.com, reinette.chatre@intel.com, len.brown@intel.com, ak@linux.intel.com, isaku.yamahata@intel.com, ying.huang@intel.com, chao.gao@intel.com, sathyanarayanan.kuppuswamy@linux.intel.com, nik.borisov@suse.com, bagasdotme@gmail.com, sagis@google.com, imammedo@redhat.com Subject: Re: [PATCH v12 20/22] x86/virt/tdx: Allow SEAMCALL to handle #UD and #GP Message-ID: <20230629111600.hq4carptan6pfu37@box.shutemov.name> References: <20230628152900.GI2438817@hirez.programming.kicks-ass.net> <20230628203823.GR38236@hirez.programming.kicks-ass.net> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20230628203823.GR38236@hirez.programming.kicks-ass.net> X-Rspam-User: X-Rspamd-Server: rspam06 X-Rspamd-Queue-Id: 0CCC020024 X-Stat-Signature: nwjgjibqbxrzwhmncwimuisuy3fddqiq X-HE-Tag: 1688037372-997993 X-HE-Meta: U2FsdGVkX1/61l7BGKaSFuD+pGU8kEZepzsBZydef6n+3KAkTdtkCy5sKphvx0QawZWF5pho3kTkqM9XhMMU6kSvhamb9oJBIb2VV/CZTe/BQ++JB3xMz/zsyzjzKLJpTjNO3gk52i7eQZRxrgxPSuPfbhMuZUBZYPXTziwddnWebV+WZWyB8MPXDfSeB7eCfhgUXElskx5tl0vOrKJuI4hYlYeLqsYdzxffRSh8T3rCOwCkrgch3k6rkvxQS98GMzb5zw9PKapRxwlN0tLf5T/Re43zBmfMIIckGfFNiTy3TUlvVyZz5zFnNESkbeBjIW9l7HaQnFiq4vDfKxE5yHZ+DnxuRCGx7w1vszSP0581CgRfRJRX8fMPi0ZjBB0kwVYyi6F6Q76rJUENeFOWWgT9Xy0cVOuJ4Xxc5xxofOtnHiXsKIrAX7kXfBl5YOfm28Dku1HvAdFaQlVlrqOjX//lWA0674d92lnjLzquPwlksWzZGAq+zUDHsu9JTqa8nln5eoOJn1222sTDCWLIFuWSXXrx3ZhgWdutW/z6nPZ8t/2tf9AzdU8bGl2pik7S+kMspNHZsymh/wlrodYTvEp4qHhncjYL5EmPZjgDqG4UVPjdGdueK5q2TnEsztR1wTX+9ZLmvVBP6JmOVS/rDjH37RfrJj/HkwuHek9Hdb/tQBciMomWIY1CwC9xhVEftSUy9oyHcoCdXz6vspA136b2HBXwmtiBSrO5kP4hW1DqLoXC+qrFFuozh3mGeHxCNIVVzG5lvSWLkpTH83hCoFTAQde2zXlMs1Smq3G6m7w+QvH/3CQNqf8QiLeYWunR8U+VxHmfS/TOxjk+87P4RnUj71nwjqRVTs+M3OJ7xsN27DBkhjmfk/4fLJ0MB4OI1sU4pKaWFRaC2OJ1aoszTjzZbUq23zFzMS1fvi+eIj6dxQvdbcDgPUyFubk6HZ13Qx6aNDPNDTWU2gUDV6Z pynxnA1c LS/oNQWkDxQNt3UHH1MAkIpdTwMlCOKLI4EZs7mGFbiOUJuIIkTaNngCwI5+MlWzUiEzMqqHJwClkZqdSzXswaNBRvprQtT1YxHgMmAGIBDesE8I= X-Bogosity: Ham, tests=bogofilter, spamicity=0.003456, version=1.2.4 Sender: owner-linux-mm@kvack.org Precedence: bulk X-Loop: owner-majordomo@kvack.org List-ID: On Wed, Jun 28, 2023 at 10:38:23PM +0200, Peter Zijlstra wrote: > On Wed, Jun 28, 2023 at 05:29:01PM +0200, Peter Zijlstra wrote: > > On Tue, Jun 27, 2023 at 02:12:50AM +1200, Kai Huang wrote: > > > diff --git a/arch/x86/virt/vmx/tdx/tdxcall.S b/arch/x86/virt/vmx/tdx/tdxcall.S > > > index 49a54356ae99..757b0c34be10 100644 > > > --- a/arch/x86/virt/vmx/tdx/tdxcall.S > > > +++ b/arch/x86/virt/vmx/tdx/tdxcall.S > > > @@ -1,6 +1,7 @@ > > > /* SPDX-License-Identifier: GPL-2.0 */ > > > #include > > > #include > > > +#include > > > > > > /* > > > * TDCALL and SEAMCALL are supported in Binutils >= 2.36. > > > @@ -45,6 +46,7 @@ > > > /* Leave input param 2 in RDX */ > > > > > > .if \host > > > +1: > > > seamcall > > > > So what registers are actually clobbered by SEAMCALL ? There's a > > distinct lack of it in SDM Vol.2 instruction list :-( > > With the exception of the abomination that is TDH.VP.ENTER all SEAMCALLs > seem to be limited to the set presented here (c,d,8,9,10,11) and all > other registers should be available. > > Can we please make that a hard requirement, SEAMCALL must not use > registers outside this? We can hardly program to random future > extentions; we need hard ABI guarantees here. > > That also means we should be able to use si,di for the cmovc below. > > Kirill, back when we did __tdx_hypercall() we got bp removed as a valid > register, the 1.0 spec still lists that, and it is also listed in > TDH.VP.ENTER, I'm assuming it will be removed there too? > > bp must not be used -- it violates the pre-existing calling convention. I've just brought it up again internally. Let's see what will happen. -- Kiryl Shutsemau / Kirill A. Shutemov