Currently, the following sequence of actions:
* VMPTRLD (creates a mapping, likely pointing at gfn 0 for an empty vmcs)
* VMWRITE CPU_BASED_VM_EXEC_CONTROL (completed by hardware)
* VMWRITE MSR_BITMAP (completed by hardware)
* VMLAUNCH
results in an L2 guest running with ACTIVATE_MSR_BITMAP set, but Xen using a
stale mapping (likely gfn 0) when reading the interception bitmap. The
MSR_BITMAP field needs unconditionally intercepting even with VMCS shadowing,
so Xen's mapping of the bitmap can be updated.
Signed-off-by: Andrew Cooper <andrew.coop...@citrix.com>
---
CC: Jan Beulich <jbeul...@suse.com>
CC: Jun Nakajima <jun.nakaj...@intel.com>
CC: Kevin Tian <kevin.t...@intel.com>
---
xen/arch/x86/hvm/vmx/vvmx.c | 4 +++-
1 file changed, 3 insertions(+), 1 deletion(-)
diff --git a/xen/arch/x86/hvm/vmx/vvmx.c b/xen/arch/x86/hvm/vmx/vvmx.c
index 0d08789..f84478e 100644
--- a/xen/arch/x86/hvm/vmx/vvmx.c
+++ b/xen/arch/x86/hvm/vmx/vvmx.c
@@ -98,13 +98,15 @@ int nvmx_vcpu_initialise(struct vcpu *v)
clear_page(vw);
/*
- * For the following 4 encodings, we need to handle them in VMM.
+ * For the following 6 encodings, we need to handle them in VMM.
* Let them vmexit as usual.
*/
set_bit(IO_BITMAP_A, vw);
set_bit(VMCS_HIGH(IO_BITMAP_A), vw);
set_bit(IO_BITMAP_B, vw);
set_bit(VMCS_HIGH(IO_BITMAP_B), vw);
+ set_bit(MSR_BITMAP, vw);
+ set_bit(VMCS_HIGH(MSR_BITMAP), vw);
unmap_domain_page(vw);
}
--
2.1.4
_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
https://lists.xen.org/xen-devel
