From nobody Sun May 5 04:59:16 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=1656528374; cv=none; d=zohomail.com; s=zohoarc; b=cHZNLOi7YEn/ACUi8+FyzxA7QXnr+4tfShc+F8A54kFceVp05v7Hurrgir5xI/mlwnalWU8NX/nUJFECXvALXwta2q35qaWvr8KnSkPIt2TX5y2EqgfXNnZ7N9Y0sGxhoEXwexQ1gLSInwRQRheaR0O20P56LWjIsE03Jv/24uE= ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=zohomail.com; s=zohoarc; t=1656528374; 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=yczESqIUn02eoYBg7htb2sNUbkfHEqoFdGTZvcI7nOI=; b=DnOX06VYm3pmvw7eF9t03N9+DpWSFcavceTJ0KO5C4n3UhsjHgyV5RvOaQwFxD3QiaBkBVdSPzk+XTtxHmoHM1eB/SAyFHSEYwCkKx6/AlzM6ypAvTJS7HB8E4JsH8plQtR2OPAUhdTYRr/cuoTBV+QGx4MbDsS7XL0JRUCr3HM= 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 1656528374185331.7268798745471; Wed, 29 Jun 2022 11:46:14 -0700 (PDT) Received: from list by lists.xenproject.org with outflank-mailman.358036.587000 (Exim 4.92) (envelope-from ) id 1o6ch8-00013v-Mg; Wed, 29 Jun 2022 18:45:46 +0000 Received: by outflank-mailman (output) from mailman id 358036.587000; Wed, 29 Jun 2022 18:45:46 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1o6ch8-00013o-Jp; Wed, 29 Jun 2022 18:45:46 +0000 Received: by outflank-mailman (input) for mailman id 358036; Wed, 29 Jun 2022 18:45:45 +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 1o6ch6-0000mL-SD for xen-devel@lists.xenproject.org; Wed, 29 Jun 2022 18:45:44 +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 ad1bcc4c-f7db-11ec-bd2d-47488cf2e6aa; Wed, 29 Jun 2022 20:45:43 +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: ad1bcc4c-f7db-11ec-bd2d-47488cf2e6aa DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=citrix.com; s=securemail; t=1656528343; h=from:to:cc:subject:date:message-id:in-reply-to: references:mime-version:content-transfer-encoding; bh=hZZKKx5wLOQQOp1PoQBnMdpXG5SbkLDIEV13BnQaatU=; b=HrlqaoZDyhdg+N6BC1sIu9MvlyMQlxWnGtIOFLnHKaJ9PMJoFrWmT2UO HB+9Bv6z5MnxyksKgs6wso77UgX0eRr4imFqxgVrDLK/svAXVV1JJ2WOl Yefhj201e/C3Oj5dYH5VOrEP1GhnFVN0sA9KEdB/6GZKdHXv8fET6WkGt 4=; Authentication-Results: esa2.hc3370-68.iphmx.com; dkim=none (message not signed) header.i=none X-SBRS: 5.1 X-MesageID: 74746992 X-Ironport-Server: esa2.hc3370-68.iphmx.com X-Remote-IP: 162.221.156.83 X-Policy: $RELAYED IronPort-Data: A9a23:3VTefatbpT3L9DzYjk7fsfh2UOfnVAleMUV32f8akzHdYApBsoF/q tZmKWDTbPaMNjT8Kd5wYd/gpE8B6MPXm4VmGwBr+3o0FC5A+JbJXdiXEBz9bniYRiHhoOOLz Cm8hv3odp1coqr0/0/1WlTZhSAgk/nOHNIQMcacUsxLbVYMpBwJ1FQywYbVvqYy2YLjW13X6 IuryyHiEATNNwBcYzp8B52r8HuDjNyq0N/PlgVjDRzjlAa2e0g9VPrzF4noR5fLatA88tqBb /TC1NmEElbxpH/BPD8HfoHTKSXmSpaKVeSHZ+E/t6KK2nCurQRquko32WZ1he66RFxlkvgoo Oihu6BcRi8TbqORu6MbUiB6Chp+ZqB5943jDkGG5Jn7I03uKxMAwt1rBUAye4YZ5vx2ESdF8 vlwxDIlN07ZwbjsmfTiF7cq1p9LwMrDZevzvllJyz3DAOlgapfEW6jQvvdT3Ssqh9AIFvHbD yYcQWUzM0ieMkwVUrsRIKwSxuGvnnr9TzdB9HGv/6A7wlD50DUkhdABN/KKI4fXFK25hH2wu Wbu72n/RBYAO7S36xCI73atje/nhj7gVcQZE7jQ3u5nhhify3IeDDUSVECnur+ph0imQdVdJ kcIvC00osAPGFeDF4enGUfi+Tjd40BaC4E4//AGBB+l8PraviXeAGk9bCd6aIcri8AEYRMT7 wrc9z/2PgCDoIF5WFrEqOrK8GrjZXRMRYMRTXRaFFVYurEPtKl210uSFYg7TcZZm/WvQVnNL ya2QD/Sbln5peoCzO2F8F/OmFpATbCZH1dutm07so9Ihz6VhbJJhKTysDA3Fd4acO6koqCp5 RDoYfS24uEUFo2qnyeQWugLF7zBz6/bbWOA3Qc2QcJxqmjFF5ufkWZ4uWAWyKBBYq45lcLBO heP6Wu9GrcJVJdVUUOHS93oUJl7pUQRPd/kSurVfrJzX3SFTyfepHsGTRfJhwjFyRFw+Ylia MzzWZv9Uh4n5VFPkWPeqxE1iud7mEjTBAr7GPjG8vhQ+eHENCLEGetdbQDmgyJQxPrsnTg5O u13b6OioyizmsWnCsUL2eb/9Ww3EEU= IronPort-HdrOrdr: A9a23:S0kXN6GqN+pPxrBSpLqE5MeALOsnbusQ8zAXP0AYc3Jom6uj5q eTdZUgpHvJYVkqOE3I9ertBEDiewK4yXcW2/hzAV7KZmCP0wHEEGgL1/qF/9SKIUzDH4Bmup uIC5IOauHNMQ== X-IronPort-AV: E=Sophos;i="5.92,231,1650945600"; d="scan'208";a="74746992" From: Andrew Cooper To: Xen-devel CC: Andrew Cooper , Jan Beulich , =?UTF-8?q?Roger=20Pau=20Monn=C3=A9?= , Wei Liu Subject: [PATCH v2 1/2] x86/spec-ctrl: Only adjust MSR_SPEC_CTRL for idle with legacy IBRS Date: Wed, 29 Jun 2022 19:45:07 +0100 Message-ID: <20220629184508.15956-2-andrew.cooper3@citrix.com> X-Mailer: git-send-email 2.11.0 In-Reply-To: <20220629184508.15956-1-andrew.cooper3@citrix.com> References: <20220629184508.15956-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: 1656528375126100001 Back at the time of the original Spectre-v2 fixes, it was recommended to cl= ear MSR_SPEC_CTRL when going idle. This is because of the side effects on the sibling thread caused by the microcode IBRS and STIBP implementations which were retrofitted to existing CPUs. However, there are no relevant cross-thread impacts for the hardware IBRS/STIBP implementations, so this logic should not be used on Intel CPUs supporting eIBRS, or any AMD CPUs; doing so only adds unnecessary latency to the idle path. Furthermore, there's no point playing with MSR_SPEC_CTRL in the idle paths = if SMT is disabled for other reasons. Fixes: 8d03080d2a33 ("x86/spec-ctrl: Cease using thunk=3Dlfence on AMD") Signed-off-by: Andrew Cooper Reviewed-by: Roger Pau Monn=C3=A9 --- CC: Jan Beulich CC: Roger Pau Monn=C3=A9 CC: Wei Liu v2: * New --- xen/arch/x86/include/asm/cpufeatures.h | 2 +- xen/arch/x86/include/asm/spec_ctrl.h | 5 +++-- xen/arch/x86/spec_ctrl.c | 10 ++++++++-- 3 files changed, 12 insertions(+), 5 deletions(-) diff --git a/xen/arch/x86/include/asm/cpufeatures.h b/xen/arch/x86/include/= asm/cpufeatures.h index bd45a144ee78..493d338a085e 100644 --- a/xen/arch/x86/include/asm/cpufeatures.h +++ b/xen/arch/x86/include/asm/cpufeatures.h @@ -33,7 +33,7 @@ XEN_CPUFEATURE(SC_MSR_HVM, X86_SYNTH(17)) /* MSR_S= PEC_CTRL used by Xen fo XEN_CPUFEATURE(SC_RSB_PV, X86_SYNTH(18)) /* RSB overwrite needed f= or PV */ XEN_CPUFEATURE(SC_RSB_HVM, X86_SYNTH(19)) /* RSB overwrite needed f= or HVM */ XEN_CPUFEATURE(XEN_SELFSNOOP, X86_SYNTH(20)) /* SELFSNOOP gets used by= Xen itself */ -XEN_CPUFEATURE(SC_MSR_IDLE, X86_SYNTH(21)) /* (SC_MSR_PV || SC_MSR_H= VM) && default_xen_spec_ctrl */ +XEN_CPUFEATURE(SC_MSR_IDLE, X86_SYNTH(21)) /* Clear MSR_SPEC_CTRL on= idle */ XEN_CPUFEATURE(XEN_LBR, X86_SYNTH(22)) /* Xen uses MSR_DEBUGCTL.= LBR */ /* Bits 23,24 unused. */ XEN_CPUFEATURE(SC_VERW_IDLE, X86_SYNTH(25)) /* VERW used by Xen for i= dle */ diff --git a/xen/arch/x86/include/asm/spec_ctrl.h b/xen/arch/x86/include/as= m/spec_ctrl.h index 751355f471f4..7e83e0179fb9 100644 --- a/xen/arch/x86/include/asm/spec_ctrl.h +++ b/xen/arch/x86/include/asm/spec_ctrl.h @@ -78,7 +78,8 @@ static always_inline void spec_ctrl_enter_idle(struct cpu= _info *info) uint32_t val =3D 0; =20 /* - * Branch Target Injection: + * It is recommended in some cases to clear MSR_SPEC_CTRL when going i= dle, + * to avoid impacting sibling threads. * * Latch the new shadow value, then enable shadowing, then update the = MSR. * There are no SMP issues here; only local processor ordering concern= s. @@ -114,7 +115,7 @@ static always_inline void spec_ctrl_exit_idle(struct cp= u_info *info) uint32_t val =3D info->xen_spec_ctrl; =20 /* - * Branch Target Injection: + * Restore MSR_SPEC_CTRL on exit from idle. * * Disable shadowing before updating the MSR. There are no SMP issues * here; only local processor ordering concerns. diff --git a/xen/arch/x86/spec_ctrl.c b/xen/arch/x86/spec_ctrl.c index 1f275ad1fb5d..57f4fcb21398 100644 --- a/xen/arch/x86/spec_ctrl.c +++ b/xen/arch/x86/spec_ctrl.c @@ -1151,8 +1151,14 @@ void __init init_speculation_mitigations(void) /* (Re)init BSP state now that default_spec_ctrl_flags has been calcul= ated. */ init_shadow_spec_ctrl_state(); =20 - /* If Xen is using any MSR_SPEC_CTRL settings, adjust the idle path. */ - if ( default_xen_spec_ctrl ) + /* + * For microcoded IBRS only (i.e. Intel, pre eIBRS), it is recommended= to + * clear MSR_SPEC_CTRL before going idle, to avoid impacting sibling + * threads. Activate this if SMT is enabled, and Xen is using a non-z= ero + * MSR_SPEC_CTRL setting. + */ + if ( boot_cpu_has(X86_FEATURE_IBRSB) && !(caps & ARCH_CAPS_IBRS_ALL) && + hw_smt_enabled && default_xen_spec_ctrl ) setup_force_cpu_cap(X86_FEATURE_SC_MSR_IDLE); =20 xpti_init_default(caps); --=20 2.11.0 From nobody Sun May 5 04:59:16 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=1656528375; cv=none; d=zohomail.com; s=zohoarc; b=Xzz67VQqUvFkwhYvYiqJvU5fAOXT650GZcn8JDRUIJyas1qVNsKX63HuEhE8TuyTMCiI2reWqTOedKWC7kCP7YR1csVS8XW4vOCyChKiJQVbb4tXp09wNyNHSlZXC18TW/NdonbH8jNgVZicTbzl10gBBKEDuzdUladho8wwCaA= ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=zohomail.com; s=zohoarc; t=1656528375; 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=Usdl2saEgygBO1lrE71CyDJKciBusEA5auQN1oYeQpg=; b=QjgVveizqm3b3pa8+fmKTMGp1LncXJ6Q8YDVeNGh0ObGm/Txd6KBrctAwGyiV1jkaVJ3nmZmVhxiVvdPmH7SEFG4xDdljw1AX33P/pMqsKxIfepYL/S0GqzFrZwTGrMpM+F0ryQ9A1ykaUKPFzJZjKhI35P4uxG7eGPyhnZzMTs= 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 1656528375068340.4499758219738; Wed, 29 Jun 2022 11:46:15 -0700 (PDT) Received: from list by lists.xenproject.org with outflank-mailman.358037.587011 (Exim 4.92) (envelope-from ) id 1o6ch9-0001Jx-Vk; Wed, 29 Jun 2022 18:45:47 +0000 Received: by outflank-mailman (output) from mailman id 358037.587011; Wed, 29 Jun 2022 18:45: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 1o6ch9-0001Jq-S4; Wed, 29 Jun 2022 18:45:47 +0000 Received: by outflank-mailman (input) for mailman id 358037; Wed, 29 Jun 2022 18:45: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 1o6ch8-0000mL-DY for xen-devel@lists.xenproject.org; Wed, 29 Jun 2022 18:45: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 aef34e82-f7db-11ec-bd2d-47488cf2e6aa; Wed, 29 Jun 2022 20:45: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: aef34e82-f7db-11ec-bd2d-47488cf2e6aa DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=citrix.com; s=securemail; t=1656528344; h=from:to:cc:subject:date:message-id:in-reply-to: references:mime-version:content-transfer-encoding; bh=qX8FoVKbQduGMZIO5wy6Y3hMntj7bH2XpUmWXTKnZfE=; b=Xl5F6iBj9dzNNlqAo6mdyWaT5evlDbIxLRVpzaw+u/5K0k5q0WInr4Ye RcCZVyDKhjnPdliG7nRvVIhlGfbHOnG6X/3Lm3goSVp6z2wh145cIXK9A QcHRnvfSR6dc1WX1lgGoddOpMQqcYv+8HDA9EwxorbDkKBrx/guRNbFKB E=; Authentication-Results: esa2.hc3370-68.iphmx.com; dkim=none (message not signed) header.i=none X-SBRS: 5.1 X-MesageID: 74746993 X-Ironport-Server: esa2.hc3370-68.iphmx.com X-Remote-IP: 162.221.156.83 X-Policy: $RELAYED IronPort-Data: A9a23:LnFTLKhXFEXqwBCtgDC0rNzsX161PxAKZh0ujC45NGQN5FlHY01je htvUTrQPKmDamf9fNx2YI+y90sEsZ7RzoJgTwJtpC03FCMb9cadCdqndUqhZCn6wu8v7a5EA 2fyTvGacajYm1eF/k/F3oDJ9CU6jefSLlbFILas1hpZHGeIcw98z0M58wIFqtQw24LhXVnc4 YqaT/D3YzdJ5RYlagr41IrbwP9flKyaVOQw5wFWiVhj5TcyplFNZH4tDfjZw0jQG+G4KtWSV efbpIxVy0uCl/sb5nFJpZ6gGqECaua60QFjERO6UYD66vRJjnRaPqrWqJPwwKqY4tmEt4kZ9 TlDiXC/YT15MPDv3+IcajtBKCElMJJJypvoGEHq5KR/z2WeG5ft6/BnDUVwNowE4OdnR2pJ8 JT0KhhUMErF3bjvhuvmFK883azPL+GyVG8bklhmwSvUErANRpfbTr+RzdRZwC0xloZFGvO2i 88xNmYwMEqRMkYn1lE/CMIlo8GYpkHDLQZBqljK9PoI42Hc5VkkuFTqGIWMIYHbLSlPpW6Ho krW8mK/BQsVXPS94zeY9nOnhsfUgDj2HokVEdWQ5vNsxVGe2GEXIBkXTkeg5+m0jFakXNBSI FBS/TAhxZXe72TyEIO7BUfh5ifZ4FhMALK8DtHW9im3mqSJwEGfB1EmVwVBM9EZu/0SagUTg wrhc8zSOdB/jFGEYSvDq+nJ9GLuZXF9wXwqPnFdE1ZcizX3iMRq10+UEI4+eEKgpoetcQwc1 Qxmu8TXa187qccQn5u28lnc695HjsiYF1Vljuk7s4/M0++YWGJGT9bxgbQjxawcRLt1t3HY1 JT+p+CQ7foVEbaGnzGXTeMGEdmBvqjYbmGA2AcxRMl8q1xBHkJPm6gJsVmSw285WvvohBezO BOD0e+vzMU70ISWgV9fPNvqVpVCIVnIHtX5TPHEBudzjmxKXFbfpklGPBfIt0i0yRREufxuY v+zLJfzZUv2/Iw6lVJasc9Gie91rs3/rEuOLa3GI+OPiuDOOC/FFe9YazNjrIkRtcu5nekcy P4HX+Pi9vmVeLSWjvX/mWLLEW03EA== IronPort-HdrOrdr: A9a23:fA9MuajhUOLgsfO5aHKh7Ri6RHBQXtYji2hC6mlwRA09TySZ// rBoB19726StN9xYgBFpTnuAsm9qB/nmaKdgrNhWItKPjOW21dARbsKheCJrgEIcxeOkNK1vp 0AT0ERMrLN5CBB/KTH3DU= X-IronPort-AV: E=Sophos;i="5.92,231,1650945600"; d="scan'208";a="74746993" From: Andrew Cooper To: Xen-devel CC: Andrew Cooper , Jan Beulich , =?UTF-8?q?Roger=20Pau=20Monn=C3=A9?= , Wei Liu Subject: [PATCH v2 2/2] x86/spec-ctrl: Knobs for STIBP and PSFD, and follow hardware STIBP hint Date: Wed, 29 Jun 2022 19:45:08 +0100 Message-ID: <20220629184508.15956-3-andrew.cooper3@citrix.com> X-Mailer: git-send-email 2.11.0 In-Reply-To: <20220629184508.15956-1-andrew.cooper3@citrix.com> References: <20220629184508.15956-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: 1656528377016100003 STIBP and PSFD are slightly weird bits, because they're both implied by oth= er bits in MSR_SPEC_CTRL. Add fine grain controls for them, and take the implications into account when setting IBRS/SSBD. Rearrange the IBPB text/variables/logic to keep all the MSR_SPEC_CTRL bits together, for consistency. However, AMD have a hardware hint CPUID bit recommending that STIBP be set unilaterally. This is advertised on Zen3, so follow the recommendation. Furthermore, in such cases, set STIBP behind the guest's back for now. This has negligible overhead for the guest, but saves a WRMSR on vmentry. This = is the only default change. Signed-off-by: Andrew Cooper Reviewed-by: Jan Beulich Reviewed-by: Roger Pau Monn=C3=A9 --- CC: Jan Beulich CC: Roger Pau Monn=C3=A9 CC: Wei Liu v2: * Tweak comments/logic per suggestion. * Also set STIBP behind the guest's back to improve the vmentry path. --- docs/misc/xen-command-line.pandoc | 21 ++++++++++--- xen/arch/x86/hvm/svm/vmcb.c | 9 ++++++ xen/arch/x86/spec_ctrl.c | 65 +++++++++++++++++++++++++++++++++--= ---- 3 files changed, 81 insertions(+), 14 deletions(-) diff --git a/docs/misc/xen-command-line.pandoc b/docs/misc/xen-command-line= .pandoc index a92b7d228cae..da18172e50c5 100644 --- a/docs/misc/xen-command-line.pandoc +++ b/docs/misc/xen-command-line.pandoc @@ -2258,8 +2258,9 @@ By default SSBD will be mitigated at runtime (i.e `ss= bd=3Druntime`). =20 ### spec-ctrl (x86) > `=3D List of [ , xen=3D, {pv,hvm,msr-sc,rsb,md-clear}=3D, -> bti-thunk=3Dretpoline|lfence|jmp, {ibrs,ibpb,ssbd,eager-fpu, -> l1d-flush,branch-harden,srb-lock,unpriv-mmio}=3D ]` +> bti-thunk=3Dretpoline|lfence|jmp, {ibrs,ibpb,ssbd,psfd, +> eager-fpu,l1d-flush,branch-harden,srb-lock, +> unpriv-mmio}=3D ]` =20 Controls for speculative execution sidechannel mitigations. By default, X= en will pick the most appropriate mitigations based on compiled in support, @@ -2309,9 +2310,10 @@ On hardware supporting IBRS (Indirect Branch Restric= ted Speculation), the If Xen is not using IBRS itself, functionality is still set up so IBRS can= be virtualised for guests. =20 -On hardware supporting IBPB (Indirect Branch Prediction Barrier), the `ibp= b=3D` -option can be used to force (the default) or prevent Xen from issuing bran= ch -prediction barriers on vcpu context switches. +On hardware supporting STIBP (Single Thread Indirect Branch Predictors), t= he +`stibp=3D` option can be used to force or prevent Xen using the feature it= self. +By default, Xen will use STIBP when IBRS is in use (IBRS implies STIBP), a= nd +when hardware hints recommend using it as a blanket setting. =20 On hardware supporting SSBD (Speculative Store Bypass Disable), the `ssbd= =3D` option can be used to force or prevent Xen using the feature itself. On A= MD @@ -2319,6 +2321,15 @@ hardware, this is a global option applied at boot, a= nd not virtualised for guest use. On Intel hardware, the feature is virtualised for guests, independently of Xen's choice of setting. =20 +On hardware supporting PSFD (Predictive Store Forwarding Disable), the `ps= fd=3D` +option can be used to force or prevent Xen using the feature itself. By +default, Xen will not use PSFD. PSFD is implied by SSBD, and SSBD is off = by +default. + +On hardware supporting IBPB (Indirect Branch Prediction Barrier), the `ibp= b=3D` +option can be used to force (the default) or prevent Xen from issuing bran= ch +prediction barriers on vcpu context switches. + On all hardware, the `eager-fpu=3D` option can be used to force or prevent= Xen from using fully eager FPU context switches. This is currently implemente= d as a global control. By default, Xen will choose to use fully eager context diff --git a/xen/arch/x86/hvm/svm/vmcb.c b/xen/arch/x86/hvm/svm/vmcb.c index 958309657799..0fc57dfd71cf 100644 --- a/xen/arch/x86/hvm/svm/vmcb.c +++ b/xen/arch/x86/hvm/svm/vmcb.c @@ -29,6 +29,7 @@ #include #include #include +#include =20 struct vmcb_struct *alloc_vmcb(void) { @@ -176,6 +177,14 @@ static int construct_vmcb(struct vcpu *v) vmcb->_pause_filter_thresh =3D SVM_PAUSETHRESH_INIT; } =20 + /* + * When default_xen_spec_ctrl simply SPEC_CTRL_STIBP, default this beh= ind + * the back of the VM too. Our SMT topology isn't accurate, the overh= ead + * is neglegable, and doing this saves a WRMSR on the vmentry path. + */ + if ( default_xen_spec_ctrl =3D=3D SPEC_CTRL_STIBP ) + v->arch.msrs->spec_ctrl.raw =3D SPEC_CTRL_STIBP; + return 0; } =20 diff --git a/xen/arch/x86/spec_ctrl.c b/xen/arch/x86/spec_ctrl.c index 57f4fcb21398..efed24933d91 100644 --- a/xen/arch/x86/spec_ctrl.c +++ b/xen/arch/x86/spec_ctrl.c @@ -48,9 +48,13 @@ static enum ind_thunk { THUNK_LFENCE, THUNK_JMP, } opt_thunk __initdata =3D THUNK_DEFAULT; + static int8_t __initdata opt_ibrs =3D -1; +int8_t __initdata opt_stibp =3D -1; +bool __read_mostly opt_ssbd; +int8_t __initdata opt_psfd =3D -1; + bool __read_mostly opt_ibpb =3D true; -bool __read_mostly opt_ssbd =3D false; int8_t __read_mostly opt_eager_fpu =3D -1; int8_t __read_mostly opt_l1d_flush =3D -1; static bool __initdata opt_branch_harden =3D true; @@ -172,12 +176,20 @@ static int __init cf_check parse_spec_ctrl(const char= *s) else rc =3D -EINVAL; } + + /* Bits in MSR_SPEC_CTRL. */ else if ( (val =3D parse_boolean("ibrs", s, ss)) >=3D 0 ) opt_ibrs =3D val; - else if ( (val =3D parse_boolean("ibpb", s, ss)) >=3D 0 ) - opt_ibpb =3D val; + else if ( (val =3D parse_boolean("stibp", s, ss)) >=3D 0 ) + opt_stibp =3D val; else if ( (val =3D parse_boolean("ssbd", s, ss)) >=3D 0 ) opt_ssbd =3D val; + else if ( (val =3D parse_boolean("psfd", s, ss)) >=3D 0 ) + opt_psfd =3D val; + + /* Misc settings. */ + else if ( (val =3D parse_boolean("ibpb", s, ss)) >=3D 0 ) + opt_ibpb =3D val; else if ( (val =3D parse_boolean("eager-fpu", s, ss)) >=3D 0 ) opt_eager_fpu =3D val; else if ( (val =3D parse_boolean("l1d-flush", s, ss)) >=3D 0 ) @@ -376,7 +388,7 @@ static void __init print_details(enum ind_thunk thunk, = uint64_t caps) "\n"); =20 /* Settings for Xen's protection, irrespective of guests. */ - printk(" Xen settings: BTI-Thunk %s, SPEC_CTRL: %s%s%s%s, Other:%s%s%= s%s%s\n", + printk(" Xen settings: BTI-Thunk %s, SPEC_CTRL: %s%s%s%s%s, Other:%s%= s%s%s%s\n", thunk =3D=3D THUNK_NONE ? "N/A" : thunk =3D=3D THUNK_RETPOLINE ? "RETPOLINE" : thunk =3D=3D THUNK_LFENCE ? "LFENCE" : @@ -390,6 +402,9 @@ static void __init print_details(enum ind_thunk thunk, = uint64_t caps) (!boot_cpu_has(X86_FEATURE_SSBD) && !boot_cpu_has(X86_FEATURE_AMD_SSBD)) ? "" : (default_xen_spec_ctrl & SPEC_CTRL_SSBD) ? " SSBD+" : " SSBD-", + (!boot_cpu_has(X86_FEATURE_PSFD) && + !boot_cpu_has(X86_FEATURE_INTEL_PSFD)) ? "" : + (default_xen_spec_ctrl & SPEC_CTRL_PSFD) ? " PSFD+" : " PSFD-", !(caps & ARCH_CAPS_TSX_CTRL) ? "" : (opt_tsx & 1) ? " TSX+" : " TSX-", !cpu_has_srbds_ctrl ? "" : @@ -980,10 +995,7 @@ void __init init_speculation_mitigations(void) if ( !has_spec_ctrl ) printk(XENLOG_WARNING "?!? CET active, but no MSR_SPEC_CTRL?\n= "); else if ( opt_ibrs =3D=3D -1 ) - { opt_ibrs =3D ibrs =3D true; - default_xen_spec_ctrl |=3D SPEC_CTRL_IBRS | SPEC_CTRL_STIBP; - } =20 if ( opt_thunk =3D=3D THUNK_DEFAULT || opt_thunk =3D=3D THUNK_RETP= OLINE ) thunk =3D THUNK_JMP; @@ -1087,14 +1099,49 @@ void __init init_speculation_mitigations(void) setup_force_cpu_cap(X86_FEATURE_SC_MSR_HVM); } =20 - /* If we have IBRS available, see whether we should use it. */ + /* Figure out default_xen_spec_ctrl. */ if ( has_spec_ctrl && ibrs ) + { + /* IBRS implies STIBP. */ + if ( opt_stibp =3D=3D -1 ) + opt_stibp =3D 1; + default_xen_spec_ctrl |=3D SPEC_CTRL_IBRS; + } + + /* + * Use STIBP by default if the hardware hint is set. Otherwise, leave= it + * off as it a severe performance pentalty on pre-eIBRS Intel hardware + * where it was retrofitted in microcode. + */ + if ( opt_stibp =3D=3D -1 ) + opt_stibp =3D !!boot_cpu_has(X86_FEATURE_STIBP_ALWAYS); + + if ( opt_stibp && (boot_cpu_has(X86_FEATURE_STIBP) || + boot_cpu_has(X86_FEATURE_AMD_STIBP)) ) + default_xen_spec_ctrl |=3D SPEC_CTRL_STIBP; =20 - /* If we have SSBD available, see whether we should use it. */ if ( opt_ssbd && (boot_cpu_has(X86_FEATURE_SSBD) || boot_cpu_has(X86_FEATURE_AMD_SSBD)) ) + { + /* SSBD implies PSFD */ + if ( opt_psfd =3D=3D -1 ) + opt_psfd =3D 1; + default_xen_spec_ctrl |=3D SPEC_CTRL_SSBD; + } + + /* + * Don't use PSFD by default. AMD designed the predictor to + * auto-clear on privilege change. PSFD is implied by SSBD, which is + * off by default. + */ + if ( opt_psfd =3D=3D -1 ) + opt_psfd =3D 0; + + if ( opt_psfd && (boot_cpu_has(X86_FEATURE_PSFD) || + boot_cpu_has(X86_FEATURE_INTEL_PSFD)) ) + default_xen_spec_ctrl |=3D SPEC_CTRL_PSFD; =20 /* * PV guests can create RSB entries for any linear address they contro= l, --=20 2.11.0