From nobody Sat Apr 20 00:42:36 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=1642091958; cv=none; d=zohomail.com; s=zohoarc; b=IzQgU0S7hYIBfX5EKdhmCfbmZOi5sXEpm5wS7noaH0BToQap/xEy2ZsuwfSSQasAxxTbYkeYKNhRbqAeSFSFo2C0Ol2UXP/HyRIsv/8nU3f223fxMjLLp6YsCLIHy9ngkvpxxKkwcoMXJqbs0Zg8nxNtp8Xh6vojVNVUWvKr5XE= ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=zohomail.com; s=zohoarc; t=1642091958; 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=F5olkELz/Z06tN9ZTYNdQP222Y2XSVI3lmLuBRx96QY=; b=d5djvTjxv43VbCbXW09SLXg/QItRwotrleZjDZfPLEvq8mysrtn+1gZKKuCbxAtSS4l7CMFH3O1b0WjkO5SvJCVHGNAapkUfO1VprgCmqEBz34JqRqslroEH394kaZ7tUDGsZfiC+LEwJN6N3k4DslHYwT7RgOB6tb++HDsWL5c= 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 1642091958756893.2070630338575; Thu, 13 Jan 2022 08:39:18 -0800 (PST) Received: from list by lists.xenproject.org with outflank-mailman.257288.442096 (Exim 4.92) (envelope-from ) id 1n837m-0001pw-8R; Thu, 13 Jan 2022 16:38:54 +0000 Received: by outflank-mailman (output) from mailman id 257288.442096; Thu, 13 Jan 2022 16:38:54 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1n837m-0001mp-3E; Thu, 13 Jan 2022 16:38:54 +0000 Received: by outflank-mailman (input) for mailman id 257288; Thu, 13 Jan 2022 16:38:52 +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 1n837k-0001gG-Gi for xen-devel@lists.xenproject.org; Thu, 13 Jan 2022 16:38:52 +0000 Received: from esa1.hc3370-68.iphmx.com (esa1.hc3370-68.iphmx.com [216.71.145.142]) by se1-gles-sth1.inumbo.com (Halon) with ESMTPS id 4883d5b0-748f-11ec-bcf3-e9554a921baa; Thu, 13 Jan 2022 17:38:50 +0100 (CET) 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: 4883d5b0-748f-11ec-bcf3-e9554a921baa DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=citrix.com; s=securemail; t=1642091930; h=from:to:cc:subject:date:message-id:in-reply-to: references:mime-version:content-transfer-encoding; bh=sxj8Ni05lVGFYuLB7GuSzaAjISrCd3y2GU6H36Yb4z4=; b=QES6lAfQV0foPPUPFsOfHAVFkCfC3tR+ZOo8KH4nwnyFhhf74XLVMgET 6yc8nR2pBEqCLaVKyQPLB0V52EJHfXWhrw6PxHu0a2NLYz5CCN93U0i/7 J2baAx4Ahi0EI/pgoC8N9d0qM8QCAL2gM52G0DY9PXVRjDVDp+Q653dGW E=; Authentication-Results: esa1.hc3370-68.iphmx.com; dkim=none (message not signed) header.i=none IronPort-SDR: mpWKD6XAyW/dzNRWG4EIp2Bhp6P2gCPuy+yOy1khUf49HY5RqavOU8Esw5McwD1dSF8zOAg/aF EU+iv83gegNPl7GuesOKlqqNH2pOoxZvyXcO6hExHvDx78iDUHOWZqad886CDJJ4aQMphd2zul 7BodWjqHNo3pYCg4Zp/dHryyowO1TtSShPYiu81abL5fbPCGtLjHAcVCLr8lIMd++kS+DQzxKs Qk4LNkdT5KlXMpodJVUeTRRYYP+UmjJqJptQ2pciaZS8LxVWLVpecdVZzymHEFJntNqpmLo32M wEZkq4M23/ZHi+jxhJVG5auV X-SBRS: 5.2 X-MesageID: 62341821 X-Ironport-Server: esa1.hc3370-68.iphmx.com X-Remote-IP: 162.221.156.83 X-Policy: $RELAYED IronPort-Data: A9a23:RNm+3a7eqdtIP00KwcYx+QxRtOzAchMFZxGqfqrLsTDasY5as4F+v mNLUD/TP/iIamH2LdFzbIu2/RlU6seBm9VnSVFlpSAyHi5G8cbLO4+Ufxz6V8+wwmwvb67FA +E2MISowBUcFyeEzvuV3zyIQUBUjclkfJKlYAL/En03FV8MpBsJ00o5wbZg29Uw27BVPivW0 T/Mi5yHULOa82Yc3lI8s8pvfzs24ZweEBtB1rAPTagjUG32zhH5P7pGTU2FFFPqQ5E8IwKPb 72rIIdVXI/u10xF5tuNyt4Xe6CRK1LYFVDmZnF+A8BOjvXez8CbP2lS2Pc0MC9qZzu1c99Zy uVzuZ2vEl8QM5L93+8vURJGKQJaMvgTkFPHCSDXXc27ykTHdz3nwul0DVFwNoodkgp1KTgQr 7pCcmlLN03dwbLtqF64YrAEasALBc/nJo4A/FpnyinUF60OSpHfWaTao9Rf2V/cg+gQR62CP ppDMFKDajzrPzxJamYUNakUs9+jiSbRQwR3+G+a8P9fD2/7k1UqjemF3MDuUsOObdVYmACfv G2u10bTDwweNdef4SGY6X/qjejK9QvrVYRXGLCm+/pChFyI2ndVGBAQTUG8o/Sylgi5Qd03F qAP0nNw9+5orhXtF4SjGU3jyJKZgvICc9hgLeE791rV86fr0kGSNGoPUARiTNNz4afaWgcW/ lOOmtroAxlmv7uUVW+R+9+okN+iBcQGBTRcPHFZFGPp9/Gm+dhu1UyXEr6PBYbo1oWdJN3m/ 9ydQMHSbZ03hNVD6ai09Euvb9mE9smQFV5dCuk6swuYAuJFiGyNO93ABbvzt68owGOlor+p5 ihsdy+2trFmMH11vHbRKNjh5Znwjxp/DBXSgER0A74q/Cm39niocOh4uW8ifh8waZ5aJW+yO ic/XD+9ArcJbBNGioctMuqM5zkCl/C8RbwJqNiJBjaxXnSBXFDep3w/DaJh92vsjFItgckC1 WSzKq6R4YIhIf0/llKeHr5FuZdyn3xW7T6NGfjTkkr2uZLDNC/9YepUazOmM7FmhJ5oVS2Iq b6zwePQlUUGOAA/CwGKmbMuwacidilkVcuo+p0OJoZu4GNOQQkcNhMY+pt5E6QNokifvr2gE qiVVhAKxVzhq2fALAnWOHlvZKm2BcR0rG4hPDxqNlGtgiBxbYGq5aYZVp02Ybh4q7Azka8qF 6EIK5eaH/BCajXb4DBBP5Pzm5NvKUawjgWUMiv7PDVmJ8x8RxbE88PPdxf08HVcFTK+sMYz+ uXy1g7STZcZaR5lCcLaNKCmw1+r5CBPk+NuRUrYZNJUfRy0ooRtLiXwiN4xIt0NdkqflmfLi V7ODE5B9+fXooIz/N3Yvoy+rt+kQ7lkA05XP2jH9rLqZyPUyXWunN1bW+GScDGDCG6toPe+Z f9Yxu3XOeEcmAoYqJJ1FrtmwP5s59broLMGnA1oEG+SMgauA7JkZHKHwdNOputGwboA4Vm6X UeG+997P7SVOZy6TA5NdVR9NunTh+sJnjTy7OguJBSo7SB6y7OLTEFOMkTekydaNrZ0bNsoz OpJVBT6MOBjZs7G6uq7sx0= IronPort-HdrOrdr: A9a23:vbGmha5VsjoDo7gKTQPXwPLXdLJyesId70hD6qhwISY1TiX+rb HXoB17726MtN9/YgBCpTntAsa9qDbnhPpICOoqTNGftWvdyQmVxehZhOOIqVCNJ8S9zJ876U 4JSdkENDSaNzhHZKjBjjVQa+xQpeW6zA== X-IronPort-AV: E=Sophos;i="5.88,286,1635220800"; d="scan'208";a="62341821" From: Andrew Cooper To: Xen-devel CC: Andrew Cooper , Jan Beulich , =?UTF-8?q?Roger=20Pau=20Monn=C3=A9?= , Wei Liu Subject: [PATCH 1/3] x86/msr: Split MSR_SPEC_CTRL handling Date: Thu, 13 Jan 2022 16:38:31 +0000 Message-ID: <20220113163833.3831-2-andrew.cooper3@citrix.com> X-Mailer: git-send-email 2.11.0 In-Reply-To: <20220113163833.3831-1-andrew.cooper3@citrix.com> References: <20220113163833.3831-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: 1642091960507100005 In order to fix a VT-x bug, and support MSR_SPEC_CTRL on AMD, there will ne= ed to be three different access methods for where the guest's value lives. However, it would be better not to duplicate the #GP checking logic. guest_{rd,wr}msr() are always called first in the PV and HVM MSR paths, so = we can repurpose X86EMUL_UNHANDLEABLE slightly for this. This is going to be a common pattern for other MSRs too in the future. Duplicate the msrs->spec_ctrl.raw accesses in the PV and VT-x paths for now. The SVM path is currently unreachable because of the CPUID policy. No functional change. Signed-off-by: Andrew Cooper Reviewed-by: Roger Pau Monn=C3=A9 --- CC: Jan Beulich CC: Roger Pau Monn=C3=A9 CC: Wei Liu --- xen/arch/x86/hvm/vmx/vmx.c | 10 ++++++++++ xen/arch/x86/include/asm/msr.h | 11 +++++++---- xen/arch/x86/msr.c | 6 ++---- xen/arch/x86/pv/emul-priv-op.c | 10 ++++++++++ 4 files changed, 29 insertions(+), 8 deletions(-) diff --git a/xen/arch/x86/hvm/vmx/vmx.c b/xen/arch/x86/hvm/vmx/vmx.c index a7a0d662342a..28ee6393f11e 100644 --- a/xen/arch/x86/hvm/vmx/vmx.c +++ b/xen/arch/x86/hvm/vmx/vmx.c @@ -3128,12 +3128,17 @@ static int is_last_branch_msr(u32 ecx) static int vmx_msr_read_intercept(unsigned int msr, uint64_t *msr_content) { struct vcpu *curr =3D current; + const struct vcpu_msrs *msrs =3D curr->arch.msrs; uint64_t tmp; =20 HVM_DBG_LOG(DBG_LEVEL_MSR, "ecx=3D%#x", msr); =20 switch ( msr ) { + case MSR_SPEC_CTRL: /* guest_rdmsr() has already performed #GP checks.= */ + *msr_content =3D msrs->spec_ctrl.raw; + break; + case MSR_IA32_SYSENTER_CS: __vmread(GUEST_SYSENTER_CS, msr_content); break; @@ -3331,6 +3336,7 @@ void vmx_vlapic_msr_changed(struct vcpu *v) static int vmx_msr_write_intercept(unsigned int msr, uint64_t msr_content) { struct vcpu *v =3D current; + struct vcpu_msrs *msrs =3D v->arch.msrs; const struct cpuid_policy *cp =3D v->domain->arch.cpuid; =20 HVM_DBG_LOG(DBG_LEVEL_MSR, "ecx=3D%#x, msr_value=3D%#"PRIx64, msr, msr= _content); @@ -3339,6 +3345,10 @@ static int vmx_msr_write_intercept(unsigned int msr,= uint64_t msr_content) { uint64_t rsvd, tmp; =20 + case MSR_SPEC_CTRL: /* guest_wrmsr() has already performed #GP checks.= */ + msrs->spec_ctrl.raw =3D msr_content; + return X86EMUL_OKAY; + case MSR_IA32_SYSENTER_CS: __vmwrite(GUEST_SYSENTER_CS, msr_content); break; diff --git a/xen/arch/x86/include/asm/msr.h b/xen/arch/x86/include/asm/msr.h index 1d3eca9063a2..0b2176a9bc53 100644 --- a/xen/arch/x86/include/asm/msr.h +++ b/xen/arch/x86/include/asm/msr.h @@ -367,10 +367,13 @@ int init_domain_msr_policy(struct domain *d); int init_vcpu_msr_policy(struct vcpu *v); =20 /* - * Below functions can return X86EMUL_UNHANDLEABLE which means that MSR is - * not (yet) handled by it and must be processed by legacy handlers. Such - * behaviour is needed for transition period until all rd/wrmsr are handled - * by the new MSR infrastructure. + * The below functions return X86EMUL_*. Callers are responsible for + * converting X86EMUL_EXCEPTION into #GP[0]. + * + * X86EMUL_UNHANDLEABLE means "not everything complete". It could be that: + * 1) Common #GP checks have been done, but val access needs delegating = to the + * per-VM-type handlers. + * 2) The MSR is not handled at all by common logic. * * These functions are also used by the migration logic, so need to cope w= ith * being used outside of v's context. diff --git a/xen/arch/x86/msr.c b/xen/arch/x86/msr.c index b834456c7b02..3549630d6699 100644 --- a/xen/arch/x86/msr.c +++ b/xen/arch/x86/msr.c @@ -265,8 +265,7 @@ int guest_rdmsr(struct vcpu *v, uint32_t msr, uint64_t = *val) case MSR_SPEC_CTRL: if ( !cp->feat.ibrsb ) goto gp_fault; - *val =3D msrs->spec_ctrl.raw; - break; + return X86EMUL_UNHANDLEABLE; /* Delegate value to per-VM-type logi= c. */ =20 case MSR_INTEL_PLATFORM_INFO: *val =3D mp->platform_info.raw; @@ -514,8 +513,7 @@ int guest_wrmsr(struct vcpu *v, uint32_t msr, uint64_t = val) if ( val & rsvd ) goto gp_fault; /* Rsvd bit set? */ =20 - msrs->spec_ctrl.raw =3D val; - break; + return X86EMUL_UNHANDLEABLE; /* Delegate value to per-VM-type logi= c. */ =20 case MSR_PRED_CMD: if ( !cp->feat.ibrsb && !cp->extd.ibpb ) diff --git a/xen/arch/x86/pv/emul-priv-op.c b/xen/arch/x86/pv/emul-priv-op.c index c78be6d92b21..6644e739209c 100644 --- a/xen/arch/x86/pv/emul-priv-op.c +++ b/xen/arch/x86/pv/emul-priv-op.c @@ -875,6 +875,7 @@ static int read_msr(unsigned int reg, uint64_t *val, struct x86_emulate_ctxt *ctxt) { struct vcpu *curr =3D current; + const struct vcpu_msrs *msrs =3D curr->arch.msrs; const struct domain *currd =3D curr->domain; const struct cpuid_policy *cp =3D currd->arch.cpuid; bool vpmu_msr =3D false, warn =3D false; @@ -898,6 +899,10 @@ static int read_msr(unsigned int reg, uint64_t *val, *val |=3D APIC_BASE_BSP; return X86EMUL_OKAY; =20 + case MSR_SPEC_CTRL: /* guest_rdmsr() has already performed #GP checks.= */ + *val =3D msrs->spec_ctrl.raw; + return X86EMUL_OKAY; + case MSR_FS_BASE: if ( !cp->extd.lm ) break; @@ -1024,6 +1029,7 @@ static int write_msr(unsigned int reg, uint64_t val, struct x86_emulate_ctxt *ctxt) { struct vcpu *curr =3D current; + struct vcpu_msrs *msrs =3D curr->arch.msrs; const struct domain *currd =3D curr->domain; const struct cpuid_policy *cp =3D currd->arch.cpuid; bool vpmu_msr =3D false; @@ -1041,6 +1047,10 @@ static int write_msr(unsigned int reg, uint64_t val, { uint64_t temp; =20 + case MSR_SPEC_CTRL: /* guest_wrmsr() has already performed #GP checks.= */ + msrs->spec_ctrl.raw =3D val; + return X86EMUL_OKAY; + case MSR_FS_BASE: case MSR_GS_BASE: case MSR_SHADOW_GS_BASE: --=20 2.11.0 From nobody Sat Apr 20 00:42:36 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=1642091960; cv=none; d=zohomail.com; s=zohoarc; b=fVAHweqprQVjMOLwFp6s9WKQivZWnykyphtj9A3HNCm8brEUPPZGr/iJBzhZQSTZPk4E6ChIoXlBbCnk4dr1g+AwHcwN61gOpPMPBXFpyNC6xLBDAulNqEkS4wMyk7xSOSWNQ56490f/Nyh2Ma85VEOjZWb5TbBVj6aQCotdSv0= ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=zohomail.com; s=zohoarc; t=1642091960; 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=mGP49brrDUkmK0BdbP6PSKtpkJnmZ/L8VVmRtrOSks4=; b=RylIXesqIFNF+MaNhvmFMyYNmpr3gxxazQm1nwcBTUMv1zpJUOAAJ1WQYG6nhP+Qjwi07DnNzH5GN93iaTp4uo0HqyGKNvyMl4mQFT0ex5nmVJIagKOS24ErfUQWf8nbRQ9oQ7/jEp9UPxZ/WpmGMonU4Ed6JrxizVDSi1t2yaA= 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 1642091960723293.8676624710505; Thu, 13 Jan 2022 08:39:20 -0800 (PST) Received: from list by lists.xenproject.org with outflank-mailman.257286.442086 (Exim 4.92) (envelope-from ) id 1n837l-0001i0-IT; Thu, 13 Jan 2022 16:38:53 +0000 Received: by outflank-mailman (output) from mailman id 257286.442086; Thu, 13 Jan 2022 16:38:53 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1n837l-0001ht-F8; Thu, 13 Jan 2022 16:38:53 +0000 Received: by outflank-mailman (input) for mailman id 257286; Thu, 13 Jan 2022 16:38:51 +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 1n837j-0001gG-Mk for xen-devel@lists.xenproject.org; Thu, 13 Jan 2022 16:38:51 +0000 Received: from esa3.hc3370-68.iphmx.com (esa3.hc3370-68.iphmx.com [216.71.145.155]) by se1-gles-sth1.inumbo.com (Halon) with ESMTPS id 4862c5d8-748f-11ec-bcf3-e9554a921baa; Thu, 13 Jan 2022 17:38:50 +0100 (CET) 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: 4862c5d8-748f-11ec-bcf3-e9554a921baa DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=citrix.com; s=securemail; t=1642091930; h=from:to:cc:subject:date:message-id:in-reply-to: references:mime-version:content-transfer-encoding; bh=tsZqCwP/9e30gFHgjSlmMePARuttaiZ9/gTqptDuKYQ=; b=bNl0Yy7giZpd+MsVTLhPOS5h9vO+JcA/3TeHifQT6E7OiCOi/SCXt1tR nDSsT1V/MXUWqzSvjGNPAmwSfUD9259RvLlWe1/ZolcPEYmaE4TZgJR7i CBccs4ToexZR0cid2OKE8F04OFhO3+RNBKwAS/7eFOhR57bonplZ4HXO0 g=; Authentication-Results: esa3.hc3370-68.iphmx.com; dkim=none (message not signed) header.i=none IronPort-SDR: YM7XPkVGIo6D+Bx1k+vpFCmlqh1HFHaqi2ijNLGCIKfZJsf7H4GlvtM68h/enzq1JJVzHjfqNf WomRlwuNISemojJXghp/YNBWUMs7j/XOQzlAGEj65amylmBSxXkWsqejfvk9JZC0XovI0pq/Fa Ge6aZ6bYpn5nvuLKrPR7n/3o6iHvpIkaP1B6bs5tffM1KDj8ECKQkvSM0bmQAX6R6Q6eMaTUoS iJ451hVY2ll0y48zfWwk8cIRWqPLp5S7C+8d3vfJtTJ2ezlIuYLI+HL0zr+wkXx2ptk5DMKx1k EG4Ggh4d4TTBMnoG4NjsG4ii X-SBRS: 5.2 X-MesageID: 61937667 X-Ironport-Server: esa3.hc3370-68.iphmx.com X-Remote-IP: 162.221.156.83 X-Policy: $RELAYED IronPort-Data: A9a23:ApJpAq+LuP0MzLQ8ycV4DrUDenmTJUtcMsCJ2f8bNWPcYEJGY0x3x jQXC2rXOPiDZTanLYtxbIi+pxkE65TTmNJnHQFt+X08E34SpcT7XtnIdU2Y0wF+jyHgoOCLy +1EN7Es+ehtFie0Si9AttENlFEkvU2ybuOU5NXsZ2YhFWeIdA970Ug5w7dg2dYy6TSEK1jlV e3a8pW31GCNg1aYAkpMg05UgEoy1BhakGpwUm0WPZinjneH/5UmJMt3yZWKB2n5WuFp8tuSH I4v+l0bElTxpH/BAvv9+lryn9ZjrrT6ZWBigVIOM0Sub4QrSoXfHc/XOdJFAXq7hQllkPhox vdxqZ63azsFO42LuOdeXQdDIRtXaPguFL/veRBTsOSWxkzCNXDt3+9vHAc9OohwFuRfWD8Us 6ZCcXZUM07F17neLLGTE4GAguwKKsXxMZxZkXZn1TzDVt4tQIzZQrWM7thdtNs1rp4XTK2BO ZRGAdZpRATAbCBEAVAJNLxk26SPvVfAd2Vjgk3A8MLb5ECMlVcsgdABKuH9eMGMA8NcnU+ap 2fP12X/HhwecteYzFKt8X+yh+mJgSLyXqoTEqG18rhhh1j77nMXIA0bUx28u/bRol6zXZdTJ lIZ/gIqrLMu7wq7Q9/lRRq6rXWY+BkGVLJ4Mcc39QWMwar8+BuCCy4PSTspVTA9nJZoH3pwj AbPxo63Q2w02FGIdZ6D3q6ajw+uOy83EUMHRWgkTkgL/cLRmqhm23ojUe1fOKKyi9T0HxT5z DaLsDUyit0vsCIb60mo1QuZ2mzx//AlWiZwv1yKBTz9smuVcab4P9TA1LTN0RpXwG91pHGlt WNMpcWR5ftm4XqlxH3UG7Vl8F1ECp+43NzgbbxHQ8hJG9eFoSfLkWVsDNdWfhcB3iEsI26BX aMrkVkNjKK/xVPzBUONX6q/Ct4x0Y/rHsn/W/bfY7JmO8YtLlfep3kwOR7LhQgBdXTAd4lla f93lu72XB4n5VlPlmLqF4/xL5d2rszB+Y8jbc+ilEn2uVZvTHWUVa0EIDOzghMRt8u5TPHu2 48HbaOikkwHOMWnO3W/2dNNcTgicCZqbbir+50/XrPSeWJORTB+Y8I9NJt8IeSJaYwPyLeRl px8M2cFoGfCaYrvclTVOis9OeK2Df6SbxsTZEQRALph4FB7Ca7H0UvVX8FfkWAP+LMxwPhqY eMCfsncUP1DRi6eo2YWbIXnrZwkfxOu3FrcMy2gaTk5XphhWw2WpYO0IlqxrHEDXnitqM8zg 7y8zQeHE5ANcBtvUZTNY/W1wlLv4XVEwLBuX1HFK8V4cVn39NQ4MDT4i/I6epleKRjKyjaA+ RyRBBMU+bvEr4MvqYGbjqGYtYa5VeB5GxMCTWXc6L+3Mwjc/3aintAcALrZI2iFWTqtqqu4Z OhTw/XtC9E9nQ5H49hmDrJm7aMi/N+z9bVU+RtpQSfQZFOxB7I+fnTfhZtTtrdAz6NysBetX h7d4cFTPLiENZ+3EFMVIwZ5PO2P2etNx2vX5PUxZk77+DV27PyMVkALZ0uAjylULb1UNoI5w Lh+5J5KulLn0hd6YMybii109niXKi1SWqoqgZgWHYv3h1d50VpFe5HdVnf77Zznhw+g6aX2z ut4XJb/uok= IronPort-HdrOrdr: A9a23:t7fHo6w0a6hoOs87rFdiKrPwFr1zdoMgy1knxilNoRw8SK2lfq eV7YwmPH7P+U8ssR4b6LO90cW7Lk80sKQFhbX5Xo3SOjUO2lHYTr2KhLGKq1aLdkHDH6xmpM BdmsBFeabN5DNB7foSjjPXLz9Z+qjjzJyV X-IronPort-AV: E=Sophos;i="5.88,286,1635220800"; d="scan'208";a="61937667" From: Andrew Cooper To: Xen-devel CC: Andrew Cooper , Jan Beulich , =?UTF-8?q?Roger=20Pau=20Monn=C3=A9?= , Wei Liu , Jun Nakajima , Kevin Tian Subject: [PATCH 2/3] x86/spec-ctrl: Drop SPEC_CTRL_{ENTRY_FROM,EXIT_TO}_HVM Date: Thu, 13 Jan 2022 16:38:32 +0000 Message-ID: <20220113163833.3831-3-andrew.cooper3@citrix.com> X-Mailer: git-send-email 2.11.0 In-Reply-To: <20220113163833.3831-1-andrew.cooper3@citrix.com> References: <20220113163833.3831-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: 1642091963066100001 These were written before Spectre/Meltdown went public, and there was large uncertainty in how the protections would evolve. As it turns out, they're very specific to Intel hardware, and not very suitable for AMD. Expand and drop the macros. No change at all for VT-x. For AMD, the only relevant piece of functionality is DO_OVERWRITE_RSB, although we will soon be adding (different) logic to handle MSR_SPEC_CTRL. This has a marginal improvement of removing an unconditional pile of long-n= ops from the vmentry/exit path. Signed-off-by: Andrew Cooper Reviewed-by: Roger Pau Monn=C3=A9 --- CC: Jan Beulich CC: Roger Pau Monn=C3=A9 CC: Wei Liu CC: Jun Nakajima CC: Kevin Tian --- xen/arch/x86/hvm/svm/entry.S | 5 +++-- xen/arch/x86/hvm/vmx/entry.S | 8 ++++++-- xen/arch/x86/include/asm/spec_ctrl_asm.h | 17 ++--------------- 3 files changed, 11 insertions(+), 19 deletions(-) diff --git a/xen/arch/x86/hvm/svm/entry.S b/xen/arch/x86/hvm/svm/entry.S index e208a4b32ae7..276215d36aff 100644 --- a/xen/arch/x86/hvm/svm/entry.S +++ b/xen/arch/x86/hvm/svm/entry.S @@ -59,7 +59,7 @@ __UNLIKELY_END(nsvm_hap) mov VCPUMSR_spec_ctrl_raw(%rax), %eax =20 /* WARNING! `ret`, `call *`, `jmp *` not safe beyond this point. */ - SPEC_CTRL_EXIT_TO_HVM /* Req: a=3Dspec_ctrl %rsp=3Dregs/cpuinfo,= Clob: cd */ + /* SPEC_CTRL_EXIT_TO_SVM (nothing currently) */ =20 pop %r15 pop %r14 @@ -86,7 +86,8 @@ __UNLIKELY_END(nsvm_hap) =20 GET_CURRENT(bx) =20 - SPEC_CTRL_ENTRY_FROM_HVM /* Req: b=3Dcurr %rsp=3Dregs/cpuinfo, = Clob: acd */ + /* SPEC_CTRL_ENTRY_FROM_SVM Req: b=3Dcurr %rsp=3Dregs/cpuinfo, = Clob: ac */ + ALTERNATIVE "", DO_OVERWRITE_RSB, X86_FEATURE_SC_RSB_HVM /* WARNING! `ret`, `call *`, `jmp *` not safe before this point. */ =20 stgi diff --git a/xen/arch/x86/hvm/vmx/entry.S b/xen/arch/x86/hvm/vmx/entry.S index 27c8c5ca4943..30139ae58e9d 100644 --- a/xen/arch/x86/hvm/vmx/entry.S +++ b/xen/arch/x86/hvm/vmx/entry.S @@ -33,7 +33,9 @@ ENTRY(vmx_asm_vmexit_handler) movb $1,VCPU_vmx_launched(%rbx) mov %rax,VCPU_hvm_guest_cr2(%rbx) =20 - SPEC_CTRL_ENTRY_FROM_HVM /* Req: b=3Dcurr %rsp=3Dregs/cpuinfo, = Clob: acd */ + /* SPEC_CTRL_ENTRY_FROM_VMX Req: b=3Dcurr %rsp=3Dregs/cpuinfo, = Clob: acd */ + ALTERNATIVE "", DO_OVERWRITE_RSB, X86_FEATURE_SC_RSB_HVM + ALTERNATIVE "", DO_SPEC_CTRL_ENTRY_FROM_HVM, X86_FEATURE_SC_MSR_HVM /* WARNING! `ret`, `call *`, `jmp *` not safe before this point. */ =20 /* Hardware clears MSR_DEBUGCTL on VMExit. Reinstate it if debugg= ing Xen. */ @@ -80,7 +82,9 @@ UNLIKELY_END(realmode) mov VCPUMSR_spec_ctrl_raw(%rax), %eax =20 /* WARNING! `ret`, `call *`, `jmp *` not safe beyond this point. */ - SPEC_CTRL_EXIT_TO_HVM /* Req: a=3Dspec_ctrl %rsp=3Dregs/cpuinfo,= Clob: cd */ + /* SPEC_CTRL_EXIT_TO_VMX Req: a=3Dspec_ctrl %rsp=3Dregs/cpuinfo,= Clob: cd */ + ALTERNATIVE "", DO_SPEC_CTRL_EXIT_TO_GUEST, X86_FEATURE_SC_MSR_HVM + ALTERNATIVE "", __stringify(verw CPUINFO_verw_sel(%rsp)), X86_FEAT= URE_SC_VERW_HVM =20 mov VCPU_hvm_guest_cr2(%rbx),%rax =20 diff --git a/xen/arch/x86/include/asm/spec_ctrl_asm.h b/xen/arch/x86/includ= e/asm/spec_ctrl_asm.h index cb34299a865b..18ecfcd70375 100644 --- a/xen/arch/x86/include/asm/spec_ctrl_asm.h +++ b/xen/arch/x86/include/asm/spec_ctrl_asm.h @@ -68,14 +68,14 @@ * * The following ASM fragments implement this algorithm. See their local * comments for further details. - * - SPEC_CTRL_ENTRY_FROM_HVM + * - SPEC_CTRL_ENTRY_FROM_{SVM,VMX} (See appropriate entry.S files) * - SPEC_CTRL_ENTRY_FROM_PV * - SPEC_CTRL_ENTRY_FROM_INTR * - SPEC_CTRL_ENTRY_FROM_INTR_IST * - SPEC_CTRL_EXIT_TO_XEN_IST * - SPEC_CTRL_EXIT_TO_XEN * - SPEC_CTRL_EXIT_TO_PV - * - SPEC_CTRL_EXIT_TO_HVM + * - SPEC_CTRL_EXIT_TO_{SVM,VMX} */ =20 .macro DO_OVERWRITE_RSB tmp=3Drax @@ -225,12 +225,6 @@ wrmsr .endm =20 -/* Use after a VMEXIT from an HVM guest. */ -#define SPEC_CTRL_ENTRY_FROM_HVM \ - ALTERNATIVE "", DO_OVERWRITE_RSB, X86_FEATURE_SC_RSB_HVM; \ - ALTERNATIVE "", DO_SPEC_CTRL_ENTRY_FROM_HVM, \ - X86_FEATURE_SC_MSR_HVM - /* Use after an entry from PV context (syscall/sysenter/int80/int82/etc). = */ #define SPEC_CTRL_ENTRY_FROM_PV \ ALTERNATIVE "", DO_OVERWRITE_RSB, X86_FEATURE_SC_RSB_PV; \ @@ -255,13 +249,6 @@ ALTERNATIVE "", __stringify(verw CPUINFO_verw_sel(%rsp)), \ X86_FEATURE_SC_VERW_PV =20 -/* Use when exiting to HVM guest context. */ -#define SPEC_CTRL_EXIT_TO_HVM \ - ALTERNATIVE "", \ - DO_SPEC_CTRL_EXIT_TO_GUEST, X86_FEATURE_SC_MSR_HVM; \ - ALTERNATIVE "", __stringify(verw CPUINFO_verw_sel(%rsp)), \ - X86_FEATURE_SC_VERW_HVM - /* * Use in IST interrupt/exception context. May interrupt Xen or PV contex= t. * Fine grain control of SCF_ist_wrmsr is needed for safety in the S3 resu= me --=20 2.11.0 From nobody Sat Apr 20 00:42:36 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=1642091957; cv=none; d=zohomail.com; s=zohoarc; b=PSjYC4snRMk2xLvocSJ5x9JRh3iXP/8U6YVYqgq44cGQZyJpL+kPZ/mQU5pl5uzf3VkIKjEZm7M0tB18zY3RUMqEzb8TvYFdZUXvMROwAObZuLIW+Tmkl5tITUs6Yza8Zk6rRR+/t7+VeQ7nz2sXgruDc5v0Xn/YqsEaxBC/bHc= ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=zohomail.com; s=zohoarc; t=1642091957; 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=RcyRLvHfydKTw8f/ImOnfxEXUsbFXBvKIjosRu/4thY=; b=HwnswNOt/ZQ/1OkO5YTgLajzZXFXYb2cSk7qds+b/pseE9wZx/5tQshCeWUsFILh6/URPQCDh+Q0e4WDkjsg7yFGjCbbLCCifgQbNH4CEkf4tHMNmuIZey4UpWpvgdIiFnD1SpXft8XyKDcg01I6iCg0Jiaqdwtx57DD6ztH5UU= 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 1642091957296904.9900062453108; Thu, 13 Jan 2022 08:39:17 -0800 (PST) Received: from list by lists.xenproject.org with outflank-mailman.257287.442092 (Exim 4.92) (envelope-from ) id 1n837m-0001li-04; Thu, 13 Jan 2022 16:38:54 +0000 Received: by outflank-mailman (output) from mailman id 257287.442092; Thu, 13 Jan 2022 16:38:53 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1n837l-0001l9-Pt; Thu, 13 Jan 2022 16:38:53 +0000 Received: by outflank-mailman (input) for mailman id 257287; Thu, 13 Jan 2022 16:38:51 +0000 Received: from se1-gles-flk1-in.inumbo.com ([94.247.172.50] helo=se1-gles-flk1.inumbo.com) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1n837j-0001RD-J3 for xen-devel@lists.xenproject.org; Thu, 13 Jan 2022 16:38:51 +0000 Received: from esa5.hc3370-68.iphmx.com (esa5.hc3370-68.iphmx.com [216.71.155.168]) by se1-gles-flk1.inumbo.com (Halon) with ESMTPS id 48073cfb-748f-11ec-a563-1748fde96b53; Thu, 13 Jan 2022 17:38:49 +0100 (CET) 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: 48073cfb-748f-11ec-a563-1748fde96b53 DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=citrix.com; s=securemail; t=1642091929; h=from:to:cc:subject:date:message-id:in-reply-to: references:mime-version:content-transfer-encoding; bh=FMDy/dj6l/QX6LBOg2g+h5IZtV9TVhX1B7/xS1PYv88=; b=FWJbYrnOFLsbS94i5uLb/+4BFzhHDEesiuJ54Wb+MuwBM1+7FwscX4PP bOntdQ0oF9NxoABKSRKlQueJVJxHQ1+6MthymYOzQQMxSrMGqEjBXCNXv BEQa0mT4x7PmIcnL0h0XvZCHAnhn/acNjXQYLYPRyStyNzNj7EFwtJK+R c=; Authentication-Results: esa5.hc3370-68.iphmx.com; dkim=none (message not signed) header.i=none IronPort-SDR: Vg2mI7n7gsW1hGZlLwBaPDwvmJQyj7FgkISdkgNQ2nrbsDolVKIH+vz63o8aesc10rSqUlrlEL Yb6M+OICoZ8FegDsC2tsHbkPPTHiybpSLjnUmoQHI5RR/4lZZqUOXa2jxebptfCjcAAjQ9pgfw 9tq2Ksf27+n5bTtBCJXbAkpi0R+S4eVkOvChc5flgVHHG4ieEKfieek2akaxPnpUCj8NikdGXm 0aN8LmQAvWHk6Q1dRdBYtUtDd34eOJnDVG9mT5rItuScSR34eyjJXm5MnXJttpUWWZ8hjdonom GKxyzBD4TrrS7YXwbztqf+Xs X-SBRS: 5.2 X-MesageID: 61416780 X-Ironport-Server: esa5.hc3370-68.iphmx.com X-Remote-IP: 162.221.156.83 X-Policy: $RELAYED IronPort-Data: A9a23:h3HADqj7+jeAGK1oyTVTRbAEX161mhcKZh0ujC45NGQN5FlHY01je htvC2uAbq2Ja2HxctknaIvj/B4Bu8SDzoIyTgNuqi43Fyob9cadCdqndUqhZCn6wu8v7a5EA 2fyTvGacajYm1eF/k/F3oAMKRCQ7InQLlbGILes1htZGEk0GE/NtTo5w7Rj2tcx2oDja++wk YiaT/P3aQfNNwFcagr424rbwP+4lK2v0N+wlgVWicFj5DcypVFMZH4sDfjZw0/DaptVBoaHq 9Prl9lVyI97EyAFUbtJmp6jGqEDryW70QKm0hK6UID66vROS7BbPg/W+5PwZG8O4whlkeydx /1Aj4epSF8TApbXu/8fCglUMB5XJvFJreqvzXiX6aR/zmXDenrohf5vEFs3LcsT/eMf7WNmr KJCbmpXN1ba2rzwkOnTpupE36zPKOHCOo8Ft24m5jbeFfs8GrjIQrnQ5M8e1zA17ixLNaiHO 5NHNmo3BPjGSzhzGk8lI84Up/6t31vEc2QH+Vi8/JNitgA/yyQuieOwYbI5YOeiR9hT2ECRp WvE/mHwKhAcKNGbjzGC9xqEheLRnCW9RIMbEpW58OJnhBuYwWl7IAISfUu2p7++kEHWc8JSL QkY9zQjqYA29Ve3VZ/tUhugunmGsxUAHd1KHIUSyiuA167V6AaxHXUfQ3hKb9lOiSMtbWV0j BnTxYqvXGEx9u3OIZ6AyluKhT6IIjEUdVU+XjQnVglc89XAn6go0h2aG76PD5WJptHyHDjxx RWDoy4/m6gfgKY36kmrwbzUq2ny/8aUF2bZ8i2SBzv4tV0hOOZJcqT1sQCz0BpWEGqOorBtV lAgktPW0u0BBIrleMelELRUR+HBCxpo3VThbb9T83sJq2XFF52LJ9k4DNRCyKFBaJZsldjBO h67hO+pzMUPVEZGlIcuC25LN+wkzLL7CfPuXe3OY9xFb/BZLVHbpnk3PhbOgzC2yiDAdJ3T3 7/BIa5A6l5AWMxaIMeeHb9BgdfHOAhjrY8seXwL50v+iufPDJJkYbwELEGPfogEAFCs+23oH yJkH5LSkX13CbSmCgGOqNJ7BQ1UcRATWM6nw+QKJr/rClc3QwkJVq6OqY7NjqQ4xcy5YM+So CHkMqKZoXKi7UD6xfKiMSE8OOixDMcm/RrW/0UEZD6V5pTqWq73hI93Snf9VeJPGDVLwaEmQ v8bVd+HB/gTGD3L9y5ENcv2rZB4dQTtjgWLZnL3bD86dp9mZgrI5t67IVe/qHhQVnK65Zkkv rmt9gLHWp5fFQ5sO9nbNaC0xFSrsHlDxO8rBxnUIsNecVnH+ZRxL3Cjlec+JswBcE2RxjaT2 wuMLw0foO3B/908/NXT3PjWpIa1CepuWEFdGjCDv7qxMCDb+EulwJNBD7nULWyMCjus9fz7N +tPzvz6PPkWp3pwstJxQ+Rx0KYzx9rzvLsGnA5qK2rGMgawAbR6L3jYgcQW7v9RxqVUsBedU 16U/oUIIq2APc7oHQJDJAchaejfh/gYliOLsKYwKUT+oiR24KCGQQNZOBzV0H5RK758MYUEx +Y9uZFJt1zj20RyatvW3DpJ82msL2AbV/R1v54XN4bnlw43xwwQepfbECL3vMmCZtgk3pPG+ dNIaH4uX4hh+3c= IronPort-HdrOrdr: A9a23:Lb/SNq+QyjLE/Fy1ZCBuk+DgI+orL9Y04lQ7vn2YSXRuHPBw8P re5cjztCWE7gr5N0tBpTntAsW9qDbnhPtICOoqTNCftWvdyQiVxehZhOOIqVDd8m/Fh4pgPM 9bAtBD4bbLbGSS4/yU3ODBKadD/OW6 X-IronPort-AV: E=Sophos;i="5.88,286,1635220800"; d="scan'208";a="61416780" From: Andrew Cooper To: Xen-devel CC: Andrew Cooper , Jan Beulich , =?UTF-8?q?Roger=20Pau=20Monn=C3=A9?= , Wei Liu , Jun Nakajima , Kevin Tian Subject: [PATCH 3/3] x86/spec-ctrl: Fix NMI race condition with VT-x MSR_SPEC_CTRL handling Date: Thu, 13 Jan 2022 16:38:33 +0000 Message-ID: <20220113163833.3831-4-andrew.cooper3@citrix.com> X-Mailer: git-send-email 2.11.0 In-Reply-To: <20220113163833.3831-1-andrew.cooper3@citrix.com> References: <20220113163833.3831-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: 1642091958505100002 The logic was based on a mistaken understanding of how NMI blocking on vmex= it works. NMIs are only blocked for EXIT_REASON_NMI, and not for general exit= s. Therefore, an NMI can in general hit early in the vmx_asm_vmexit_handler pa= th, and the guest's value will be clobbered before it is saved. Switch to using MSR load/save lists. This causes the guest value to be sav= ed atomically with respect to NMIs/MCEs/etc. First, update vmx_cpuid_policy_changed() to configure the load/save lists at the same time as configuring the intercepts. This function is always used = in remote context, so extend the vmx_vmcs_{enter,exit}() block to cover the wh= ole function, rather than having multiple remote acquisitions of the same VMCS. vmx_add_guest_msr() can fail, but only in ways which are entirely fatal to = the guest, so handle failures using domain_crash(). vmx_del_msr() can fail with -ESRCH but we don't matter, and this path will be taken during domain create on a system lacking IBRSB. Second, update vmx_msr_{read,write}_intercept() to use the load/save lists rather than vcpu_msrs, and update the comment to describe the new state location. Finally, adjust the entry/exit asm. Drop DO_SPEC_CTRL_ENTRY_FROM_HVM entirely, and use a shorter code sequence to simply reload Xen's setting fr= om the top-of-stack block. Because the guest values are loaded/saved atomically, we do not need to use the shadowing logic to cope with late NMIs/etc, so we can omit DO_SPEC_CTRL_EXIT_TO_GUEST entirely and VMRESUME/VMLAUNCH with Xen's value = in context. Furthermore, we can drop the SPEC_CTRL_ENTRY_FROM_PV too, as ther= e's no need to switch back to Xen's context on an early failure. Signed-off-by: Andrew Cooper --- CC: Jan Beulich CC: Roger Pau Monn=C3=A9 CC: Wei Liu CC: Jun Nakajima CC: Kevin Tian Needs backporting as far as people can tolerate. If the entry/exit logic were in C, I'd ASSERT() that shadow tracking is off, but this is awkard to arrange in asm. --- xen/arch/x86/hvm/vmx/entry.S | 19 ++++++++++------- xen/arch/x86/hvm/vmx/vmx.c | 36 +++++++++++++++++++++++++++-= ---- xen/arch/x86/include/asm/msr.h | 10 ++++++++- xen/arch/x86/include/asm/spec_ctrl_asm.h | 32 ++++------------------------ 4 files changed, 56 insertions(+), 41 deletions(-) diff --git a/xen/arch/x86/hvm/vmx/entry.S b/xen/arch/x86/hvm/vmx/entry.S index 30139ae58e9d..297ed8685126 100644 --- a/xen/arch/x86/hvm/vmx/entry.S +++ b/xen/arch/x86/hvm/vmx/entry.S @@ -35,7 +35,14 @@ ENTRY(vmx_asm_vmexit_handler) =20 /* SPEC_CTRL_ENTRY_FROM_VMX Req: b=3Dcurr %rsp=3Dregs/cpuinfo, = Clob: acd */ ALTERNATIVE "", DO_OVERWRITE_RSB, X86_FEATURE_SC_RSB_HVM - ALTERNATIVE "", DO_SPEC_CTRL_ENTRY_FROM_HVM, X86_FEATURE_SC_MSR_HVM + + .macro restore_spec_ctrl + mov $MSR_SPEC_CTRL, %ecx + movzbl CPUINFO_xen_spec_ctrl(%rsp), %eax + xor %edx, %edx + wrmsr + .endm + ALTERNATIVE "", restore_spec_ctrl, X86_FEATURE_SC_MSR_HVM /* WARNING! `ret`, `call *`, `jmp *` not safe before this point. */ =20 /* Hardware clears MSR_DEBUGCTL on VMExit. Reinstate it if debugg= ing Xen. */ @@ -83,7 +90,6 @@ UNLIKELY_END(realmode) =20 /* WARNING! `ret`, `call *`, `jmp *` not safe beyond this point. */ /* SPEC_CTRL_EXIT_TO_VMX Req: a=3Dspec_ctrl %rsp=3Dregs/cpuinfo,= Clob: cd */ - ALTERNATIVE "", DO_SPEC_CTRL_EXIT_TO_GUEST, X86_FEATURE_SC_MSR_HVM ALTERNATIVE "", __stringify(verw CPUINFO_verw_sel(%rsp)), X86_FEAT= URE_SC_VERW_HVM =20 mov VCPU_hvm_guest_cr2(%rbx),%rax @@ -119,12 +125,11 @@ UNLIKELY_END(realmode) SAVE_ALL =20 /* - * PV variant needed here as no guest code has executed (so - * MSR_SPEC_CTRL can't have changed value), and NMIs/MCEs are liab= le - * to hit (in which case the HVM variant might corrupt things). + * SPEC_CTRL_ENTRY notes + * + * If we end up here, no guest code has executed. We still have X= en's + * choice of MSR_SPEC_CTRL in context, and the RSB is safe. */ - SPEC_CTRL_ENTRY_FROM_PV /* Req: %rsp=3Dregs/cpuinfo Clob: acd */ - /* WARNING! `ret`, `call *`, `jmp *` not safe before this point. */ =20 call vmx_vmentry_failure jmp .Lvmx_process_softirqs diff --git a/xen/arch/x86/hvm/vmx/vmx.c b/xen/arch/x86/hvm/vmx/vmx.c index 28ee6393f11e..d7feb5f9c455 100644 --- a/xen/arch/x86/hvm/vmx/vmx.c +++ b/xen/arch/x86/hvm/vmx/vmx.c @@ -592,6 +592,7 @@ void vmx_update_exception_bitmap(struct vcpu *v) static void vmx_cpuid_policy_changed(struct vcpu *v) { const struct cpuid_policy *cp =3D v->domain->arch.cpuid; + int rc =3D 0; =20 if ( opt_hvm_fep || (v->domain->arch.cpuid->x86_vendor !=3D boot_cpu_data.x86_vendor)= ) @@ -601,17 +602,27 @@ static void vmx_cpuid_policy_changed(struct vcpu *v) =20 vmx_vmcs_enter(v); vmx_update_exception_bitmap(v); - vmx_vmcs_exit(v); =20 /* * We can safely pass MSR_SPEC_CTRL through to the guest, even if STIBP * isn't enumerated in hardware, as SPEC_CTRL_STIBP is ignored. */ if ( cp->feat.ibrsb ) + { vmx_clear_msr_intercept(v, MSR_SPEC_CTRL, VMX_MSR_RW); + + rc =3D vmx_add_guest_msr(v, MSR_SPEC_CTRL, 0); + if ( rc ) + goto err; + } else + { vmx_set_msr_intercept(v, MSR_SPEC_CTRL, VMX_MSR_RW); =20 + /* Can only fail with -ESRCH, and we don't care. */ + vmx_del_msr(v, MSR_SPEC_CTRL, VMX_MSR_GUEST); + } + /* MSR_PRED_CMD is safe to pass through if the guest knows about it. */ if ( cp->feat.ibrsb || cp->extd.ibpb ) vmx_clear_msr_intercept(v, MSR_PRED_CMD, VMX_MSR_RW); @@ -623,6 +634,15 @@ static void vmx_cpuid_policy_changed(struct vcpu *v) vmx_clear_msr_intercept(v, MSR_FLUSH_CMD, VMX_MSR_RW); else vmx_set_msr_intercept(v, MSR_FLUSH_CMD, VMX_MSR_RW); + + err: + vmx_vmcs_exit(v); + + if ( rc ) + { + printk(XENLOG_G_ERR "MSR load/save list error: %d", rc); + domain_crash(v->domain); + } } =20 int vmx_guest_x86_mode(struct vcpu *v) @@ -3128,7 +3148,6 @@ static int is_last_branch_msr(u32 ecx) static int vmx_msr_read_intercept(unsigned int msr, uint64_t *msr_content) { struct vcpu *curr =3D current; - const struct vcpu_msrs *msrs =3D curr->arch.msrs; uint64_t tmp; =20 HVM_DBG_LOG(DBG_LEVEL_MSR, "ecx=3D%#x", msr); @@ -3136,7 +3155,11 @@ static int vmx_msr_read_intercept(unsigned int msr, = uint64_t *msr_content) switch ( msr ) { case MSR_SPEC_CTRL: /* guest_rdmsr() has already performed #GP checks.= */ - *msr_content =3D msrs->spec_ctrl.raw; + if ( vmx_read_guest_msr(curr, msr, msr_content) ) + { + ASSERT_UNREACHABLE(); + goto gp_fault; + } break; =20 case MSR_IA32_SYSENTER_CS: @@ -3336,7 +3359,6 @@ void vmx_vlapic_msr_changed(struct vcpu *v) static int vmx_msr_write_intercept(unsigned int msr, uint64_t msr_content) { struct vcpu *v =3D current; - struct vcpu_msrs *msrs =3D v->arch.msrs; const struct cpuid_policy *cp =3D v->domain->arch.cpuid; =20 HVM_DBG_LOG(DBG_LEVEL_MSR, "ecx=3D%#x, msr_value=3D%#"PRIx64, msr, msr= _content); @@ -3346,7 +3368,11 @@ static int vmx_msr_write_intercept(unsigned int msr,= uint64_t msr_content) uint64_t rsvd, tmp; =20 case MSR_SPEC_CTRL: /* guest_wrmsr() has already performed #GP checks.= */ - msrs->spec_ctrl.raw =3D msr_content; + if ( vmx_write_guest_msr(v, msr, msr_content) ) + { + ASSERT_UNREACHABLE(); + goto gp_fault; + } return X86EMUL_OKAY; =20 case MSR_IA32_SYSENTER_CS: diff --git a/xen/arch/x86/include/asm/msr.h b/xen/arch/x86/include/asm/msr.h index 0b2176a9bc53..5f851958992b 100644 --- a/xen/arch/x86/include/asm/msr.h +++ b/xen/arch/x86/include/asm/msr.h @@ -287,7 +287,15 @@ extern struct msr_policy raw_msr_policy, /* Container object for per-vCPU MSRs */ struct vcpu_msrs { - /* 0x00000048 - MSR_SPEC_CTRL */ + /* + * 0x00000048 - MSR_SPEC_CTRL + * + * For PV guests, this holds the guest kernel value. It is accessed on + * every entry/exit path. + * + * For VT-x guests, the guest value is held in the MSR guest load/save + * list. + */ struct { uint32_t raw; } spec_ctrl; diff --git a/xen/arch/x86/include/asm/spec_ctrl_asm.h b/xen/arch/x86/includ= e/asm/spec_ctrl_asm.h index 18ecfcd70375..ddce8b33fd17 100644 --- a/xen/arch/x86/include/asm/spec_ctrl_asm.h +++ b/xen/arch/x86/include/asm/spec_ctrl_asm.h @@ -42,9 +42,10 @@ * path, or late in the exit path after restoring the guest value. Th= is * will corrupt the guest value. * - * Factor 1 is dealt with by relying on NMIs/MCEs being blocked immediately - * after VMEXIT. The VMEXIT-specific code reads MSR_SPEC_CTRL and updates - * current before loading Xen's MSR_SPEC_CTRL setting. + * Factor 1 is dealt with: + * - On VMX by using MSR load/save lists to have vmentry/exit atomically + * load/save the guest value. Xen's value is loaded in regular code, = and + * there is no need to use the shadow logic (below). * * Factor 2 is harder. We maintain a shadow_spec_ctrl value, and a use_sh= adow * boolean in the per cpu spec_ctrl_flags. The synchronous use is: @@ -126,31 +127,6 @@ #endif .endm =20 -.macro DO_SPEC_CTRL_ENTRY_FROM_HVM -/* - * Requires %rbx=3Dcurrent, %rsp=3Dregs/cpuinfo - * Clobbers %rax, %rcx, %rdx - * - * The common case is that a guest has direct access to MSR_SPEC_CTRL, at - * which point we need to save the guest value before setting IBRS for Xen. - * Unilaterally saving the guest value is shorter and faster than checking. - */ - mov $MSR_SPEC_CTRL, %ecx - rdmsr - - /* Stash the value from hardware. */ - mov VCPU_arch_msrs(%rbx), %rdx - mov %eax, VCPUMSR_spec_ctrl_raw(%rdx) - xor %edx, %edx - - /* Clear SPEC_CTRL shadowing *before* loading Xen's value. */ - andb $~SCF_use_shadow, CPUINFO_spec_ctrl_flags(%rsp) - - /* Load Xen's intended value. */ - movzbl CPUINFO_xen_spec_ctrl(%rsp), %eax - wrmsr -.endm - .macro DO_SPEC_CTRL_ENTRY maybexen:req /* * Requires %rsp=3Dregs (also cpuinfo if !maybexen) --=20 2.11.0