From mboxrd@z Thu Jan 1 00:00:00 1970 From: Paolo Bonzini Subject: Re: [PATCH kvm-unit-tests] KVM: x86: add hyperv clock test case Date: Thu, 4 Feb 2016 11:13:58 +0100 Message-ID: <56B32466.6020108@redhat.com> References: <1453989899-30351-1-git-send-email-pbonzini@redhat.com> <20160128162206.GA29344@rkaganb.sw.ru> <56B22CB4.9090404@redhat.com> <20160204093325.GA31799@rkaganb.sw.ru> Mime-Version: 1.0 Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 8bit To: Roman Kagan , kvm@vger.kernel.org, Andrey Smetanin , "Denis V. Lunev" , Marcelo Tosatti Return-path: Received: from mx1.redhat.com ([209.132.183.28]:47534 "EHLO mx1.redhat.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S933687AbcBDKOB (ORCPT ); Thu, 4 Feb 2016 05:14:01 -0500 In-Reply-To: <20160204093325.GA31799@rkaganb.sw.ru> Sender: kvm-owner@vger.kernel.org List-ID: On 04/02/2016 10:33, Roman Kagan wrote: >> The bit that I was missing last week was how the guest could perceive >> updates to the TSC page parameters as atomic. We actually _can_ >> emulate seqlock-like behavior in Hyper-V by writing 0 to seq during >> an update. Instead of looping like seqlocks do, the guest will simply >> use the time reference counter and take a hypervisor exit. The result >> however is still valid, because we want the time reference counter to >> be perfectly synchronized with the Hyper-V clock and lets you handle >> any kvmclock update scenario safely. > > That's smart, thanks for the idea! We'll only need to check that > Windows goes through all these steps on every clock read, rather than > remembering the failure and sticking with the MSR for good. Andrey pointed me to https://lkml.org/lkml/2015/11/2/655, which has the source for Windows's clock read code. It should work. >> The remaining part is _further_ adjusting the offset to > > ...? Cut and paste. :) I'll take a look at it if it's not super-high priority for you. Paolo