From nobody Mon Jun 8 09:48:37 2026 Received: from mail-pl1-f202.google.com (mail-pl1-f202.google.com [209.85.214.202]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id 341AB4D90A6 for ; Wed, 3 Jun 2026 22:34:23 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=209.85.214.202 ARC-Seal: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1780526068; cv=none; b=JAyT3R+eFZkVwX/Q1gBM4I7a+KKmlgSyHNiFI5EHJ6PeX+HBoO1zxpVBByl75mibhGSBSzvtzwnq94EfCUw8BtWlO6M08y5nbKovV2buMgpFl1mZoRjooQeEytHOIan/pPHfFuZbQeRY+ymRChoqKAyhpDzciR+BUCp7b2XrDZ0= ARC-Message-Signature: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1780526068; c=relaxed/simple; bh=bYjWQS9V5yKNsX/qamnnBTvmDwesC5dEoAweBDT6DRM=; h=Date:In-Reply-To:Mime-Version:References:Message-ID:Subject:From: To:Cc:Content-Type; b=e9TgM/G/S3pqej3CypisQTkvc1r6P03i8JbQtgFzXXUHRRhkK7CZoQ5IEtrNdCbZAXwbAuWAtb55axwY5cmUb3mcOFKkRPeXFGK442SC//qlfMTJOZ76KKpZfK0j33Dbjepci/mRBTilPOppO4XhZsEVuidK6Bo46XSTiEJQtkQ= ARC-Authentication-Results: i=1; smtp.subspace.kernel.org; dmarc=pass (p=reject dis=none) header.from=google.com; spf=pass smtp.mailfrom=flex--seanjc.bounces.google.com; dkim=pass (2048-bit key) header.d=google.com header.i=@google.com header.b=WwJgKtJh; arc=none smtp.client-ip=209.85.214.202 Authentication-Results: smtp.subspace.kernel.org; dmarc=pass (p=reject dis=none) header.from=google.com Authentication-Results: smtp.subspace.kernel.org; spf=pass smtp.mailfrom=flex--seanjc.bounces.google.com Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=google.com header.i=@google.com header.b="WwJgKtJh" Received: by mail-pl1-f202.google.com with SMTP id d9443c01a7336-2bf160f7191so329565ad.3 for ; Wed, 03 Jun 2026 15:34:22 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20251104; t=1780526062; x=1781130862; darn=vger.kernel.org; h=cc:to:from:subject:message-id:references:mime-version:in-reply-to :date:reply-to:from:to:cc:subject:date:message-id:reply-to; bh=lvvRiUJMqyN5FyY9xvvNaMRd83EfYY0souJYEsNdbNo=; b=WwJgKtJhQF0DV4SkG74nuI28GM2GfrzDFYY0PMWDUT3XZ9fFkgWrOZDrF0tVFLTNj1 26zvjzubG96TihhtsowmkqgOa66RKnoxzDfXFM358XRCLlxGjIatNQfghF6liGLJ5L05 yVJTKfSwE7GjRHOWOdRvrJ/y7rYeBTknOnYlSj4eN7+pbHqnvoMmAutq7KzRR+6MyXVp 0lMU1GCWjjwq28/dJo0FaIMbEImofbjqwh3CyBf2pkDw/PL2G4qO+V3nD0VzT3HzzlEx MMTKefBhTiezwzUGvBKYcz0f/9M0hJlriwuNJ4Q6//2uPZaQDN7pHC2PuFiMJTQdsBgq tCjg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20251104; t=1780526062; x=1781130862; h=cc:to:from:subject:message-id:references:mime-version:in-reply-to :date:reply-to:x-gm-message-state:from:to:cc:subject:date:message-id :reply-to; bh=lvvRiUJMqyN5FyY9xvvNaMRd83EfYY0souJYEsNdbNo=; b=H3JzmTW2JMbRNAOwCiLM3rf/5HHvaF939t8i0ZZHV2PTdDHg9MOwroi3hMXnX/siOk sAZjyXNf4ypKXIpo0fP0Pnxsx/1nyE/iWC00WIoBQNnTLQ9oJKvuGnY8dv75ltZRqQxK L//Ki6IdSiCblIKPXntsvATYSgYe8etJc16sTbyK5e4F6F5jJhjD//ahfeNJFbF/lAnu js4zrvpLubwCxu8tGYiPfgYmv0tWvTzEcLOthGL/FUBKYotQbaH/2B5G1Cy+jleiLdP7 P9VR9j601DtA0tXMX5qyyqEh4DZkSy5hqC09c27fa5mln7dcRT2yQWryf2tSwJkLCMec EDuw== X-Forwarded-Encrypted: i=1; AFNElJ/Aauufu7d3k1gqXOoksKf/fOGVAqSRH6b9Op4rhdpYCHfWiE1femGzSBj/H839fRdvX/SbWumIUsCjJRE=@vger.kernel.org X-Gm-Message-State: AOJu0Yw5zdCp2myZVL25tBFG5mfhLuXwtNMCYm5KQMUzvFpiZkbkvxSk Sc7m17UhHv4LgnnhWilq0Z/TnNRaGlsHcP3byw9z2IgD5D42ozOxoyV7tf4iDuZe4zI2xXfsD1Y +Rb5iNQ== X-Received: from plbkt11.prod.google.com ([2002:a17:903:88b:b0:2bf:27ab:9cf4]) (user=seanjc job=prod-delivery.src-stubby-dispatcher) by 2002:a17:903:37cf:b0:2c1:ef9:4516 with SMTP id d9443c01a7336-2c1641b0f33mr56917885ad.35.1780526061843; Wed, 03 Jun 2026 15:34:21 -0700 (PDT) Reply-To: Sean Christopherson Date: Wed, 3 Jun 2026 15:34:17 -0700 In-Reply-To: <20260603223418.1720035-1-seanjc@google.com> Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: Mime-Version: 1.0 References: <20260603223418.1720035-1-seanjc@google.com> X-Mailer: git-send-email 2.54.0.1032.g2f8565e1d1-goog Message-ID: <20260603223418.1720035-2-seanjc@google.com> Subject: [PATCH 1/2] KVM: nVMX: Move vTPR vs. TPR Threshold consistency check into "normal" checks From: Sean Christopherson To: Sean Christopherson , Paolo Bonzini Cc: kvm@vger.kernel.org, linux-kernel@vger.kernel.org, Jim Mattson Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="utf-8" Move the off-by-default consistency check for vmcs12.tpr_threshold vs. the virtual APIC vTPR into the "normal" controls checks, as waiting until KVM has loaded some amount of state is unnecessary and actively dangerous. Specifically, failure to unwind vmcs01.GUEST_CR3 to KVM's value when EPT is disabled results in KVM running L1 with an L1-controlled CR3, not with KVM's CR3! Alternatively, KVM could simply reset the MMU to force a reload of vmcs01.GUEST_CR3, but the _only_ reason the check was shoved into a "late" flow was to wait until the vmcs12 pages were retrieved. Rather than build up more crusty code, simply access vTPR using a regular guest memory access (performance isn't a concern). To circumvent the restrictions that led to KVM deferring nested_get_vmcs12_pages(), (a) use a VM-scoped API to read guest memory so that it always hits non-SMM memslots (for RSM), and (b) skip the check (since its off-by-default anyways) when the vCPU doesn't want to run, i.e. when userspace is restoring/stuffing state. Fixes: 1100e4910ad2 ("KVM: nVMX: Add an off-by-default module param to WARN= on missed consistency checks") Cc: stable@vger.kernel.org Signed-off-by: Sean Christopherson --- arch/x86/kvm/vmx/nested.c | 65 +++++++++++++++++---------------------- 1 file changed, 28 insertions(+), 37 deletions(-) diff --git a/arch/x86/kvm/vmx/nested.c b/arch/x86/kvm/vmx/nested.c index b2c851cc7d5c..039e234e7d2b 100644 --- a/arch/x86/kvm/vmx/nested.c +++ b/arch/x86/kvm/vmx/nested.c @@ -582,6 +582,8 @@ static int nested_vmx_check_msr_bitmap_controls(struct = kvm_vcpu *vcpu, static int nested_vmx_check_tpr_shadow_controls(struct kvm_vcpu *vcpu, struct vmcs12 *vmcs12) { + u32 vtpr; + if (!nested_cpu_has(vmcs12, CPU_BASED_TPR_SHADOW)) return 0; =20 @@ -591,6 +593,32 @@ static int nested_vmx_check_tpr_shadow_controls(struct= kvm_vcpu *vcpu, if (CC(!nested_cpu_has_vid(vmcs12) && vmcs12->tpr_threshold >> 4)) return -EINVAL; =20 + /* + * Do the illegal vTPR vs. TPR Threshold consistency check if and only + * if KVM is configured to WARN on missed consistency checks, otherwise + * it's a waste of time. KVM needs to rely on hardware to fully detect + * an illegal combination due to the vTPR being writable by L1 at all + * times (it's an in-memory value, not a VMCS field). I.e. even if the + * check passes now, it might fail at the actual VM-Enter. + * + * Keying off the module param also allows treating an invalid vAPIC + * page as a consistency check failure without increasing the risk of + * breaking a "real" VM. + * + * Note! Deliberately use the VM-scoped API when reading guest memory, + * to ensure the read doesn't hit SMRAM when restoring L2 state on RSM, + * and only perform the check when in KVM_RUN, to avoid a false failure + * if userspace hasn't yet configured memslots during state restore. + */ + if (warn_on_missed_cc && vcpu->wants_to_run && + nested_cpu_has(vmcs12, CPU_BASED_TPR_SHADOW) && + !nested_cpu_has_vid(vmcs12) && + !nested_cpu_has2(vmcs12, SECONDARY_EXEC_VIRTUALIZE_APIC_ACCESSES) && + (CC(kvm_read_guest(vcpu->kvm, vmcs12->virtual_apic_page_addr + APIC_T= ASKPRI, + &vtpr, sizeof(vtpr))) || + CC((vmcs12->tpr_threshold & GENMASK(3, 0)) > ((vtpr >> 4) & GENMASK(= 3, 0))))) + return -EINVAL; + return 0; } =20 @@ -3115,38 +3143,6 @@ static int nested_vmx_check_controls(struct kvm_vcpu= *vcpu, return 0; } =20 -static int nested_vmx_check_controls_late(struct kvm_vcpu *vcpu, - struct vmcs12 *vmcs12) -{ - void *vapic =3D to_vmx(vcpu)->nested.virtual_apic_map.hva; - u32 vtpr =3D vapic ? (*(u32 *)(vapic + APIC_TASKPRI)) >> 4 : 0; - - /* - * Don't bother with the consistency checks if KVM isn't configured to - * WARN on missed consistency checks, as KVM needs to rely on hardware - * to fully detect an illegal vTPR vs. TRP Threshold combination due to - * the vTPR being writable by L1 at all times (it's an in-memory value, - * not a VMCS field). I.e. even if the check passes now, it might fail - * at the actual VM-Enter. - * - * Keying off the module param also allows treating an invalid vAPIC - * mapping as a consistency check failure without increasing the risk - * of breaking a "real" VM. - */ - if (!warn_on_missed_cc) - return 0; - - if ((exec_controls_get(to_vmx(vcpu)) & CPU_BASED_TPR_SHADOW) && - nested_cpu_has(vmcs12, CPU_BASED_TPR_SHADOW) && - !nested_cpu_has_vid(vmcs12) && - !nested_cpu_has2(vmcs12, SECONDARY_EXEC_VIRTUALIZE_APIC_ACCESSES) && - (CC(!vapic) || - CC((vmcs12->tpr_threshold & GENMASK(3, 0)) > (vtpr & GENMASK(3, 0)))= )) - return -EINVAL; - - return 0; -} - static int nested_vmx_check_address_space_size(struct kvm_vcpu *vcpu, struct vmcs12 *vmcs12) { @@ -3696,11 +3692,6 @@ enum nvmx_vmentry_status nested_vmx_enter_non_root_m= ode(struct kvm_vcpu *vcpu, return NVMX_VMENTRY_KVM_INTERNAL_ERROR; } =20 - if (nested_vmx_check_controls_late(vcpu, vmcs12)) { - vmx_switch_vmcs(vcpu, &vmx->vmcs01); - return NVMX_VMENTRY_VMFAIL; - } - if (nested_vmx_check_guest_state(vcpu, vmcs12, &entry_failure_code)) { exit_reason.basic =3D EXIT_REASON_INVALID_STATE; --=20 2.54.0.1032.g2f8565e1d1-goog From nobody Mon Jun 8 09:48:37 2026 Received: from mail-pf1-f202.google.com (mail-pf1-f202.google.com [209.85.210.202]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id 592354D8DB1 for ; Wed, 3 Jun 2026 22:34:24 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=209.85.210.202 ARC-Seal: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1780526067; cv=none; b=i+tQS7d2J3g22v/cOaWditaQbr7idS2UI0Lfu1Mfs0KpWsAU5+eYtMagKEkfiB+95ww6xZPxh87yiIA6rK65vabFwQVOYV9tt63TXPH+H3XHDl/KZmnD0lsxUOfn7MyMsbQfbvQykDT/egTTC2IxISF8+1sxRA2d8mkzLL0VbwY= ARC-Message-Signature: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1780526067; c=relaxed/simple; bh=KtdlDyfbm3TdN3Bu5jvCzKeLtKQzA5ao31bl8Pxom84=; h=Date:In-Reply-To:Mime-Version:References:Message-ID:Subject:From: To:Cc:Content-Type; b=srhAQBXN19bg0FPsy1x4+2h7dSIqdoLOaJT+HRNyFbjyMXYlsMTWdCQ5+GltwI/PsbD29abzCRW4dI0RYJNjTkBV8nI5IP7Qknoyl4k5CnGgetHkaFQc+chukRzrYNwWSI8j9c91vdw/vDuVy4dxLJVNJHdnPhaaX8O2Y71Oc+E= ARC-Authentication-Results: i=1; smtp.subspace.kernel.org; dmarc=pass (p=reject dis=none) header.from=google.com; spf=pass smtp.mailfrom=flex--seanjc.bounces.google.com; dkim=pass (2048-bit key) header.d=google.com header.i=@google.com header.b=tyvlDC+Y; arc=none smtp.client-ip=209.85.210.202 Authentication-Results: smtp.subspace.kernel.org; dmarc=pass (p=reject dis=none) header.from=google.com Authentication-Results: smtp.subspace.kernel.org; spf=pass smtp.mailfrom=flex--seanjc.bounces.google.com Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=google.com header.i=@google.com header.b="tyvlDC+Y" Received: by mail-pf1-f202.google.com with SMTP id d2e1a72fcca58-8421ffff8a3so58958b3a.2 for ; Wed, 03 Jun 2026 15:34:24 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20251104; t=1780526063; x=1781130863; darn=vger.kernel.org; h=cc:to:from:subject:message-id:references:mime-version:in-reply-to :date:reply-to:from:to:cc:subject:date:message-id:reply-to; bh=YT22xFPe+uvBINsx4QHwFFDf4DhD63vVETjx/ZAWt2E=; b=tyvlDC+Y99qjHpEnqftZV/RRwHqb8Q9tEauYZvCGXZzV17cGV7f0HOatReGEsRGUNm gEZxmwcsxQyhnwKWsBgQRO1iBk4RkEV4KW/MpGu5Srolxl/5huAkzLkhgU7MNIIAgcXL OCmzamR2LHvzmdxkwoErfXIT3IAgvSOzOdb0rGdncLiUIeju5/IVcbLue1022R7B3HnW 599Z5fsRgqr36q74aD0Vl6xq8JcmkWmfbjHFaUAVXBMx0vPo7HmWK/V67vi1g3mRn9j3 o5TybdGV9snAgIlQostN4TYsTPQhKBNvWrC7DUAAUyq2yfKSGHD5bSHk0Xa6m0fZxVTy hvKA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20251104; t=1780526063; x=1781130863; h=cc:to:from:subject:message-id:references:mime-version:in-reply-to :date:reply-to:x-gm-message-state:from:to:cc:subject:date:message-id :reply-to; bh=YT22xFPe+uvBINsx4QHwFFDf4DhD63vVETjx/ZAWt2E=; b=JpjEG7a3HsMO7Vgay8WEUtoj8j38QLCF8qYvmtKEqSPOTQAiVvgRAjYQyb+A6NFgmX t80DAzWt74MdZmPg9MUZV8ENw2+ekDH3oOjx/2NlsAIl7yauDZUxCJ/6qZePTwPOPHcK Hups3OckHjJHQCx46RLNpNVRjbA2uzBiJifQ0y+4PJIAqG16g2vfv1B6L7W4m/Q7dx5n 2jKBIi6Hhw1VjRlmG4M0F+2C2ZDzepsuc+qXQmyW83MPTF8X7bVJ3YHYvcj48OyoYc0W 45aJQqUWBMR5O6iTjsG7LfsZDe5IJEBQlrSr+NOHMB0KEnxeQYh8jVySQjkOqC6/lOpr xW8w== X-Forwarded-Encrypted: i=1; AFNElJ9xSWf3lSWWG5JRC27G52Z/zyPbBLGFyBWZbWvF8JvIIr/PvfW/ehX9ZQukJukAsoXvlsTAOiT/B5y/3C0=@vger.kernel.org X-Gm-Message-State: AOJu0YxDDL7ELgtJDdkYnqDWPpMLPDocYX8W12l1Rsx4L1WMNbdxLgjX eTlC2s00y3Uns97aBEPU2JWIk0Z41FbdfwYoUe0Aew2YozbwydRdDrFwB0g0APtjMt+cVJVSE5n 12X9mwg== X-Received: from pfm4.prod.google.com ([2002:a05:6a00:724:b0:842:2c74:b8ce]) (user=seanjc job=prod-delivery.src-stubby-dispatcher) by 2002:a05:6a00:b483:b0:842:2ddb:e303 with SMTP id d2e1a72fcca58-84284da5a08mr5238397b3a.12.1780526063099; Wed, 03 Jun 2026 15:34:23 -0700 (PDT) Reply-To: Sean Christopherson Date: Wed, 3 Jun 2026 15:34:18 -0700 In-Reply-To: <20260603223418.1720035-1-seanjc@google.com> Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: Mime-Version: 1.0 References: <20260603223418.1720035-1-seanjc@google.com> X-Mailer: git-send-email 2.54.0.1032.g2f8565e1d1-goog Message-ID: <20260603223418.1720035-3-seanjc@google.com> Subject: [PATCH 2/2] KVM: nVMX: Don't use vmcs01.GUEST_CR3 to snapshot L1's CR3 when EPT is disabled From: Sean Christopherson To: Sean Christopherson , Paolo Bonzini Cc: kvm@vger.kernel.org, linux-kernel@vger.kernel.org, Jim Mattson Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="utf-8" Add a dedicated field in "struct nested_vmx" to track L1's pre-VM-Enter CR3 instead of using vmcs01.GUEST_CR3, which isn't anywhere near as safe as the comment purports it to be. E.g. in addition to the warn_on_missed_cc bug (that was fixed by relocating the consistency check), if getting vmcs12 pages (during actual nested VM-Entry) fails and EPT is disabled (in KVM), KVM will return control to userspace with vmcs01.GUEST_CR3 holding a guest- controlled value. Alternatively, KVM could force a reload of vmcs01.GUEST_CR3 by resetting the MMU context in the error path, but as above, the safety of the vmcs01 approach is extremely questionable, e.g. it took all of ~4 months for the code to break. Fixes: 671ddc700fd0 ("KVM: nVMX: Don't leak L1 MMIO regions to L2") Cc: stable@vger.kernel.org Cc: Jim Mattson Signed-off-by: Sean Christopherson --- arch/x86/kvm/vmx/nested.c | 21 ++++++++------------- arch/x86/kvm/vmx/vmx.h | 7 +++++++ 2 files changed, 15 insertions(+), 13 deletions(-) diff --git a/arch/x86/kvm/vmx/nested.c b/arch/x86/kvm/vmx/nested.c index 039e234e7d2b..772b8090d06a 100644 --- a/arch/x86/kvm/vmx/nested.c +++ b/arch/x86/kvm/vmx/nested.c @@ -3668,19 +3668,14 @@ enum nvmx_vmentry_status nested_vmx_enter_non_root_= mode(struct kvm_vcpu *vcpu, &vmx->nested.pre_vmenter_ssp_tbl); =20 /* - * Overwrite vmcs01.GUEST_CR3 with L1's CR3 if EPT is disabled. In the - * event of a "late" VM-Fail, i.e. a VM-Fail detected by hardware but - * not KVM, KVM must unwind its software model to the pre-VM-Entry host - * state. When EPT is disabled, GUEST_CR3 holds KVM's shadow CR3, not - * L1's "real" CR3, which causes nested_vmx_restore_host_state() to - * corrupt vcpu->arch.cr3. Stuffing vmcs01.GUEST_CR3 results in the - * unwind naturally setting arch.cr3 to the correct value. Smashing - * vmcs01.GUEST_CR3 is safe because nested VM-Exits, and the unwind, - * reset KVM's MMU, i.e. vmcs01.GUEST_CR3 is guaranteed to be - * overwritten with a shadow CR3 prior to re-entering L1. + * Stash L1's CR3, so that in the event of a "late" VM-Fail, i.e. a + * VM-Fail detected by hardware but not KVM, KVM can unwind its + * software model to the pre-VM-Entry host state. When EPT is + * disabled, GUEST_CR3 holds KVM's shadow CR3, not L1's "real" CR3, + * and so simply restoring from vmcs01.GUEST_CR3 would corrupt + * vcpu->arch.cr3. */ - if (!enable_ept) - vmcs_writel(GUEST_CR3, vcpu->arch.cr3); + vmx->nested.pre_vmenter_cr3 =3D vcpu->arch.cr3; =20 vmx_switch_vmcs(vcpu, &vmx->nested.vmcs02); =20 @@ -4992,7 +4987,7 @@ static void nested_vmx_restore_host_state(struct kvm_= vcpu *vcpu) vmx_set_cr4(vcpu, vmcs_readl(CR4_READ_SHADOW)); =20 nested_ept_uninit_mmu_context(vcpu); - vcpu->arch.cr3 =3D vmcs_readl(GUEST_CR3); + vcpu->arch.cr3 =3D vmx->nested.pre_vmenter_cr3; kvm_register_mark_available(vcpu, VCPU_REG_CR3); =20 /* diff --git a/arch/x86/kvm/vmx/vmx.h b/arch/x86/kvm/vmx/vmx.h index de9de0d2016c..dc8517f15bc4 100644 --- a/arch/x86/kvm/vmx/vmx.h +++ b/arch/x86/kvm/vmx/vmx.h @@ -159,6 +159,13 @@ struct nested_vmx { bool has_preemption_timer_deadline; bool preemption_timer_expired; =20 + /* + * Used to restore L1's CR3 if hardware detects a VM-Fail Consistency + * Check that KVM does not, in which case KVM needs to unwind CR3 back + * to its pre-VM-Enter state, NOT to vmcs01.HOST_CR3. + */ + unsigned long pre_vmenter_cr3; + /* * Used to snapshot MSRs that are conditionally loaded on VM-Enter in * order to propagate the guest's pre-VM-Enter value into vmcs02. For --=20 2.54.0.1032.g2f8565e1d1-goog