Re: [PATCH 6/7] target/i386: add VMX features

[Paolo Bonzini]

On 19/09/19 16:32, Liran Alon wrote:
> 
> 
>> On 17 Sep 2019, at 13:34, Paolo Bonzini <address@hidden> wrote:
>>
>> Add code to convert the VMX feature words back into MSR values,
>> allowing the user to enable/disable VMX features as they wish.  The same
>> infrastructure enables support for limiting VMX features in named
>> CPU models.
>>
>> Signed-off-by: Paolo Bonzini <address@hidden>
>> ---
>> +static uint64_t make_vmx_msr_value(uint32_t index, uint32_t features)
>> +{
>> +    uint32_t default1, can_be_one, can_be_zero;
>> +    uint32_t must_be_one;
>> +
>> +    switch (index) {
>> +    case MSR_IA32_VMX_TRUE_PINBASED_CTLS:
>> +        default1 = 0x00000016;
>> +        break;
>> +    case MSR_IA32_VMX_TRUE_PROCBASED_CTLS:
>> +        default1 = 0x0401e172;
>> +        break;
>> +    case MSR_IA32_VMX_TRUE_ENTRY_CTLS:
>> +        default1 = 0x000011ff;
>> +        break;
>> +    case MSR_IA32_VMX_TRUE_EXIT_CTLS:
>> +        default1 = 0x00036dff;
>> +        break;
>> +    case MSR_IA32_VMX_PROCBASED_CTLS2:
>> +        default1 = 0;
>> +        break;
>> +    default:
>> +        abort();
>> +    }
>> +
> 
> See below.
> 
>> +    /*
>> +     * Bits 0-30, 32-44 and 50-53 come from the host.  KVM should
>> +     * not change them for backwards compatibility.
>> +     */
>> +    uint64_t fixed_vmx_basic = kvm_vmx_basic & 0x003c1fff7fffffffULL;
>> +
>> +    /*
>> +     * Same for bits 0-4 and 25-27.  Bits 16-24 (CR3 target count) can
>> +     * change in the future but are always zero for now, clear them to be
>> +     * future proof.  Bits 32-63 in theory could change, though KVM does
>> +     * not support dual-monitor treatment and probably never will; mask
>> +     * them out as well.
>> +     */
>> +    uint64_t fixed_vmx_misc = kvm_vmx_misc & 0x0e00001f;
> 
> I haven’t yet read deeply entire patch-series but I’m definitely against 
> having
> these hard-coded values in code instead of explicitly building proper bitmap
> with well-defined bit names. This is error-prone and less readable.
> (E.g. Am I suppose as a reader to convert 0x0401e172 to which processor-based 
> controls it represents?)

No, you're not. :)  In fact, most of the bits that are set in these
constants have no definition.  Most "default1" reserved bits have
remained reserved since forever, the only exceptions are DEBUGCTL and
CR3 load/store controls.

The hex constants here correspond simply to the bits that are listed in
appendix A of the SDM:

  Default settings partition the various controls into the following
  classes:
  [...]
  * Default1. They are (or have been) reserved with a default
    setting of 1.
  [...]
  The default1 class of pin-based VM-execution controls contains bits 1,
  2, and 4
  [...]
  The default1 class of processor-based VM-execution controls contains
  bits 1, 4–6, 8, 13–16, and 26
  [...]
  The default1 class of VM-exit controls contains bits 0–8, 10, 11, 13,
  14, 16, and 17
  [...]
  The default1 class of VM-entry controls contains bits 0–8 and 12

I could add four #defines for these values, but they are used only here
and shouldn't be used elsewhere since make_vmx_msr_value is there
exactly to hide the existence of default1 reserved bits.

I will add defines for fixed_vmx_basic, fixed_vmx_misc and
fixed_vmx_ept_mask, though.

Paolo