On 19/09/19 16:32, Liran Alon wrote:
>
>
>> On 17 Sep 2019, at 13:34, Paolo Bonzini <pbonz...@redhat.com> 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 <pbonz...@redhat.com>
>> ---
>> +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
