From: Paolo Bonzini <pbonzini@redhat.com>
To: Liran Alon <liran.alon@oracle.com>
Cc: qemu-devel@nongnu.org, ehabkost@redhat.com
Subject: Re: [PATCH 6/7] target/i386: add VMX features
Date: Thu, 19 Sep 2019 16:54:36 +0200 [thread overview]
Message-ID: <60820b32-42df-dbc0-9fc7-81821b2e42cb@redhat.com> (raw)
In-Reply-To: <A0C3DD36-966F-46CC-8705-903112BECBC2@oracle.com>
On 19/09/19 16:32, Liran Alon wrote:
>
>
>> On 17 Sep 2019, at 13:34, Paolo Bonzini <pbonzini@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 <pbonzini@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
next prev parent reply other threads:[~2019-09-19 15:02 UTC|newest]
Thread overview: 12+ messages / expand[flat|nested] mbox.gz Atom feed top
2019-09-17 10:34 [Qemu-devel] [PATCH v2 0/7] target/i386: support VMX features in "-cpu" Paolo Bonzini
2019-09-17 10:34 ` [Qemu-devel] [PATCH 1/7] target/i386: handle filtered_features in a new function mark_unavailable_features Paolo Bonzini
2019-09-17 10:34 ` [Qemu-devel] [PATCH 2/7] target/i386: introduce generic feature dependency mechanism Paolo Bonzini
2019-09-17 10:34 ` [Qemu-devel] [PATCH 3/7] target/i386: expand feature words to 64 bits Paolo Bonzini
2019-09-17 10:34 ` [Qemu-devel] [PATCH 4/7] target/i386: add VMX definitions Paolo Bonzini
2019-09-17 10:34 ` [Qemu-devel] [PATCH 5/7] vmxcap: correct the name of the variables Paolo Bonzini
2019-09-17 10:34 ` [Qemu-devel] [PATCH 6/7] target/i386: add VMX features Paolo Bonzini
2019-09-19 14:32 ` Liran Alon
2019-09-19 14:54 ` Paolo Bonzini [this message]
2019-09-19 15:16 ` Paolo Bonzini
2019-09-17 10:34 ` [Qemu-devel] [PATCH 7/7] target/i386: work around KVM_GET_MSRS bug for secondary execution controls Paolo Bonzini
2019-09-17 12:28 ` [Qemu-devel] [PATCH v2 0/7] target/i386: support VMX features in "-cpu" no-reply
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=60820b32-42df-dbc0-9fc7-81821b2e42cb@redhat.com \
--to=pbonzini@redhat.com \
--cc=ehabkost@redhat.com \
--cc=liran.alon@oracle.com \
--cc=qemu-devel@nongnu.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).