From mboxrd@z Thu Jan 1 00:00:00 1970 From: Paolo Bonzini Subject: Re: kvmclock doesn't work, help? Date: Wed, 9 Dec 2015 22:16:27 +0100 Message-ID: <56689A2B.6090500@redhat.com> References: Mime-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit To: Andy Lutomirski , kvm list , Marcelo Tosatti , Radim Krcmar , X86 ML Return-path: Received: from mx1.redhat.com ([209.132.183.28]:37529 "EHLO mx1.redhat.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1753152AbbLIVQj (ORCPT ); Wed, 9 Dec 2015 16:16:39 -0500 In-Reply-To: Sender: kvm-owner@vger.kernel.org List-ID: On 09/12/2015 22:10, Andy Lutomirski wrote: > Can we please stop making kvmclock more complex? It's a beast right > now, and not in a good way. It's far too tangled with the vclock > machinery on both the host and guest sides, the pvclock stuff is not > well thought out (even in principle in an ABI sense), and it's never > been clear to my what problem exactly the kvmclock stuff is supposed > to solve. It's supposed to solve the problem that: - not all hosts have a working TSC - even if they all do, virtual machines can be migrated (or saved/restored) to a host with a different TSC frequency - any MMIO- or PIO-based mechanism to access the current time is orders of magnitude slower than the TSC and less precise too. > I'm somewhat tempted to suggest that we delete kvmclock entirely and > start over. A correctly functioning KVM guest using TSC (i.e. > ignoring kvmclock entirely) seems to work rather more reliably and > considerably faster than a kvmclock guest. If all your hosts have a working TSC and you don't do migration or save/restore, that's a valid configuration. It's not a good default, however. Paolo