[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <CALzav=eTPVECBfPpkOaUMUbN5KjJuZUixdNB9uqRz+oOi+1-qQ@mail.gmail.com>
Date: Wed, 30 Nov 2016 10:05:04 -0800
From: David Matlack <dmatlack@...gle.com>
To: Paolo Bonzini <pbonzini@...hat.com>
Cc: kvm list <kvm@...r.kernel.org>,
"linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
Jim Mattson <jmattson@...gle.com>,
Radim Krčmář <rkrcmar@...hat.com>
Subject: Re: [PATCH v3 1/5] KVM: nVMX: generate non-true VMX MSRs based on
true versions
On Wed, Nov 30, 2016 at 3:16 AM, Paolo Bonzini <pbonzini@...hat.com> wrote:
> On 30/11/2016 03:14, David Matlack wrote:
>>
>> /* secondary cpu-based controls */
>> @@ -2868,36 +2865,32 @@ static int vmx_get_vmx_msr(struct kvm_vcpu *vcpu, u32 msr_index, u64 *pdata)
>> *pdata = vmx_control_msr(
>> vmx->nested.nested_vmx_pinbased_ctls_low,
>> vmx->nested.nested_vmx_pinbased_ctls_high);
>> + if (msr_index == MSR_IA32_VMX_PINBASED_CTLS)
>> + *pdata |= PIN_BASED_ALWAYSON_WITHOUT_TRUE_MSR;
>
> Almost: PIN_BASED_ALWAYSON_WITHOUT_TRUE_MSR must be
> added to both the low and high parts. Likewise below.
> I guess you can use vmx_control_msr to generate it, too.
SGTM.
Although that would mean the true MSRs indicate a bit must-be-0 while
the non-true MSRs are indicating it must-be-1, which seems odd.
Powered by blists - more mailing lists