From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([2001:4830:134:3::10]:37556) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1ez5TF-00021O-Bw for qemu-devel@nongnu.org; Thu, 22 Mar 2018 15:01:57 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1ez5TC-0001cB-A2 for qemu-devel@nongnu.org; Thu, 22 Mar 2018 15:01:53 -0400 Received: from mx1.redhat.com ([209.132.183.28]:48194) by eggs.gnu.org with esmtps (TLS1.0:DHE_RSA_AES_256_CBC_SHA1:32) (Exim 4.71) (envelope-from ) id 1ez5TC-0001bj-5D for qemu-devel@nongnu.org; Thu, 22 Mar 2018 15:01:50 -0400 Date: Thu, 22 Mar 2018 16:01:46 -0300 From: Eduardo Habkost Message-ID: <20180322190146.GA1396@localhost.localdomain> References: <20180322131358.15096-1-vkuznets@redhat.com> <20180322131358.15096-3-vkuznets@redhat.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20180322131358.15096-3-vkuznets@redhat.com> Subject: Re: [Qemu-devel] [PATCH v4 2/2] i386/kvm: expose Hyper-V frequency MSRs with reenlightenment List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Vitaly Kuznetsov Cc: qemu-devel@nongnu.org, Paolo Bonzini , Marcelo Tosatti , Roman Kagan , Richard Henderson On Thu, Mar 22, 2018 at 02:13:58PM +0100, Vitaly Kuznetsov wrote: > We can also expose Hyper-V frequency MSRs when reenlightenment feature is > enabled and TSC frequency is known, Hyper-V on KVM will provide stable TSC > page clocksources to its guests. > > Signed-off-by: Vitaly Kuznetsov > --- > - Expose frequency MSRs only when either INVTSC or Reenlightenment is > provided [Paolo Bonzini] > --- > target/i386/kvm.c | 3 ++- > 1 file changed, 2 insertions(+), 1 deletion(-) > > diff --git a/target/i386/kvm.c b/target/i386/kvm.c > index 75f4e1d69e..2c3c19d690 100644 > --- a/target/i386/kvm.c > +++ b/target/i386/kvm.c > @@ -651,7 +651,8 @@ static int hyperv_handle_properties(CPUState *cs) > env->features[FEAT_HYPERV_EAX] |= HV_TIME_REF_COUNT_AVAILABLE; > env->features[FEAT_HYPERV_EAX] |= HV_REFERENCE_TSC_AVAILABLE; > > - if (has_msr_hv_frequencies && tsc_is_stable_and_known(env)) { > + if (has_msr_hv_frequencies && env->tsc_khz && > + (tsc_is_stable_and_known(env) || cpu->hyperv_reenlightenment)) { Continuing the discussion we had in v3 about being possible to crash when migrating to a host running an older kernel: This patch doesn't fix the issue, because it is still implicitly enabling hv-frequencies. But I don't think this patch will make the situation any worse, because we don't have any KVM versions that support HV_X64_MSR_REENLIGHTENMENT_CONTROL but not HV_X64_MSR_TSC_FREQUENCY. This means that we can safely make "hv-reenlightenment=on" automatically set "hv-frequencies=on", when we finally introduce a hv-frequencies property. Roman, do you agree? The next question is: do we need to fix this and introduce a hv-frequencies property in 2.12, or can this wait for 2.13? > env->features[FEAT_HYPERV_EAX] |= HV_ACCESS_FREQUENCY_MSRS; > env->features[FEAT_HYPERV_EDX] |= HV_FREQUENCY_MSRS_AVAILABLE; > } > -- > 2.14.3 > > -- Eduardo