[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <877e1riy1o.fsf@vitty.brq.redhat.com>
Date: Thu, 16 Jan 2020 09:51:47 +0100
From: Vitaly Kuznetsov <vkuznets@...hat.com>
To: Sean Christopherson <sean.j.christopherson@...el.com>
Cc: Liran Alon <liran.alon@...cle.com>, kvm@...r.kernel.org,
Paolo Bonzini <pbonzini@...hat.com>,
Jim Mattson <jmattson@...gle.com>,
linux-kernel@...r.kernel.org, Roman Kagan <rkagan@...tuozzo.com>
Subject: Re: [PATCH RFC 2/3] x86/kvm/hyper-v: move VMX controls sanitization out of nested_enable_evmcs()
Liran Alon <liran.alon@...cle.com> writes:
>> On 16 Jan 2020, at 1:27, Sean Christopherson <sean.j.christopherson@...el.com> wrote:
>>
>> On Wed, Jan 15, 2020 at 06:10:13PM +0100, Vitaly Kuznetsov wrote:
>>> With fine grained VMX feature enablement QEMU>=4.2 tries to do KVM_SET_MSRS
>>> with default (matching CPU model) values and in case eVMCS is also enabled,
>>> fails.
>>
>> As in, Qemu is blindly throwing values at KVM and complains on failure?
>> That seems like a Qemu bug, especially since Qemu needs to explicitly do
>> KVM_CAP_HYPERV_ENLIGHTENED_VMCS to enable eVMCS.
>
> See: https://patchwork.kernel.org/patch/11316021/
> For more context.
Ya,
while it would certainly be possible to require that userspace takes
into account KVM_CAP_HYPERV_ENLIGHTENED_VMCS (which is an opt-in) when
doing KVM_SET_MSRS there doesn't seem to be an existing (easy) way to
figure out which VMX controls were filtered out after enabling
KVM_CAP_HYPERV_ENLIGHTENED_VMCS: KVM_GET_MSRS returns global
&vmcs_config.nested values for VMX MSRs (vmx_get_msr_feature()).
--
Vitaly
Powered by blists - more mailing lists