Re: [PATCH v1 3/3] target/i386: Raise the highest index value used for any VMCS encoding

[Xin Li]

> > +    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...