[<prev] [next>] [<thread-prev] [day] [month] [year] [list]
Message-Id: <3CBF9845-3A41-4FB2-91A0-CD3D56614D9C@oracle.com>
Date: Thu, 24 Jan 2019 19:41:08 +0200
From: Liran Alon <liran.alon@...cle.com>
To: Vitaly Kuznetsov <vkuznets@...hat.com>
Cc: kvm@...r.kernel.org, Paolo Bonzini <pbonzini@...hat.com>,
Radim Krčmář <rkrcmar@...hat.com>,
Roman Kagan <rkagan@...tuozzo.com>,
linux-kernel@...r.kernel.org
Subject: Re: [PATCH] x86/kvm/hyper-v: tweak HYPERV_CPUID_ENLIGHTMENT_INFO
> On 24 Jan 2019, at 19:39, Vitaly Kuznetsov <vkuznets@...hat.com> wrote:
>
> Liran Alon <liran.alon@...cle.com> writes:
>
>>> On 24 Jan 2019, at 19:15, Vitaly Kuznetsov <vkuznets@...hat.com> wrote:
>>>
>>> We shouldn't probably be suggesting using Enlightened VMCS when it's not
>>> enabled (not supported from guest's point of view). System reset through
>>> synthetic MSR is not recommended neither by genuine Hyper-V nor my QEMU.
>>>
>>> Windows seems to be fine either way but let's be consistent.
>>>
>>> Fixes: 2bc39970e932 ("x86/kvm/hyper-v: Introduce KVM_GET_SUPPORTED_HV_CPUID")
>>> Signed-off-by: Vitaly Kuznetsov <vkuznets@...hat.com>
>>> ---
>>> arch/x86/kvm/hyperv.c | 4 ++--
>>> 1 file changed, 2 insertions(+), 2 deletions(-)
>>>
>>> diff --git a/arch/x86/kvm/hyperv.c b/arch/x86/kvm/hyperv.c
>>> index ac44a681f065..4730fcaa70cf 100644
>>> --- a/arch/x86/kvm/hyperv.c
>>> +++ b/arch/x86/kvm/hyperv.c
>>> @@ -1847,11 +1847,11 @@ int kvm_vcpu_ioctl_get_hv_cpuid(struct kvm_vcpu *vcpu, struct kvm_cpuid2 *cpuid,
>>> case HYPERV_CPUID_ENLIGHTMENT_INFO:
>>> ent->eax |= HV_X64_REMOTE_TLB_FLUSH_RECOMMENDED;
>>> ent->eax |= HV_X64_APIC_ACCESS_RECOMMENDED;
>>> - ent->eax |= HV_X64_SYSTEM_RESET_RECOMMENDED;
>>> ent->eax |= HV_X64_RELAXED_TIMING_RECOMMENDED;
>>> ent->eax |= HV_X64_CLUSTER_IPI_RECOMMENDED;
>>> ent->eax |= HV_X64_EX_PROCESSOR_MASKS_RECOMMENDED;
>>> - ent->eax |= HV_X64_ENLIGHTENED_VMCS_RECOMMENDED;
>>> + if (evmcs_ver)
>>> + ent->eax |= HV_X64_ENLIGHTENED_VMCS_RECOMMENDED;
>>>
>>> /*
>>> * Default number of spinlock retry attempts, matches
>>> --
>>> 2.20.1
>>>
>>
>> Seems to me that there are 2 unrelated separated patches here. Why not
>> split them?
>
> They seem to be too small :-) No problem, I'll split them up in v2.
I don’t think in general that it matters how small they are.
Separating to small logical patches allows better bisect, easier review and better revert resolution. So better overall. :)
>
>> For content itself: Reviewed-by: Liran Alon <liran.alon@...cle.com>
>>
>
> Thanks!
>
> --
> Vitaly
Powered by blists - more mailing lists