[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <CALMp9eQYf4YjkD9W_4ySbJAxqe_oXQYrn5dpbp1Vm6jBu_2g7A@mail.gmail.com>
Date: Thu, 24 Aug 2017 09:02:37 -0700
From: Jim Mattson <jmattson@...gle.com>
To: Paolo Bonzini <pbonzini@...hat.com>
Cc: LKML <linux-kernel@...r.kernel.org>, kvm list <kvm@...r.kernel.org>
Subject: Re: [PATCH 1/4] KVM: VMX: cache secondary exec controls
On the subject of complexity, why do we clear
CPUID.(EAX=07H,ECX=0):EBX.INVPCID[bit 10] when CPUID.01H:ECX.PCID[bit
17] is clear? Sure, it would be odd to support the INVPCID instruction
without also supporting PCIDs, but why single out this one check?
Isn't it equally bizarre to support SSE2 without SSE, or XSAVES
without XSAVE, or RDTSCP without TSC, or DS-CPL without DS, or ...?
On Thu, Aug 24, 2017 at 8:46 AM, Paolo Bonzini <pbonzini@...hat.com> wrote:
> On 24/08/2017 17:41, Jim Mattson wrote:
>> Userspace can establish the value of the virtualized
>> IA32_VMX_PROCBASED_CTLS2 MSR via the KVM_SET_MSRS ioctl, which goes
>> through vms_set_vmx_msr. But maybe that's not important, since
>> features can only be disabled on that path.
>
> Yeah, I was only thinking of non-nested in the commit message. It's
> complicated enough. :)
>
> Paolo
>
>> On Thu, Aug 24, 2017 at 8:25 AM, Paolo Bonzini <pbonzini@...hat.com> wrote:
>>> On 24/08/2017 16:47, Jim Mattson wrote:
>>>>> Currently, secondary execution controls are divided in three groups:
>>>>>
>>>>> - static, depending mostly on the module arguments or the processor
>>>>> (vmx_secondary_exec_control)
>>>>>
>>>>> - static, depending on CPUID (vmx_cpuid_update)
>>>> There should also be:
>>>>
>>>> - static, depending on guest VMX capability MSRs (vmx_set_vmx_msr)
>>> Can you explain what you mean?
>>>
>>> Paolo
>
Powered by blists - more mailing lists