On 25/05/2018 08:27, Jan Beulich wrote: >>>> On 24.05.18 at 18:48, <andrew.coop...@citrix.com> wrote: >> On 24/05/18 17:01, Roger Pau Monné wrote: >>> On Tue, May 22, 2018 at 12:20:46PM +0100, Andrew Cooper wrote: >>>> --- a/xen/include/asm-x86/hvm/vmx/vmcs.h >>>> +++ b/xen/include/asm-x86/hvm/vmx/vmcs.h >>>> @@ -306,6 +306,8 @@ extern u64 vmx_ept_vpid_cap; >>>> (vmx_cpu_based_exec_control & CPU_BASED_MONITOR_TRAP_FLAG) >>>> #define cpu_has_vmx_pat \ >>>> (vmx_vmentry_control & VM_ENTRY_LOAD_GUEST_PAT) >>>> +#define cpu_has_vmx_efer \ >>>> + (vmx_vmentry_control & VM_ENTRY_LOAD_GUEST_EFER) >>> Don't you also need a vmx_vmexit_control & VM_EXIT_SAVE_GUEST_EFER and >>> vmx_vmexit_control & VM_EXIT_LOAD_HOST_EFER? >>> >>> Or can the presence of those two be inferred from >>> VM_ENTRY_LOAD_GUEST_EFER? >> They were introduced at the same time into hardware, so these settings >> will be the same in practice. > I see other similar groups of features also aren't checked for consistency, > but wouldn't it be better to have such checks in vmx_init_vmcs_config() > (i.e. disable all three if at least one of them is unavailable)?
Correct. Logic to this effect is coming as part of Nested Virt work. ~Andrew _______________________________________________ Xen-devel mailing list Xen-devel@lists.xenproject.org https://lists.xenproject.org/mailman/listinfo/xen-devel
