While generally benign, doing so is still at best misleading.
Signed-off-by: Jan Beulich <[email protected]>
---
Using set_in_cr4() seems favorable over updating mmu_cr4_features
despite the resulting redundant CR4 update. But I certainly could be
talked into going the alternative route.
---
v2: Actually clear CR4.VMXE for the BSP on the error path.
--- a/xen/arch/x86/hvm/vmx/vmx.c
+++ b/xen/arch/x86/hvm/vmx/vmx.c
@@ -2959,14 +2959,18 @@ static bool __init has_if_pschange_mc(vo
const struct hvm_function_table * __init start_vmx(void)
{
- set_in_cr4(X86_CR4_VMXE);
+ write_cr4(read_cr4() | X86_CR4_VMXE);
if ( vmx_vmcs_init() )
{
+ write_cr4(read_cr4() & ~X86_CR4_VMXE);
printk("VMX: failed to initialise.\n");
return NULL;
}
+ /* Arrange for APs to have CR4.VMXE set early on. */
+ set_in_cr4(X86_CR4_VMXE);
+
vmx_function_table.singlestep_supported = cpu_has_monitor_trap_flag;
if ( cpu_has_vmx_dt_exiting )