Received-SPF: pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) client-ip=209.132.180.67;
Content-Type: text/plain;
        charset=utf-8
Mime-Version: 1.0 (Mac OS X Mail 11.1 \(3445.4.7\))
Subject: Re: [PATCH] x86/kvm/hyper-v: tweak HYPERV_CPUID_ENLIGHTMENT_INFO
From:   Liran Alon <liran.alon@oracle.com>
In-Reply-To: <8736pigdkm.fsf@vitty.brq.redhat.com>
Date:   Thu, 24 Jan 2019 19:41:08 +0200
Cc:     kvm@vger.kernel.org, Paolo Bonzini <pbonzini@redhat.com>,
        =?utf-8?B?UmFkaW0gS3LEjW3DocWZ?= <rkrcmar@redhat.com>,
        Roman Kagan <rkagan@virtuozzo.com>,
        linux-kernel@vger.kernel.org
Content-Transfer-Encoding: quoted-printable
Message-Id: <3CBF9845-3A41-4FB2-91A0-CD3D56614D9C@oracle.com>
References: <20190124171516.23626-1-vkuznets@redhat.com>
 <805B7B08-734E-4A96-AF98-D33065C59105@oracle.com>
 <8736pigdkm.fsf@vitty.brq.redhat.com>
To:     Vitaly Kuznetsov <vkuznets@redhat.com>
Sender: linux-kernel-owner@vger.kernel.org
Precedence: bulk


> On 24 Jan 2019, at 19:39, Vitaly Kuznetsov <vkuznets@redhat.com> =
wrote:
>=20
> Liran Alon <liran.alon@oracle.com> writes:
>=20
>>> On 24 Jan 2019, at 19:15, Vitaly Kuznetsov <vkuznets@redhat.com> =
wrote:
>>>=20
>>> 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.
>>>=20
>>> Windows seems to be fine either way but let's be consistent.
>>>=20
>>> Fixes: 2bc39970e932 ("x86/kvm/hyper-v: Introduce =
KVM_GET_SUPPORTED_HV_CPUID")
>>> Signed-off-by: Vitaly Kuznetsov <vkuznets@redhat.com>
>>> ---
>>> arch/x86/kvm/hyperv.c | 4 ++--
>>> 1 file changed, 2 insertions(+), 2 deletions(-)
>>>=20
>>> 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 |=3D =
HV_X64_REMOTE_TLB_FLUSH_RECOMMENDED;
>>> 			ent->eax |=3D HV_X64_APIC_ACCESS_RECOMMENDED;
>>> -			ent->eax |=3D HV_X64_SYSTEM_RESET_RECOMMENDED;
>>> 			ent->eax |=3D HV_X64_RELAXED_TIMING_RECOMMENDED;
>>> 			ent->eax |=3D HV_X64_CLUSTER_IPI_RECOMMENDED;
>>> 			ent->eax |=3D =
HV_X64_EX_PROCESSOR_MASKS_RECOMMENDED;
>>> -			ent->eax |=3D =
HV_X64_ENLIGHTENED_VMCS_RECOMMENDED;
>>> +			if (evmcs_ver)
>>> +				ent->eax |=3D =
HV_X64_ENLIGHTENED_VMCS_RECOMMENDED;
>>>=20
>>> 			/*
>>> 			 * Default number of spinlock retry attempts, =
matches
>>> --=20
>>> 2.20.1
>>>=20
>>=20
>> Seems to me that there are 2 unrelated separated patches here. Why =
not
>> split them?
>=20
> They seem to be too small :-) No problem, I'll split them up in v2.

I don=E2=80=99t 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. :)

>=20
>> For content itself: Reviewed-by: Liran Alon <liran.alon@oracle.com>
>>=20
>=20
> Thanks!
>=20
> --=20
> Vitaly