+ if (f[FEAT_7_1_EAX] & CPUID_7_1_EAX_FRED) { + /* FRED injected-event data (0x2052). */ + kvm_msr_entry_add(cpu, MSR_IA32_VMX_VMCS_ENUM, 0x52);HMM, I have the questions when I check the FRED spec. Section 9.3.4 said, (for injected-event data) "This field has uses the encoding pair 2052H/2053H." So why adjust the highest index to 0x52 other than 0x53?
For 16-bit, 32-bit, and natural-width fields, they must be read/write as a whole, thus the lowest bit of their encoding must be 0. A 64-bit VMCS field can be accessed as two 32-bit fields, with the higher order half using an odd VMCS encoding. But conceptually they should be treated as a whole 64-bit field. Better to refer to Intel SDM 25.11.2 VMREAD, VMWRITE, and Encodings of VMCS Fields.
And it seems FRED introduces another field "original-event data" (0x2404/0x2405), why not consider this field here as well?+ } else if (f[FEAT_VMX_EXIT_CTLS] & + VMX_VM_EXIT_ACTIVATE_SECONDARY_CONTROLS) { + /* Secondary VM-exit controls (0x2044). */ + kvm_msr_entry_add(cpu, MSR_IA32_VMX_VMCS_ENUM, 0x44); + } else if (f[FEAT_VMX_SECONDARY_CTLS] & VMX_SECONDARY_EXEC_TSC_SCALING) { /* TSC multiplier (0x2032). */ kvm_msr_entry_add(cpu, MSR_IA32_VMX_VMCS_ENUM, 0x32); } else {Maybe we could adjust the index in a cleaner way like x86_cpu_adjust_level(), but the current case-by-case is ok for me as well.
Yeah, that sounds a good idea. But the code hasn't gone wild...
