From nobody Fri May 17 07:55:54 2024 Delivered-To: importer@patchew.org Received-SPF: pass (zohomail.com: domain of lists.xenproject.org designates 192.237.175.120 as permitted sender) client-ip=192.237.175.120; envelope-from=xen-devel-bounces@lists.xenproject.org; helo=lists.xenproject.org; Authentication-Results: mx.zohomail.com; dkim=pass; spf=pass (zohomail.com: domain of lists.xenproject.org designates 192.237.175.120 as permitted sender) smtp.mailfrom=xen-devel-bounces@lists.xenproject.org; dmarc=pass(p=reject dis=none) header.from=citrix.com ARC-Seal: i=1; a=rsa-sha256; t=1660248007; cv=none; d=zohomail.com; s=zohoarc; b=DZUGTgj2AEc/hq4dODcwJLBQUu3bX7ECur5rM+vIO4rqmzP4tvB9bOG8OD4ON8glqkgjP6wpt+g/6g+mGBY/QHpjj0I6h/UxkOJ1eMjT8avv7X78+FRcN97LAOTyaYMcawVUBQDqx/x82LXGjzJkv4bwh3OawmgrcMku/4o4y/4= ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=zohomail.com; s=zohoarc; t=1660248007; h=Content-Type:Content-Transfer-Encoding:Cc:Date:From:In-Reply-To:List-Subscribe:List-Post:List-Id:List-Help:List-Unsubscribe:MIME-Version:Message-ID:References:Sender:Subject:To; bh=L7j7u1Belq5OB3KzKDS/T9GgEI1M27SvVLXdx7YyVfI=; b=RDfmXv0MLH3yfdMITrrDnFKPBzKRCLLxuG4m/eh8Wy0EO1REIZTI0eJOQAkJbkGxxCGaj+aRVM5edghNSr+BwhkI0rCqzWbX9vhTpNeff7rq6suUt8jAHI7OEdTCKbGHyL6h+/U67ny3gwZ0TdQa9H0TspSjaw632XZ5aFHmN0M= ARC-Authentication-Results: i=1; mx.zohomail.com; dkim=pass; spf=pass (zohomail.com: domain of lists.xenproject.org designates 192.237.175.120 as permitted sender) smtp.mailfrom=xen-devel-bounces@lists.xenproject.org; dmarc=pass header.from= (p=reject dis=none) Return-Path: Received: from lists.xenproject.org (lists.xenproject.org [192.237.175.120]) by mx.zohomail.com with SMTPS id 1660248007713863.6668841579387; Thu, 11 Aug 2022 13:00:07 -0700 (PDT) Received: from list by lists.xenproject.org with outflank-mailman.385157.620709 (Exim 4.92) (envelope-from ) id 1oMELL-0002dm-63; Thu, 11 Aug 2022 19:59:47 +0000 Received: by outflank-mailman (output) from mailman id 385157.620709; Thu, 11 Aug 2022 19:59:47 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1oMELL-0002dd-3L; Thu, 11 Aug 2022 19:59:47 +0000 Received: by outflank-mailman (input) for mailman id 385157; Thu, 11 Aug 2022 19:59:46 +0000 Received: from se1-gles-sth1-in.inumbo.com ([159.253.27.254] helo=se1-gles-sth1.inumbo.com) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1oMELK-00024H-BH for xen-devel@lists.xenproject.org; Thu, 11 Aug 2022 19:59:46 +0000 Received: from esa2.hc3370-68.iphmx.com (esa2.hc3370-68.iphmx.com [216.71.145.153]) by se1-gles-sth1.inumbo.com (Halon) with ESMTPS id 24857ae3-19b0-11ed-bd2e-47488cf2e6aa; Thu, 11 Aug 2022 21:59:45 +0200 (CEST) X-Outflank-Mailman: Message body and most headers restored to incoming version X-BeenThere: xen-devel@lists.xenproject.org List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: xen-devel-bounces@lists.xenproject.org Precedence: list Sender: "Xen-devel" X-Inumbo-ID: 24857ae3-19b0-11ed-bd2e-47488cf2e6aa DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=citrix.com; s=securemail; t=1660247985; h=from:to:cc:subject:date:message-id:in-reply-to: references:mime-version:content-transfer-encoding; bh=KqmmLAV1fvNf0oBH4lqcnCZIyCym+wndXbWemJjGv9k=; b=An7bHQGVImhToWA5kURC5Qym55fPU6wNhVV6V+MfsBa4lEsnxD2SBtPN 0jGkbUHLZP2/Z8CwPjYi8baVcY316XndDEhDv1VH5onaVgEuHNKLsjxUy X7oZ8BU119EcS8diIcc34HKYQixEoBFAuIR2KzW3kEuw7jzu7SgemyWYS Q=; Authentication-Results: esa2.hc3370-68.iphmx.com; dkim=none (message not signed) header.i=none X-SBRS: 2.7 X-MesageID: 77912369 X-Ironport-Server: esa2.hc3370-68.iphmx.com X-Remote-IP: 162.221.156.83 X-Policy: $RELAYED IronPort-Data: =?us-ascii?q?A9a23=3ANotJXqjJ3mrf7PzgkV/5MdGJX17brhtdyRrau?= =?us-ascii?q?qucSGfot9Go9fgcEakywXxxQyOjNFhxPkljTP6bFW25pS+9ulAPs3xUIucbH?= =?us-ascii?q?vvzWNVykLxy4vp2jvjRqeQtbf0FzuW0+S8j7v4RyZsu6L3zlaqkYpjA1iwa5?= =?us-ascii?q?/YFhfqyHuERCyUGMssI0eM2zLkCwG+afzIVeHItNofOuv1lYObgxFOLAecQN?= =?us-ascii?q?OV3IDbmIAdI9MO8de0CXOoTfc7drjqanKBqQaHJiFvUf6kuCXBThJaRR1OH4?= =?us-ascii?q?+RHDTnPJBiYkzttZeorOv4eA8+fU0ej4HZTzBRYhAvZgmdUj/l7SuxZcel8Y?= =?us-ascii?q?jvxK9p7tkdHBKWwRWS4nresLtvR3hhERsr1SWEdR2u8BAyMYLaKIZ7HuSCZf?= =?us-ascii?q?sekF67vnCve9Zmmt4ZU7r0QJ1LO2bCKjOZ/eWpwQRsBgyHBW5AZorQaGF6mQ?= =?us-ascii?q?jD5i3roBsdlZmFYMFEMclzmoGaGTuCXCIAoiMkzqlhdDxRElGASyvC/Prgh+?= =?us-ascii?q?52o6GKTIPEVqAuypmie1dfyn18cpYRo6mg83t8MNq/Ugmpho0NhettN9OGc4?= =?us-ascii?q?cffysQkhLrs+5OOLY55AWHF09GLCVeUFX3xVhcF6h9PrQFot2nUtYqvL1iNa?= =?us-ascii?q?T/hR3NexEyEXYXeK64XN/84jxVBya5pNAxO4RY+PKdWIZ+WnKvdziR+xlH54?= =?us-ascii?q?95P9I6yEgN6PCmIwPpe0I9EE1sxAvGCXhqvDJWXO5KxgG2CZ+5RJDWMDIFJx?= =?us-ascii?q?Ez3lMphrZiWrFHDCNgSqLhIZ/oyQCpGAUJmrC0VBK4v55yJ+GEVrT7FfCP0o?= =?us-ascii?q?7rlePhvlT7VqV3aAtimwRwmrNbnw7KITzGWbXy0P8VmDLdim73MwQ1y1tKFY?= =?us-ascii?q?Nh1qtvRmHF+c6cIfM0VKPh2KqP360/wt0WW/Tsb0EnmKQAdABXKxSv3TbxNI?= =?us-ascii?q?sQIlqqn3/wxOgsTWqeTSUCq2hk91YyAjz95fOnmBHU8x/+ZJYbVytBo+EgPn?= =?us-ascii?q?ORc3iXhVnUisyAKlHn0An7YkNNOcJiNSf52ch+DUiC20wtBB3eLMvMhb3AWk?= =?us-ascii?q?zYbqi9os1kETgFAgzr+EtTEIHT2Kcp1k3THvNKOtsH0Dm2uDDqUnRCEVKXEn?= =?us-ascii?q?Lc4DoQQPxnvNsr+JS3bKsmmlPFtV2ulslBJqWVCK9C7o1m4NY2k9jmZgpIJm?= =?us-ascii?q?kv6Xn+hicTEhaJp5WU1Dy+htHfORf7iZobAmki2o2OtbCfLB2+hcpibG0D+F?= =?us-ascii?q?WkwWrLAZOVzlRAnneUeArJMyekzLr33U35SXyCpLnOUPiBv3gqgegpA+8FjE?= =?us-ascii?q?kIo4qEOqdFJTpCljLFCJHwXqKy7TiC91i32PjSQdHavdU5XLpxMWDXAN59Mj?= =?us-ascii?q?r83S9i9/5xvfKdZMgijehydHdB2hKwbIJui4keNMBS+f6+3Z5QPZcdXAvnfH?= =?us-ascii?q?qwcD3JlqCcGtV1QcYF3viZ+99G/RnBHrGxWwavjtJqkc/P3fLo/ozw5lQ8QR?= =?us-ascii?q?jxjICUi0vdPSzJyBYgupXHo48iLENhOds/Y0hCi9Z3eDHWNUFYkaD0CZiHNo?= =?us-ascii?q?LwOy+gZMsepumErqtsqturFRwD6EVG1m5hlEuov7Y/V+GG44LX6aS9afM+g/?= =?us-ascii?q?KYQ4TIkEew97sVPRUbSRu1WPSh/Nz6aIG4sp7Wtd8gUqSZt4yTBSRklVMbjg?= =?us-ascii?q?qi5Tsc3HjR5qvWHlg+8PP/uCsRTsomtHWTyOEMF0vbSibLAbW3YkAv+UNOTm?= =?us-ascii?q?PQXZrvq+VkySGa5TOC4w1ADX/TWQ7hzB9HtX53joXY0yfiVByj8bUShJLSrf?= =?us-ascii?q?hX0Ybt53FBWiOG/6lnjtb+kTTZu/SoUf15ihoIxgRV3GVT6wD+BcO7HGSbB9?= =?us-ascii?q?0K2esh1m5E4R2wgE8e9KhCPqLwA1t05CoMrLYpOEhdwWfJTIgesV5brL55l6?= =?us-ascii?q?nDM5SxjnJPtYNwg7kKduDecd5r8rDuuDxfqW6CtJIIWCyHjhHHkdtPiD2Wxy?= =?us-ascii?q?FFX7DXsU8gZT/UQhQ346dkAAUOxdXWTPZOY3wYAN0ia5K6cibKE1vyr3Owk+?= =?us-ascii?q?/+MHOnRN8uU1hX+Thd28Na3wCy0i+v0VIBCR2byPCVFAk9U0Vk/+lzAs0Z0G?= =?us-ascii?q?GcVVMrCLiNqtAN/+xl+xNtYZFZ5V8dx4nkBnnc1sqSTx0bXDaGePZDAUto3f?= =?us-ascii?q?BjF1y88sGEk54eMroBuh/QUom1BeR7UL0BhSxgEVBk6lLytfVENLySrdoTSp?= =?us-ascii?q?EVq0OQCG9+YosecCP5UqlLK9OFWShArjFRhDCWVsgpvGw3foLFW1VsPyM7ZI?= =?us-ascii?q?LhwOGoIIKGOEFMItFlzYdv8Q+cTsUde6/L9qwwn7bw6ptxzq2VvZFKBe/eVq?= =?us-ascii?q?32VzFFOIE2eYjZ6Nfwj3T10btl99vmiEL0LnnzQNTfOPL7rXJAuOn9bfWAc3?= =?us-ascii?q?dzuJycS3frLliKii8dDxHutpt6QryiNyJvSeq9Z9qtTvQStYJSkkXElaG/8F?= =?us-ascii?q?FTJV97j5OUpD8NsXxIh828J16ery2xiiIO8N+htlYowx0g470aoPnLk2L9KJ?= =?us-ascii?q?RflXhVveL5uRMtEn6exfeYWC+LLHjB1D+uNOMJBfeQS5uXdiCGZCqO+4+bTi?= =?us-ascii?q?20V90MgbJxq+o4N6dENn0Jr2WWqlKBk2LGh5jbVvG68Hwx380MLNtaiC2yK+?= =?us-ascii?q?1/sGoQ5q7nviIfV1a3wG5jW6iXu4fPjOUW7LvaPUcn7eXLloRmqCx9JMcqil?= =?us-ascii?q?KOSlf8jhoeNV8+tkqER7dQq+VAveHwDvSYCZ8a4kIwZq+xabCw=3D?= X-IronPort-AV: E=Sophos;i="5.93,230,1654574400"; d="scan'208";a="77912369" From: Andrew Cooper To: Xen-devel CC: Andrew Cooper , Jan Beulich , =?UTF-8?q?Roger=20Pau=20Monn=C3=A9?= , Wei Liu Subject: [PATCH 1/2] x86/svm: Remove regs param from asm-called functions Date: Thu, 11 Aug 2022 20:59:04 +0100 Message-ID: <20220811195905.7780-2-andrew.cooper3@citrix.com> X-Mailer: git-send-email 2.11.0 In-Reply-To: <20220811195905.7780-1-andrew.cooper3@citrix.com> References: <20220811195905.7780-1-andrew.cooper3@citrix.com> MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable X-ZohoMail-DKIM: pass (identity @citrix.com) X-ZM-MESSAGEID: 1660248009193100003 A optimisation is going to want to conditionally have extra data on the sta= ck around VMExit. We could alternative between `mov %rsp, %rdi` and `lea 8(%rsp), %rdi`, but = it is easier just to make the functions void and let the compiler do the (not very) hard work. Passing regs is a bit weird for HVM guests anyway, because the resulting pointer is invariant (this isn't native exception handling where the regs pointers *are* important), and all functions calculate `current` themselves which is another invariant. Finally, the compiler can merge the get_cpu_info() calculation which is com= mon to both `current` and guest_cpu_user_regs(), meaning the delta in C really = is just one `lea`, and not any more expensive than `mov`'s in ASM anyway. No functional change. Signed-off-by: Andrew Cooper Reviewed-by: Jan Beulich --- CC: Jan Beulich CC: Roger Pau Monn=C3=A9 CC: Wei Liu --- xen/arch/x86/hvm/svm/entry.S | 3 --- xen/arch/x86/hvm/svm/nestedsvm.c | 3 ++- xen/arch/x86/hvm/svm/svm.c | 6 ++++-- 3 files changed, 6 insertions(+), 6 deletions(-) diff --git a/xen/arch/x86/hvm/svm/entry.S b/xen/arch/x86/hvm/svm/entry.S index a60d759f7108..be4ce52bd81d 100644 --- a/xen/arch/x86/hvm/svm/entry.S +++ b/xen/arch/x86/hvm/svm/entry.S @@ -26,7 +26,6 @@ ENTRY(svm_asm_do_resume) GET_CURRENT(bx) .Lsvm_do_resume: call svm_intr_assist - mov %rsp,%rdi call nsvm_vcpu_switch ASSERT_NOT_IN_ATOMIC =20 @@ -52,7 +51,6 @@ UNLIKELY_START(ne, nsvm_hap) jmp .Lsvm_do_resume __UNLIKELY_END(nsvm_hap) =20 - mov %rsp, %rdi call svm_vmenter_helper =20 clgi @@ -132,7 +130,6 @@ __UNLIKELY_END(nsvm_hap) */ stgi GLOBAL(svm_stgi_label) - mov %rsp,%rdi call svm_vmexit_handler jmp .Lsvm_do_resume =20 diff --git a/xen/arch/x86/hvm/svm/nestedsvm.c b/xen/arch/x86/hvm/svm/nested= svm.c index 9f5f35f16aff..77f754736023 100644 --- a/xen/arch/x86/hvm/svm/nestedsvm.c +++ b/xen/arch/x86/hvm/svm/nestedsvm.c @@ -1460,8 +1460,9 @@ nestedsvm_vcpu_vmexit(struct vcpu *v, struct cpu_user= _regs *regs, } =20 /* VCPU switch */ -void nsvm_vcpu_switch(struct cpu_user_regs *regs) +void nsvm_vcpu_switch(void) { + struct cpu_user_regs *regs =3D guest_cpu_user_regs(); struct vcpu *v =3D current; struct nestedvcpu *nv; struct nestedsvm *svm; diff --git a/xen/arch/x86/hvm/svm/svm.c b/xen/arch/x86/hvm/svm/svm.c index 0849a9dc5f41..81f0cf55676b 100644 --- a/xen/arch/x86/hvm/svm/svm.c +++ b/xen/arch/x86/hvm/svm/svm.c @@ -1040,8 +1040,9 @@ static void noreturn cf_check svm_do_resume(void) reset_stack_and_jump(svm_asm_do_resume); } =20 -void svm_vmenter_helper(const struct cpu_user_regs *regs) +void svm_vmenter_helper(void) { + const struct cpu_user_regs *regs =3D guest_cpu_user_regs(); struct vcpu *curr =3D current; struct vmcb_struct *vmcb =3D curr->arch.hvm.svm.vmcb; =20 @@ -2570,8 +2571,9 @@ static struct hvm_function_table __initdata_cf_clobbe= r svm_function_table =3D { }, }; =20 -void svm_vmexit_handler(struct cpu_user_regs *regs) +void svm_vmexit_handler(void) { + struct cpu_user_regs *regs =3D guest_cpu_user_regs(); uint64_t exit_reason; struct vcpu *v =3D current; struct vmcb_struct *vmcb =3D v->arch.hvm.svm.vmcb; --=20 2.11.0 From nobody Fri May 17 07:55:54 2024 Delivered-To: importer@patchew.org Received-SPF: pass (zohomail.com: domain of lists.xenproject.org designates 192.237.175.120 as permitted sender) client-ip=192.237.175.120; envelope-from=xen-devel-bounces@lists.xenproject.org; helo=lists.xenproject.org; Authentication-Results: mx.zohomail.com; dkim=pass; spf=pass (zohomail.com: domain of lists.xenproject.org designates 192.237.175.120 as permitted sender) smtp.mailfrom=xen-devel-bounces@lists.xenproject.org; dmarc=pass(p=reject dis=none) header.from=citrix.com ARC-Seal: i=1; a=rsa-sha256; t=1660248009; cv=none; d=zohomail.com; s=zohoarc; b=IVjZhc77EiWyXzc/6sMYALD4dGGdSqg7eo1bPdDaKK/Qcta3OJkCo+K0+e6qwAgwOSvrEJV0riCEM7uuKf7/34hfjDKNIPg6LG762CpOAD7hs/Sp7sRTwNM611p26kuqT1Ooy3gRNotiOjVbQOUgJ+gdXLCJgg5NnQtL1YdEal0= ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=zohomail.com; s=zohoarc; t=1660248009; h=Content-Type:Content-Transfer-Encoding:Cc:Date:From:In-Reply-To:List-Subscribe:List-Post:List-Id:List-Help:List-Unsubscribe:MIME-Version:Message-ID:References:Sender:Subject:To; bh=BgEPr8iS6ksamvFcEKPdtsN+SPzGmgsV/4f5S14lIA0=; b=TWQd23jZU95Y0oCO/7QkQyLXxxZQVsRGuBD12SN3djV3RVmMegDn0NV/WGenQlKKhWHebEgptBCAo9h5nEsG31qosj1KrO2VqFKuj/YzKwydZk3mckwSDJg5CarvINFvJNCDDwyMUt1+YtL/p1gGjUN3GfkdbuNHRAzEpb+gMlA= ARC-Authentication-Results: i=1; mx.zohomail.com; dkim=pass; spf=pass (zohomail.com: domain of lists.xenproject.org designates 192.237.175.120 as permitted sender) smtp.mailfrom=xen-devel-bounces@lists.xenproject.org; dmarc=pass header.from= (p=reject dis=none) Return-Path: Received: from lists.xenproject.org (lists.xenproject.org [192.237.175.120]) by mx.zohomail.com with SMTPS id 1660248009285399.7659781709348; Thu, 11 Aug 2022 13:00:09 -0700 (PDT) Received: from list by lists.xenproject.org with outflank-mailman.385156.620697 (Exim 4.92) (envelope-from ) id 1oMELE-0002Jw-U6; Thu, 11 Aug 2022 19:59:40 +0000 Received: by outflank-mailman (output) from mailman id 385156.620697; Thu, 11 Aug 2022 19:59:40 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1oMELE-0002Jp-RR; Thu, 11 Aug 2022 19:59:40 +0000 Received: by outflank-mailman (input) for mailman id 385156; Thu, 11 Aug 2022 19:59:39 +0000 Received: from se1-gles-sth1-in.inumbo.com ([159.253.27.254] helo=se1-gles-sth1.inumbo.com) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1oMELD-00024H-HD for xen-devel@lists.xenproject.org; Thu, 11 Aug 2022 19:59:39 +0000 Received: from esa6.hc3370-68.iphmx.com (esa6.hc3370-68.iphmx.com [216.71.155.175]) by se1-gles-sth1.inumbo.com (Halon) with ESMTPS id 203b5a88-19b0-11ed-bd2e-47488cf2e6aa; Thu, 11 Aug 2022 21:59:38 +0200 (CEST) X-Outflank-Mailman: Message body and most headers restored to incoming version X-BeenThere: xen-devel@lists.xenproject.org List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: xen-devel-bounces@lists.xenproject.org Precedence: list Sender: "Xen-devel" X-Inumbo-ID: 203b5a88-19b0-11ed-bd2e-47488cf2e6aa DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=citrix.com; s=securemail; t=1660247978; h=from:to:cc:subject:date:message-id:in-reply-to: references:mime-version:content-transfer-encoding; bh=S+Ld7c+dRiGE87K3GbtMdBGXMnjEkY04FCI3h90/+zM=; b=SM/YKZRhlcoBzU4/cBY6ghhU6qBIeliDFmF1Y9CLc8bd+vMXEc4mk+FJ KOBhQsDymh5FgxStXwcveqtJmhS4FJRvrqycjQmh9Qc8zMh9rBCMINstU BF0nBPD+OA4XE7K9PsX6qsnDQ9oJ/4oQeU9aXqPbi2YvuWo5VB4W5KMJX w=; Authentication-Results: esa6.hc3370-68.iphmx.com; dkim=none (message not signed) header.i=none X-SBRS: 2.7 X-MesageID: 77664067 X-Ironport-Server: esa6.hc3370-68.iphmx.com X-Remote-IP: 162.221.156.83 X-Policy: $RELAYED IronPort-Data: A9a23:9eRJ26qyzFAvQcwhfiU2OyeLqi9eBmJ2ZRIvgKrLsJaIsI4StFCzt garIBnUMv+Pa2WmfYx1YIzipE8Cv5CHydNlTVds+yhjF35Ap5uZCYyVIHmrMnLJJKUvbq7GA +byyDXkBJppJpMJjk71atANlVEliefSAOKU5NfsYkhZXRVjRDoqlSVtkus4hp8AqdWiCkaGt MiaT/f3YTdJ4BYpdDNPg06/gEk35q6q6GpB5gZWic1j5zcyqVFEVPrzGonpR5fIatE8NvK3Q e/F0Ia48gvxl/v6Ior4+lpTWhRiro/6ZWBiuFIPM0SRqkEqShgJ+rQ6LJIhhXJ/0F1lqTzTJ OJl7vRcQS9xVkHFdX90vxNwS0mSNoUekFPLzOTWXWV+ACQqflO1q8iCAn3aMqUi+P5wIkB21 sADE20SST2RqL6Zx7+CH7wEasQLdKEHPasas3BkizrYEewnUdbIRKCiCd1whWlqwJoURLCHO pRfOWEHgBfoOnWjPn8+Dp4kkfjurX74azBC83qepLYt4niVxwt0uFToGIWKJILWHZsK9qqej kDn0liiKUoKDfyexwah4nicn8nWgQquDer+E5Xnr6U30TV/3Fc7Fxk+RVa95/6jhSaWefhSN kgV8SoGtrUp+QqgSdyVdw21pjuIswARX/JUEvYm80edx6zM+QGbC2MYCDlbZ7QbWNQeHGJwk AXTxpWwWGIp4Ob9pW+hGqm8lzGqPgs0FUw+fhRZUiwo8fa/j4Y+t0eaJjp8K5JZnuEZCBmpn W7S9Hlh3uxN5SIY//7lpA6a2lpAsrCMF1dovVuPAwpJ+ysjPOaYi5qUBU83BBqqBKKQVRG/s XcNgKByB8heXMjWxERhrAjgdYxFBspp0xWG2DaD57F7q1yQF4eLJOi8Gg1WKkZzKdojcjT0e kLVsg45zMYNYiPzMPEqM9juW51CIU3c+TPNCJjpgidmOMAtJGdrAgk3DaJv44wduBd1yvxuU XtqWc2tEWwbGcxa8dZCfM9EiOdD7n1vmgvuqWXTlUvPPUy2OCHIEt/o8TKmMogE0U9ziF+Fr o8AbZvVkEg3vS+XSnC/zLP/5GsidRATba0aYeQNHgJfCmKKwF0cNsI= IronPort-HdrOrdr: A9a23:rBmlYKigC92mcrvkZ9POMzXn2HBQXuIji2hC6mlwRA09TySZ// rBoB19726MtN9xYgBHpTnuAsm9qB/nmaKdpLNhWItKPzOW31dATrsSjrcKqgeIc0aVm9K1l5 0QF5SWYOeAdWSS5vya3ODXKbkdKaG8gcKVuds= X-IronPort-AV: E=Sophos;i="5.93,230,1654574400"; d="scan'208";a="77664067" From: Andrew Cooper To: Xen-devel CC: Andrew Cooper , Jan Beulich , =?UTF-8?q?Roger=20Pau=20Monn=C3=A9?= , Wei Liu Subject: [PATCH 2/2] x86/svm: Keep the RAS balanced for guests Date: Thu, 11 Aug 2022 20:59:05 +0100 Message-ID: <20220811195905.7780-3-andrew.cooper3@citrix.com> X-Mailer: git-send-email 2.11.0 In-Reply-To: <20220811195905.7780-1-andrew.cooper3@citrix.com> References: <20220811195905.7780-1-andrew.cooper3@citrix.com> MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable X-ZohoMail-DKIM: pass (identity @citrix.com) X-ZM-MESSAGEID: 1660248010967100005 One source of lost performance was that fact that to protect Xen from a malicious guests, we had to flush the RAS. It turns out that CET Shadow Stacks give us enough architectural guarantees= to construct a lower overhead mitigation, which keeps the RAS balanced for the guest so their return performance is still good. To keep the RAS balanced, Xen must execute the same number of CALLs as RETs across one VMexit->VMEntry. Without CET-SS, we could achieve this fairly easily with a `call; add $8, %rsp` and `push; ret` pair, but this is not le= gal under CET-SS. In fact, CALL is the only shadow stack "push" operation we have, and we can't use it a second time if we intend to keep the RAS balanc= ed. Instead, we keep a real return address on the stack. This means that for s= ome of entry.S, %rsp conditionally doesn't reference CPUINFO. This necessitates swapping the current order of DO_OVERWRITE_RSB and svm_vmexit_spec_ctrl; while they don't have any specific ordering requirements, push_one_ras needs to come after svm_vmexit_spec_ctrl or else= we need some very invasive changes to fix up the %rsp changes. Signed-off-by: Andrew Cooper --- CC: Jan Beulich CC: Roger Pau Monn=C3=A9 CC: Wei Liu RFC for a couple of reasons. This does function correctly, but I still want to do more perf testing. Secondly, X86_FEATURE_ALWAYS is clearly not ok for committing. I'm still debating whether to make this construct available in !CET-SS cases. Mechanically, its fine, but the safety arguments depend on CET-SS being active. In principle, on CPUs which do not suffer Branch Type Confusion, you might = be able to reason a defence-in-depth argument that if an attacker can't control indirect speculation, then they can't bypass the 1-stuff safety either, but the only AMD CPUs not vulnerable to BTC have CET-SS anyway. Third, I'd like some early feedback on how clear it the logic is given the conditional nature of %rsp not referencing CPUINFO. Fourth, the alternatives logic (I think) needs improving to not fix up a direct CALL/JMP displacement if the destination is within the replacement length. I did the functional testing before wrapping things in alternative= s. --- xen/arch/x86/hvm/svm/entry.S | 55 ++++++++++++++++++++++++++++++++++++++++= ++-- 1 file changed, 53 insertions(+), 2 deletions(-) diff --git a/xen/arch/x86/hvm/svm/entry.S b/xen/arch/x86/hvm/svm/entry.S index be4ce52bd81d..98934db41fec 100644 --- a/xen/arch/x86/hvm/svm/entry.S +++ b/xen/arch/x86/hvm/svm/entry.S @@ -22,8 +22,41 @@ #include #include =20 +.macro push_one_ras + /* + * Pushes one entry into the RAS, then updates the return address(= es) + * to point at svm_ras_speculation_trap. + * + * Rogue RAS-speculation will hit the INT3 and stop. Architectural + * execution will go to svm_ras_speculation_trap. + * + * This deliberately leaves the (modified) return address on the + * stack(s). + */ + call 1f + int3 +1: + lea svm_ras_speculation_trap(%rip), %rax + +#ifdef CONFIG_XEN_SHSTK + rdsspq %rcx + wrssq %rax, (%rcx) +#endif + mov %rax, (%rsp) +.endm + ENTRY(svm_asm_do_resume) GET_CURRENT(bx) + + /* + * We've just been schedule()'d. There's no speculation safety ne= eded + * here, but we do need to set the stack up in the manner expected= by + * later logic. + */ + ALTERNATIVE "", push_one_ras, X86_FEATURE_ALWAYS + + /* WARNING! After this point, %rsp /may/ not reference cpu_info. = */ + .Lsvm_do_resume: call svm_intr_assist call nsvm_vcpu_switch @@ -56,6 +89,20 @@ __UNLIKELY_END(nsvm_hap) clgi =20 /* WARNING! `ret`, `call *`, `jmp *` not safe beyond this point. */ + /* WARNING! Before this point, %rsp /may/ not reference cpu_info.= */ + + /* + * If we're trying to balance the RAS for guests, push_one_ras in = the + * VMExit path was necessary for speculative safety, but the on-st= ack + * return address was deliberately updated to point here. + * + * We execute one RET to re-balance the RAS. It will mispredict (= to + * the INT3 in push_one_ras in the general case), but won't + * architecturally change the instruction flow. + */ + ALTERNATIVE "", ret, X86_FEATURE_ALWAYS +svm_ras_speculation_trap: + /* SPEC_CTRL_EXIT_TO_SVM Req: b=3Dcurr %rsp=3Dregs/cpuinfo, = Clob: acd */ .macro svm_vmentry_spec_ctrl mov VCPU_arch_msrs(%rbx), %rax @@ -108,8 +155,6 @@ __UNLIKELY_END(nsvm_hap) .endm ALTERNATIVE "", svm_vmexit_cond_ibpb, X86_FEATURE_IBPB_ENTRY_HVM =20 - ALTERNATIVE "", DO_OVERWRITE_RSB, X86_FEATURE_SC_RSB_HVM - .macro svm_vmexit_spec_ctrl movzbl CPUINFO_xen_spec_ctrl(%rsp), %eax movzbl CPUINFO_last_spec_ctrl(%rsp), %edx @@ -122,6 +167,12 @@ __UNLIKELY_END(nsvm_hap) 1: .endm ALTERNATIVE "", svm_vmexit_spec_ctrl, X86_FEATURE_SC_MSR_HVM + + ALTERNATIVE_2 "", \ + DO_OVERWRITE_RSB, X86_FEATURE_SC_RSB_HVM, \ + push_one_ras, X86_FEATURE_ALWAYS + + /* WARNING! After this point, %rsp /may/ not reference cpu_info. = */ /* WARNING! `ret`, `call *`, `jmp *` not safe before this point. */ =20 /* --=20 2.11.0