While generally benign, doing so is still at best misleading. Signed-off-by: Jan Beulich <jbeul...@suse.com> --- 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 )