From mboxrd@z Thu Jan 1 00:00:00 1970 From: Zachary Amsden Subject: Re: KVM timekeeping and TSC virtualization Date: Wed, 25 Aug 2010 10:32:46 -1000 Message-ID: <4C757DEE.6000809@redhat.com> References: <1282291669-25709-1-git-send-email-zamsden@redhat.com> <4C6E8284.6020200@cisco.com> <4C6F0EB8.7050906@redhat.com> <4C707E23.80209@cisco.com> <4C73240F.5010902@redhat.com> <4C7336C9.8000006@cisco.com> <4C735D09.6080506@redhat.com> <4C73C9D0.7040007@cisco.com> <4C744F52.8070207@redhat.com> <20100825165554.GA27263@amt.cnet> Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: "David S. Ahern" , kvm@vger.kernel.org To: Marcelo Tosatti Return-path: Received: from mx1.redhat.com ([209.132.183.28]:60667 "EHLO mx1.redhat.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751998Ab0HYUdA (ORCPT ); Wed, 25 Aug 2010 16:33:00 -0400 In-Reply-To: <20100825165554.GA27263@amt.cnet> Sender: kvm-owner@vger.kernel.org List-ID: On 08/25/2010 06:55 AM, Marcelo Tosatti wrote: > On Tue, Aug 24, 2010 at 01:01:38PM -1000, Zachary Amsden wrote: > >>>> With this patchset, KVM now has a much stronger guarantee: If you have >>>> old guest software running on broken hardware, using SMP virtual >>>> machines, you do not get hardware performance and error-free time >>>> virtualization. However, if you have new guest software, non-broken >>>> hardware, or can simply run UP guests instead of SMP, you can have >>>> hardware performance, and it is now error free. Alternatively, you can >>>> sacrifice some accuracy and have hardware performance, even for SMP >>>> guests, if you can tolerate some minor cross-CPU TSC variation. No >>>> other vendor I know of can make that guarantee. >>>> >>>> Zach >>>> >>> If the processor has a stable TSC why trap it? I realize you are trying >>> to cover a gauntlet of hardware and guests, so maybe a nerd knob is >>> needed to disable. >>> >> Exactly. If you have a stable TSC, we don't trap it. If you don't >> have a stable TSC, we do. That's the point of these patches. >> > Wait, don't you trap if host TSC is faster than guest TSC? > Yes, but that's not a standard scenario, that only applies for a migration. There's also a way to avoid this: set guest TSC > MAX (all host TSCs in cluster) Then catchup mode will be used to keep the TSC up to speed. Actually, it's an open question what to do for SMP in this case, I'm not sure I got that right. Technically the proper thing to do is to trap, but this should have a user override. Zach