From mboxrd@z Thu Jan 1 00:00:00 1970 From: Eduardo Habkost Subject: Re: invtsc + migration + TSC scaling Date: Tue, 18 Oct 2016 19:05:14 -0200 Message-ID: <20161018210514.GC5057@thinpad.lan.raisama.net> References: <20161014212031.GQ3275@thinpad.lan.raisama.net> <20161017094708.GB31691@amt.cnet> <20161017145008.GA2307@potion> <72b8c6b3-f08a-735a-e283-99d0195dcf7d@redhat.com> <20161017211101.GD3275@thinpad.lan.raisama.net> <20161017235846.GA22657@amt.cnet> <74794dbf-a904-54b9-315f-1bc385a959ba@redhat.com> <20161018170924.GA14243@amt.cnet> <20161018205213.GA2511@potion> Mime-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 8bit Cc: Marcelo Tosatti , Paolo Bonzini , qemu-devel@nongnu.org, kvm@vger.kernel.org To: Radim =?utf-8?B?S3LEjW3DocWZ?= Return-path: Received: from mx1.redhat.com ([209.132.183.28]:46602 "EHLO mx1.redhat.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1750770AbcJRVFV (ORCPT ); Tue, 18 Oct 2016 17:05:21 -0400 Content-Disposition: inline In-Reply-To: <20161018205213.GA2511@potion> Sender: kvm-owner@vger.kernel.org List-ID: On Tue, Oct 18, 2016 at 10:52:14PM +0200, Radim Krčmář wrote: [...] > The main problem is that QEMU changes virtual_tsc_khz when migrating > without hardware scaling, so KVM is forced to get nanoseconds wrong ... > > If QEMU doesn't want to keep the TSC frequency constant, then it would > be better if it didn't expose TSC in CPUID -- guest would just use > kvmclock without being tempted by direct TSC accesses. Isn't enough to simply not expose invtsc? Aren't guests expected to assume the TSC frequency can change if invtsc isn't set on CPUID? -- Eduardo