From mboxrd@z Thu Jan 1 00:00:00 1970 From: Avi Kivity Subject: Re: [PATCH] tsc: use kvmclock for calibration Date: Sun, 12 Aug 2012 13:56:51 +0300 Message-ID: <50278BF3.6000600@redhat.com> References: <1344513463-7329-1-git-send-email-kraxel@redhat.com> <5023B2C4.90302@redhat.com> <5023C1D2.5090103@redhat.com> <5023C2BE.5070702@redhat.com> <5023C6B8.4090805@redhat.com> <5023C71B.6090707@redhat.com> <20120809190203.GE20889@amt.cnet> Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: Gerd Hoffmann , seabios@seabios.org, kvm@vger.kernel.org To: Marcelo Tosatti Return-path: Received: from mx1.redhat.com ([209.132.183.28]:38438 "EHLO mx1.redhat.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1750828Ab2HLK5L (ORCPT ); Sun, 12 Aug 2012 06:57:11 -0400 In-Reply-To: <20120809190203.GE20889@amt.cnet> Sender: kvm-owner@vger.kernel.org List-ID: On 08/09/2012 10:02 PM, Marcelo Tosatti wrote: > On Thu, Aug 09, 2012 at 05:20:11PM +0300, Avi Kivity wrote: >> On 08/09/2012 05:18 PM, Gerd Hoffmann wrote: >> > Hi, >> > >> >>> So what do you suggest? The options I see are: >> >>> >> >>> (1) Use this patch (with alignment issue fixed of course). >> >>> (2) Do a full kvmclock implementation. Feels a bit like overkill. >> >>> (3) SeaBIOS can fallback to the PIT for timing on machines which >> >>> have no TSC. We could do that too in case we detect kvm ... >> >> >> >> What sort of timeouts are these? If seconds, maybe the rtc would be best. >> > >> > All sorts of timeouts, from a few miliseconds to seconds. >> > >> > The problematic ones are the longer timeouts, which wait for I/O stuff >> > like disk reads complete. The stuff with smaller timeouts (like waiting >> > for AHCI link become ready) tend to finish instantly in kvm. >> >> That's not guaranteed. The AHCI adapter might be real hardware. Or the >> emulation may change. >> >> What's wrong with having a full kvmclock implementation? Instead of >> issuing rdtsc call a function pointer. > > Its not necessary (someone is going to maintain the kvmclock frequency > retrieve, which patch is already here, versus maintainance of > full kvmclock). The frequency is meaninless. > > Frequency scaling (or the software equivalent: TSC trapping) are > required for other reasons anyway. One thing we can do is enable TSC trapping, then disable it if the guest activates kvmclock. That gives us accurate time either way. -- error compiling committee.c: too many arguments to function