From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mgamail.intel.com (mgamail.intel.com [192.198.163.9]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id 39C325B696 for ; Fri, 17 May 2024 14:19:55 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=192.198.163.9 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1715955596; cv=none; b=Szqsd+xlZDCcMzPHuAhs/3JR4gEI228/v+Uk8mEYIVhgVi1uI/O7UIpxGKHUzkItnrdKvAaJ6AW3NPOYiBZa4/4/juxKholT6sewY+dEFlYh0XfBQCD32kPE9NTNf+Thvk5csJBrlk/CE6P9CMiDMBykTF7fNwsTVCTC+fkhD0E= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1715955596; c=relaxed/simple; bh=qdA+03KUUXrXT1TuR3oQCBn2z6vx7qFJuNLOGkZcBqs=; h=From:To:Cc:Subject:Date:Message-ID:MIME-Version; b=Xqnt2yGBSe7gXjZyecgxESM0j/VqzEf4nf0LnTD+oIObt1zBGWdaqC16NJEMUsphl+A0sLem7Q+xQea5qR8v9AAmCht+5UyZq7fP5XFsdwALbws7T/3sn9NAmVF9sqYja7ZWxae/3OGVkVYsS88Op56NUAh0CA63dHzPUoSeGVE= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=linux.intel.com; spf=none smtp.helo=mgamail.intel.com; dkim=pass (2048-bit key) header.d=intel.com header.i=@intel.com header.b=FtCvrHL3; arc=none smtp.client-ip=192.198.163.9 Authentication-Results: smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=linux.intel.com Authentication-Results: smtp.subspace.kernel.org; spf=none smtp.helo=mgamail.intel.com Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=intel.com header.i=@intel.com header.b="FtCvrHL3" DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=intel.com; i=@intel.com; q=dns/txt; s=Intel; t=1715955595; x=1747491595; h=from:to:cc:subject:date:message-id:mime-version: content-transfer-encoding; bh=qdA+03KUUXrXT1TuR3oQCBn2z6vx7qFJuNLOGkZcBqs=; b=FtCvrHL3GQYmxWI0MPCBgfkDxoS3O6ceuAD8wOJdkgG6AlIoKr5/itOf NL0FTpe8H0uw4ovB+5SFd4sYAhfIEW0iGJp4QJAaZLH4t+6/hsNb7pcR/ Pcr7/hcsvn4hnOujDE4Di0rPoV3FWkOuEcXuSWFx9XVJfTgeITJaMU6Tl iI5DZFWOg/3c1neOihhYzTETxa4wiwHSSpVU1G5254D+yxgu28hj+DPzi 3731sz4WfEkZDCfbOglwOTAh4S3Sb/I1PgndZ8C25E+PVD9a8UyjR+TeC uUz61FPjiKiD5KEBTZu0DAi8TxhTPmnp8gfE1+W55xvFA3QxraeDOPiT7 g==; X-CSE-ConnectionGUID: J/5Waw93RiOHcvW7HgVS0A== X-CSE-MsgGUID: ZgX8luRLTJmXM5C1pC+yyA== X-IronPort-AV: E=McAfee;i="6600,9927,11075"; a="22808549" X-IronPort-AV: E=Sophos;i="6.08,167,1712646000"; d="scan'208";a="22808549" Received: from orviesa009.jf.intel.com ([10.64.159.149]) by fmvoesa103.fm.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 17 May 2024 07:19:55 -0700 X-CSE-ConnectionGUID: pUPJyHyVRUGTE9+FDhsMig== X-CSE-MsgGUID: mfRJ+xSfS/+hypUxdYOegA== X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="6.08,167,1712646000"; d="scan'208";a="31944605" Received: from black.fi.intel.com ([10.237.72.28]) by orviesa009.jf.intel.com with ESMTP; 17 May 2024 07:19:51 -0700 Received: by black.fi.intel.com (Postfix, from userid 1000) id 83A2319E; Fri, 17 May 2024 17:19:49 +0300 (EEST) From: "Kirill A. Shutemov" To: Sean Christopherson , Paolo Bonzini , Dave Hansen , Thomas Gleixner , Ingo Molnar , Borislav Petkov , x86@kernel.org, "H. Peter Anvin" , "K. Y. Srinivasan" , Haiyang Zhang , Wei Liu , Dexuan Cui , Josh Poimboeuf , Peter Zijlstra Cc: linux-coco@lists.linux.dev, linux-kernel@vger.kernel.org, linux-hyperv@vger.kernel.org, "Kirill A. Shutemov" Subject: [PATCH 00/20] x86/tdx: Rewrite TDCALL wrappers Date: Fri, 17 May 2024 17:19:18 +0300 Message-ID: <20240517141938.4177174-1-kirill.shutemov@linux.intel.com> X-Mailer: git-send-email 2.43.0 Precedence: bulk X-Mailing-List: linux-coco@lists.linux.dev List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 Content-Transfer-Encoding: 8bit Sean noticing that the TDCALL wrappers were generating a lot of awful code. TDCALL calls are centralized into a few megawrappers that take the struct tdx_module_args as input. Most of the call sites only use a few arguments, but they have to zero out unused fields in the structure to avoid data leaks to the VMM. This leads to the compiler generating inefficient code: dozens of instructions per call site to clear unused fields of the structure. This issue can be avoided by using more targeted wrappers. After the rewrite code size is cut by ~3K: add/remove: 7/15 grow/shrink: 1/17 up/down: 212/-3502 (-3290) Please take a look. I would appreciate any feedback. Kirill A. Shutemov (20): x86/tdx: Introduce tdvmcall_trampoline() x86/tdx: Add macros to generate TDVMCALL wrappers x86/tdx: Convert port I/O handling to use new TDVMCALL macros x86/tdx: Convert HLT handling to use new TDVMCALL_0() x86/tdx: Convert MSR read handling to use new TDVMCALL_1() x86/tdx: Convert MSR write handling to use new TDVMCALL_0() x86/tdx: Convert CPUID handling to use new TDVMCALL_4() x86/tdx: Convert MMIO handling to use new TDVMCALL macros x86/tdx: Convert MAP_GPA hypercall to use new TDVMCALL macros x86/tdx: Convert GET_QUOTE hypercall to use new TDVMCALL macros x86/tdx: Rewrite tdx_panic() without __tdx_hypercall() x86/tdx: Rewrite tdx_kvm_hypercall() without __tdx_hypercall() x86/tdx: Rewrite hv_tdx_hypercall() without __tdx_hypercall() x86/tdx: Add macros to generate TDCALL wrappers x86/tdx: Convert PAGE_ACCEPT tdcall to use new TDCALL_0() macro x86/tdx: Convert VP_INFO tdcall to use new TDCALL_5() macro x86/tdx: Convert VM_RD/VM_WR tdcalls to use new TDCALL macros x86/tdx: Convert VP_VEINFO_GET tdcall to use new TDCALL_5() macro x86/tdx: Convert MR_REPORT tdcall to use new TDCALL_0() macro x86/tdx: Remove old TDCALL wrappers arch/x86/boot/compressed/tdx.c | 32 +--- arch/x86/coco/tdx/tdcall.S | 145 ++++++++++----- arch/x86/coco/tdx/tdx-shared.c | 26 +-- arch/x86/coco/tdx/tdx.c | 298 ++++++++---------------------- arch/x86/hyperv/ivm.c | 33 +--- arch/x86/include/asm/shared/tdx.h | 159 +++++++++++----- arch/x86/include/asm/tdx.h | 2 + arch/x86/virt/vmx/tdx/tdxcall.S | 29 +-- tools/objtool/noreturns.h | 2 +- 9 files changed, 322 insertions(+), 404 deletions(-) -- 2.43.0