From patchwork Wed Nov 1 19:20:57 2023 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 8bit X-Patchwork-Submitter: Andrew Cooper X-Patchwork-Id: 13443002 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 lists.xenproject.org (lists.xenproject.org [192.237.175.120]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.lore.kernel.org (Postfix) with ESMTPS id 3DA8CC4332F for ; Wed, 1 Nov 2023 19:21:40 +0000 (UTC) Received: from list by lists.xenproject.org with outflank-mailman.626622.977042 (Exim 4.92) (envelope-from ) id 1qyGmD-0005bo-FG; Wed, 01 Nov 2023 19:21:17 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 626622.977042; Wed, 01 Nov 2023 19:21:17 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1qyGmD-0005bh-Bh; Wed, 01 Nov 2023 19:21:17 +0000 Received: by outflank-mailman (input) for mailman id 626622; Wed, 01 Nov 2023 19:21:15 +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 1qyGmB-0005LP-Om for xen-devel@lists.xenproject.org; Wed, 01 Nov 2023 19:21:15 +0000 Received: from esa4.hc3370-68.iphmx.com (esa4.hc3370-68.iphmx.com [216.71.155.144]) by se1-gles-sth1.inumbo.com (Halon) with ESMTPS id d2f092c5-78eb-11ee-98d6-6d05b1d4d9a1; Wed, 01 Nov 2023 20:21:14 +0100 (CET) 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: d2f092c5-78eb-11ee-98d6-6d05b1d4d9a1 DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=citrix.com; s=securemail; t=1698866474; h=from:to:cc:subject:date:message-id:in-reply-to: references:mime-version:content-transfer-encoding; bh=Y4mUXFwEkYVV4PPcEwyjahUDfbyqiOJzsv7ADOUi+tI=; b=HZI4gRZyooFiHBoucUJueaOB74xKS6T8uht5HP1ekxdh3/wF+W7MBD6R Sw1f5KOSa3kZFLfNfIocr9OyIBZQ43nRtIDyLrgg4mWlpUPnuc2HyWSmm qyPm1cNxPUhtB1NRjdplTSVXHSfHDlhFrmkdAK2rKflbZCxST4HdF0S/S s=; X-CSE-ConnectionGUID: Gul5WXPuT/mnsoAh0qSvvQ== X-CSE-MsgGUID: Ocga0upYTMWL6C4tl9Gy+A== Authentication-Results: esa4.hc3370-68.iphmx.com; dkim=none (message not signed) header.i=none X-SBRS: 4.0 X-MesageID: 130083863 X-Ironport-Server: esa4.hc3370-68.iphmx.com X-Remote-IP: 162.221.159.70 X-Policy: $RELAYED X-ThreatScanner-Verdict: Negative IronPort-Data: A9a23:zh75Aa9pgIP2QHgt6eYoDrUDcH6TJUtcMsCJ2f8bNWPcYEJGY0x3m 2sWDGnXO/bbN2Lyfd5+PY6/8B8HuZDUmt9kSQU+rCA8E34SpcT7XtnIdU2Y0wF+jCHgZBk+s 5hBMImowOQcFCK0SsKFa+C5xZVE/fjVAOK6UKidYnwZqTZMEE8JkQhkl/MynrlmiN24BxLlk d7pqojUNUTNNwRcawr40Ird7ks01BjOkGlA5AdnPKgS5AS2e0Q9V/rzG4ngdxMUfaEMdgKKb 76r5K20+Grf4yAsBruN+losWhRXKlJ6FVHmZkt+A8BOsDAbzsAB+v9T2M4nQVVWk120c+VZk 72hg3ASpTABZcUgkMxFO/VR/roX0aduoNcrKlDn2SCfItGvn9IBDJyCAWlvVbD09NqbDklh6 PhFFwA1cyzEguStx5u7EvBXmNoaeZyD0IM34hmMzBncBPciB5vCX7/L9ZlT2zJYasJmRKiEI ZBDMHw2MUWGPEUn1lQ/UfrSmM+BgHXlfiIeg1WSvactuEDYzRBr0airO93QEjCPbZwOxh7I/ TKYpAwVBDk9P9OWkSedw06JucuRtn/nXNM9Bf6Ro6sCbFq7mTVIVUx+uUGAiem0jAuyVsxSL 2QQ+zEytu4i+UqzVN7/Uhak5nmesXY0WsFQEuwgwA7Lx6HfpRvcGm8HXzkHYddgttdebR4A2 0KNntjpLSdyq7DTQnWYnp+LqRuiNC5TKnUNDQcGUA1D5dDgqYMyixvnT9B/HarzhdrwcRnzz i6Lqm4ihrwVpc8Ny6i/u1vAhlqEupHMRxUd+gbTU2Sq/w59IoWiYuSA8lja6/9oIY2SCETEo H8His/Y5etID4nlqcCWaLxTRvfzva/DaWCNxwE3d3U8y9iz01G+ed1v0AljGABsNN0DUD+xe XTNpzoEsfe/I0CWgb9Lj5OZUpp7nfi5TYy/Bpg4ffIUPMItKlXvEDVGIB7IhT6wyiDAhIlmY c/DGftAG0r2HkiOINCebOAH2Ltj/TgkxGXcXvgXJDz8iuLBPRZ5pVofWWZij9zVD4ve+205C /4Fa6O3J+x3CYUSmBX//48JNkwtJnMmH53woME/Xrfdc1o2Rjp/VaGBmONJl2lZc0N9z7mgw 51AchYFkwSXaYPvcm1mlUyPmJuwBM0i/BrXzAQnPEqy2mhLXLtDGJw3LsNtFZF+rbwL8BKBZ 6VdEyl2KqgVG2uvFvV0RcWVkbGOgzzx1VzRZHf5MWRjF3OiLiSQkuLZksLU3HFmJkKKWQEW+ tVMCiuzrUI/ejlf IronPort-HdrOrdr: A9a23:pLFJka5eB7qgJqGoMgPXwP7XdLJyesId70hD6qm+c20zTiX+rb HXoB17726MtN91YhodcL+7VJVoLUmyyXcX2/hzAV7BZmjbUQKTRekJgLcKpQeQeREWndQy6U 4PSdkbNPTASXR8kMbm8E2ZPr8bsb+6GdiT5ds2Fk0dKD1XVw== X-Talos-CUID: 9a23:8eUugGhnWThP9kjRsK0n3O1QxDJuXWDZkUjgG1KETmNvU7q8SQeJw716qp87 X-Talos-MUID: 9a23:0jps1AbS76HDFeBTkDTjjWl/LPZUxpuKVmtRjZFXlNjHHHkl X-IronPort-AV: E=Sophos;i="6.03,269,1694750400"; d="scan'208";a="130083863" From: Andrew Cooper To: Xen-devel CC: Andrew Cooper , Reima ISHII , Jan Beulich , =?utf-8?q?Roger_Pau_Monn=C3=A9?= , Wei Liu , Jun Nakajima , Kevin Tian , Tamas K Lengyel , "Takahiro Shinagawa" Subject: [PATCH 1/2] x86/vmx: Fix IRQ handling for EXIT_REASON_INIT Date: Wed, 1 Nov 2023 19:20:57 +0000 Message-ID: <20231101192058.3419310-2-andrew.cooper3@citrix.com> X-Mailer: git-send-email 2.30.2 In-Reply-To: <20231101192058.3419310-1-andrew.cooper3@citrix.com> References: <20231101192058.3419310-1-andrew.cooper3@citrix.com> MIME-Version: 1.0 When receiving an INIT, a prior bugfix tried to ignore the INIT and continue onwards. Unfortunately it's not safe to return at that point in vmx_vmexit_handler(). Just out of context in the first hunk is a local_irqs_enabled() which is depended-upon by the return-to-guest path, causing the following checklock failure in debug builds: (XEN) Error: INIT received - ignoring (XEN) CHECKLOCK FAILURE: prev irqsafe: 0, curr irqsafe 1 (XEN) Xen BUG at common/spinlock.c:132 (XEN) ----[ Xen-4.19-unstable x86_64 debug=y Tainted: H ]---- ... (XEN) Xen call trace: (XEN) [] R check_lock+0xcd/0xe1 (XEN) [] F _spin_lock+0x1b/0x60 (XEN) [] F pt_update_irq+0x32/0x3bb (XEN) [] F vmx_intr_assist+0x3b/0x51d (XEN) [] F vmx_asm_vmexit_handler+0xf7/0x210 Luckily, this is benign in release builds. Accidentally having IRQs disabled when trying to take an IRQs-on lock isn't a deadlock-vulnerable pattern. Move the INIT handling into the main switch statement. In hindsight, it's wrong to skip other normal VMExit steps. Fixes: b1f11273d5a7 ("x86/vmx: Don't spuriously crash the domain when INIT is received") Reported-by: Reima ISHII Signed-off-by: Andrew Cooper --- CC: Jan Beulich CC: Roger Pau Monné CC: Wei Liu CC: Jun Nakajima CC: Kevin Tian CC: Tamas K Lengyel CC: Reima ISHII CC: Takahiro Shinagawa With this patch in place, the INIT is ignored and the guest continues: (XEN) HVM1 restore: CPU 0 (d1) --- Xen Test Framework --- (d1) Environment: HVM 64bit (Long mode 4 levels) (XEN) Error: INIT received - ignoring (d1) Test result: SUCCESS --- xen/arch/x86/hvm/vmx/vmx.c | 10 ++++++---- 1 file changed, 6 insertions(+), 4 deletions(-) diff --git a/xen/arch/x86/hvm/vmx/vmx.c b/xen/arch/x86/hvm/vmx/vmx.c index 1edc7f1e919f..d26920d03bbc 100644 --- a/xen/arch/x86/hvm/vmx/vmx.c +++ b/xen/arch/x86/hvm/vmx/vmx.c @@ -4097,10 +4097,6 @@ void vmx_vmexit_handler(struct cpu_user_regs *regs) case EXIT_REASON_MCE_DURING_VMENTRY: do_machine_check(regs); break; - - case EXIT_REASON_INIT: - printk(XENLOG_ERR "Error: INIT received - ignoring\n"); - return; /* Renter the guest without further processing */ } /* Now enable interrupts so it's safe to take locks. */ @@ -4390,6 +4386,12 @@ void vmx_vmexit_handler(struct cpu_user_regs *regs) case EXIT_REASON_TRIPLE_FAULT: hvm_triple_fault(); break; + + case EXIT_REASON_INIT: + /* TODO: Turn into graceful shutdown. */ + printk(XENLOG_ERR "Error: INIT received - ignoring\n"); + break; + case EXIT_REASON_PENDING_VIRT_INTR: /* Disable the interrupt window. */ v->arch.hvm.vmx.exec_control &= ~CPU_BASED_VIRTUAL_INTR_PENDING; From patchwork Wed Nov 1 19:20:58 2023 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 8bit X-Patchwork-Submitter: Andrew Cooper X-Patchwork-Id: 13443001 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 lists.xenproject.org (lists.xenproject.org [192.237.175.120]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.lore.kernel.org (Postfix) with ESMTPS id 34E85C4167D for ; Wed, 1 Nov 2023 19:21:41 +0000 (UTC) Received: from list by lists.xenproject.org with outflank-mailman.626619.977022 (Exim 4.92) (envelope-from ) id 1qyGm5-00055z-Ty; Wed, 01 Nov 2023 19:21:09 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 626619.977022; Wed, 01 Nov 2023 19:21:09 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1qyGm5-00055s-RK; Wed, 01 Nov 2023 19:21:09 +0000 Received: by outflank-mailman (input) for mailman id 626619; Wed, 01 Nov 2023 19:21:08 +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 1qyGm4-000558-Pk for xen-devel@lists.xenproject.org; Wed, 01 Nov 2023 19:21:08 +0000 Received: from esa3.hc3370-68.iphmx.com (esa3.hc3370-68.iphmx.com [216.71.145.155]) by se1-gles-flk1.inumbo.com (Halon) with ESMTPS id cc8cf3de-78eb-11ee-9b0e-b553b5be7939; Wed, 01 Nov 2023 20:21:05 +0100 (CET) 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: cc8cf3de-78eb-11ee-9b0e-b553b5be7939 DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=citrix.com; s=securemail; t=1698866465; h=from:to:cc:subject:date:message-id:in-reply-to: references:mime-version:content-transfer-encoding; bh=dAjtVuXr4bnN1ScuGLWOR+3Nub1lnq5/xnQrcyf0VXU=; b=B8J4zAhQjdhHtjHVyAMuMFwn5xTfC6gBscj10/gwkXn6sojNin7u8nLo yqSAnr1MzLx/5F7Lp/cg0pARDJ5SJ+5RxIYpGcWStev1rZnyEH2OVLGPX l4ZRDO+7zCTAkWSLgctNz7GDpXRhc/Ns/bh5I21eLgOc7s53FT7ik3zfD o=; X-CSE-ConnectionGUID: PJy6mrjzSPeeXLTAFYLeTg== X-CSE-MsgGUID: Q3wW79OkSSmHYeywlHBNNw== Authentication-Results: esa3.hc3370-68.iphmx.com; dkim=none (message not signed) header.i=none X-SBRS: 4.0 X-MesageID: 127288895 X-Ironport-Server: esa3.hc3370-68.iphmx.com X-Remote-IP: 162.221.159.70 X-Policy: $RELAYED X-ThreatScanner-Verdict: Negative IronPort-Data: A9a23:cjzQnKnDAytAOavKIVUO9u/o5gxxJkRdPkR7XQ2eYbSJt1+Wr1Gzt xIeC26EPfnfYDagc9ElYd6zpEMB6JDSmtMyQAs/qi1mEyMWpZLJC+rCIxarNUt+DCFhoGFPt JxCN4aafKjYaleG+39B55C49SEUOZmgH+e6UKicfHkpGWeIcQ954Tp7gek1n4V0ttawBgKJq LvartbWfVSowFaYCEpNg064gE0p5K+aVA8w5ARkPqkS5AaGzBH5MbpETU2PByqgKmVrNrbSq 9brlNmR4m7f9hExPdKp+p6TnpoiG+O60aCm0xK6aoD66vRwjnVaPpUTbZLwXXx/mTSR9+2d/ f0W3XCGpaXFCYWX8AgVe0Ew/yiTpsSq8pefSZS0mZT7I0Er7xIAahihZa07FdRwxwp5PY1B3 cQ6OW4IdBKRvNq7zYKfdsBCt+AuEMa+aevzulk4pd3YJfMvQJSFSKTW/95Imjw3g6iiH96HO ZBfM2A2Kk2dMlsQYj/7C7pn9AusrlD5fydVtxS+oq0v7nKI5AdwzKLsIJzefdniqcB9xxzH/ DKWrzWkav0cHOXE1gXao1WvvdTKvRL2SZ0WNJee0OE/1TV/wURMUUZLBDNXu8KRmkO4Ht5SN UEQ0i4vtrQpslymSMHnWB+1q2LCuQQTM/JRCO076RulxezZ6A3fGy0YST1Qb5ovv4k0XVQC9 HWEgtfoDjxHq6CORDSW8bL8hSy2ETgYKykFfyBsZQkY5Z/lqYI6jBPKR/5iFrK4ipv+HjSY6 zOHsik4wakShMgj1qOn8FSBiDWpzrDVRws8/S3LXWao6AxoaYrjbIutgXDA7fdGJa6URVLHo T0YnMuP66YHBtePjESwrP4lRe/zoazfaXuF3A8pQMFJGymRF2CLRaJBvjRkJlVSCssJSRvVS WHinQ5t68oGVJe1VpObc75dGuxzk/mwRY29DqqEBjZdSsIvLlPZpkmCcWbVjzi3zhV2+U0qE c7DKZ7EMJoMNUhwINNarc821qUiwmgF3XnSQ5/gp/hM+eHFPCHMIVvp3UHnUwzY0E9niF+Om zqnH5HWoyizqcWnCsUtzaYdLEoRMV8wDo3spspce4are1Q3SDF/UKGPn+N4K+SJepi5cc+Ro BmAtrJwkQek2xUr1y3RApycVF8fdckm9i9qVcDdFV2px2Iice6S0UvrTLNuJeNP3LU6nZZJo wwtJ53o7gJnFm6WpFzwrPDV8ORfSfhcrVjeYXX+PWRuI8IIqs6g0oaMQzYDPRImVkKf3fbSa ZX6vu8HafLvnzhfMfs= IronPort-HdrOrdr: A9a23:Da7T7qpVQNxya6sukAye3eQaV5odeYIsimQD101hICG9vPbo8P xG+85rrSMc6QxhIU3I/OrqBEDuex/hHPJOjrX5Xo3SPzUO2lHIEGgK1+KLqVDd8kvFh4xgPM xbHZSWZueAaWRSvILX5xS5DsZl4PTvytHPuQ6n9RdQpNhRGsRd0zs= X-Talos-CUID: 9a23:fQHlF2671YPEkamuqNsszGwFRMU/cG/m9HrdE2uEIEhYbLCpRgrF X-Talos-MUID: 9a23:3qGD/grZ5bFoSQhqmzUezwg5K/g3soOtM3sIsaQLqtaAFQZWHSjI2Q== X-IronPort-AV: E=Sophos;i="6.03,269,1694750400"; d="scan'208";a="127288895" From: Andrew Cooper To: Xen-devel CC: Andrew Cooper , Reima ISHII , Jan Beulich , =?utf-8?q?Roger_Pau_Monn=C3=A9?= , Wei Liu , Jun Nakajima , Kevin Tian , Tamas K Lengyel , "Takahiro Shinagawa" Subject: [PATCH 2/2] x86/vmx: Disallow the use of inactivity states Date: Wed, 1 Nov 2023 19:20:58 +0000 Message-ID: <20231101192058.3419310-3-andrew.cooper3@citrix.com> X-Mailer: git-send-email 2.30.2 In-Reply-To: <20231101192058.3419310-1-andrew.cooper3@citrix.com> References: <20231101192058.3419310-1-andrew.cooper3@citrix.com> MIME-Version: 1.0 Right now, vvmx will blindly copy L12's ACTIVITY_STATE into the L02 VMCS and enter the vCPU. Luckily for us, nested-virt is explicitly unsupported for security bugs. The inactivity states are HLT, SHUTDOWN and WAIT-FOR-SIPI, and as noted by the SDM in Vol3 27.7 "Special Features of VM Entry": If VM entry ends with the logical processor in an inactive activity state, the VM entry generates any special bus cycle that is normally generated when that activity state is entered from the active state. Also, Some activity states unconditionally block certain events. I.e. A VMEntry with ACTIVITY=SHUTDOWN will initiate a platform reset, while a VMEntry with ACTIVITY=WAIT-FOR-SIPI will really block everything other than SIPIs. Both of these activity states are for the TXT ACM to use, not for regular hypervisors, and Xen doesn't support dropping the HLT intercept either. There are two paths in Xen which operate on ACTIVITY_STATE. 1) The vmx_{get,set}_nonreg_state() helpers for VM-Fork. As regular VMs can't use any inactivity states, this is just duplicating the 0 from construct_vmcs(). Drop the field, leaving a comment as to why it is skipped. 2) Nested virt, because of ACTIVITY_STATE in vmcs_gstate_field[]. Explicitly hide the inactivity states in the guest's view of MSR_VMX_MISC, and remove ACTIVITY_STATE from vmcs_gstate_field[]. In virtual_vmentry(), we should trigger a VMEntry failure for the use of any inactivity states, but there's no support for that in the code at all so leave a TODO for when we finally start working on nested-virt in earnest. Reported-by: Reima ISHII Signed-off-by: Andrew Cooper Reviewed-by: Jan Beulich --- CC: Jan Beulich CC: Roger Pau Monné CC: Wei Liu CC: Jun Nakajima CC: Kevin Tian CC: Tamas K Lengyel CC: Reima ISHII CC: Takahiro Shinagawa Note, entirely untested. --- xen/arch/x86/hvm/vmx/vmx.c | 2 -- xen/arch/x86/hvm/vmx/vvmx.c | 9 +++++++-- xen/arch/x86/include/asm/hvm/hvm.h | 5 ++++- xen/arch/x86/include/asm/hvm/vmx/vmcs.h | 1 + 4 files changed, 12 insertions(+), 5 deletions(-) diff --git a/xen/arch/x86/hvm/vmx/vmx.c b/xen/arch/x86/hvm/vmx/vmx.c index d26920d03bbc..a35fb23b0ece 100644 --- a/xen/arch/x86/hvm/vmx/vmx.c +++ b/xen/arch/x86/hvm/vmx/vmx.c @@ -1543,7 +1543,6 @@ static void cf_check vmx_get_nonreg_state(struct vcpu *v, { vmx_vmcs_enter(v); - __vmread(GUEST_ACTIVITY_STATE, &nrs->vmx.activity_state); __vmread(GUEST_INTERRUPTIBILITY_INFO, &nrs->vmx.interruptibility_info); __vmread(GUEST_PENDING_DBG_EXCEPTIONS, &nrs->vmx.pending_dbg); @@ -1558,7 +1557,6 @@ static void cf_check vmx_set_nonreg_state(struct vcpu *v, { vmx_vmcs_enter(v); - __vmwrite(GUEST_ACTIVITY_STATE, nrs->vmx.activity_state); __vmwrite(GUEST_INTERRUPTIBILITY_INFO, nrs->vmx.interruptibility_info); __vmwrite(GUEST_PENDING_DBG_EXCEPTIONS, nrs->vmx.pending_dbg); diff --git a/xen/arch/x86/hvm/vmx/vvmx.c b/xen/arch/x86/hvm/vmx/vvmx.c index 16b0ef82b6c8..fd0ae3916656 100644 --- a/xen/arch/x86/hvm/vmx/vvmx.c +++ b/xen/arch/x86/hvm/vmx/vvmx.c @@ -899,7 +899,10 @@ static const u16 vmcs_gstate_field[] = { GUEST_LDTR_AR_BYTES, GUEST_TR_AR_BYTES, GUEST_INTERRUPTIBILITY_INFO, + /* + * ACTIVITY_STATE is handled specially. GUEST_ACTIVITY_STATE, + */ GUEST_SYSENTER_CS, GUEST_PREEMPTION_TIMER, /* natural */ @@ -1200,6 +1203,8 @@ static void virtual_vmentry(struct cpu_user_regs *regs) nvcpu->nv_vmentry_pending = 0; nvcpu->nv_vmswitch_in_progress = 1; + /* TODO: Fail VMentry for GUEST_ACTIVITY_STATE != 0 */ + /* * EFER handling: * hvm_set_efer won't work if CR0.PG = 1, so we change the value @@ -2316,8 +2321,8 @@ int nvmx_msr_read_intercept(unsigned int msr, u64 *msr_content) data = hvm_cr4_guest_valid_bits(d); break; case MSR_IA32_VMX_MISC: - /* Do not support CR3-target feature now */ - data = host_data & ~VMX_MISC_CR3_TARGET; + /* Do not support CR3-targets or activity states. */ + data = host_data & ~(VMX_MISC_CR3_TARGET | VMX_MISC_ACTIVITY_MASK); break; case MSR_IA32_VMX_EPT_VPID_CAP: data = nept_get_ept_vpid_cap(); diff --git a/xen/arch/x86/include/asm/hvm/hvm.h b/xen/arch/x86/include/asm/hvm/hvm.h index 6d53713fc3a9..caeb8ef4f596 100644 --- a/xen/arch/x86/include/asm/hvm/hvm.h +++ b/xen/arch/x86/include/asm/hvm/hvm.h @@ -78,7 +78,10 @@ enum hvm_intblk { struct hvm_vcpu_nonreg_state { union { struct { - uint64_t activity_state; + /* + * ACTIVITY_STATE is part of VT-x's Non-Register state, but we + * don't support the use of any inactivity states. + */ uint64_t interruptibility_info; uint64_t pending_dbg; uint64_t interrupt_status; diff --git a/xen/arch/x86/include/asm/hvm/vmx/vmcs.h b/xen/arch/x86/include/asm/hvm/vmx/vmcs.h index d07fcb2bc929..8de9977eb354 100644 --- a/xen/arch/x86/include/asm/hvm/vmx/vmcs.h +++ b/xen/arch/x86/include/asm/hvm/vmx/vmcs.h @@ -277,6 +277,7 @@ extern u32 vmx_secondary_exec_control; #define VMX_VPID_INVVPID_SINGLE_CONTEXT_RETAINING_GLOBAL 0x80000000000ULL extern u64 vmx_ept_vpid_cap; +#define VMX_MISC_ACTIVITY_MASK 0x000001c0 #define VMX_MISC_PROC_TRACE 0x00004000 #define VMX_MISC_CR3_TARGET 0x01ff0000 #define VMX_MISC_VMWRITE_ALL 0x20000000