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 23:42:53 +0100 Message-ID: <5668AE6D.5090409@redhat.com> References: <56689A2B.6090500@redhat.com> <5668A76A.7050707@redhat.com> Mime-Version: 1.0 Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 8bit Cc: kvm list , Marcelo Tosatti , Radim Krcmar , X86 ML , Alexander Graf To: Andy Lutomirski Return-path: Received: from mx1.redhat.com ([209.132.183.28]:45789 "EHLO mx1.redhat.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1752982AbbLIWnE (ORCPT ); Wed, 9 Dec 2015 17:43:04 -0500 In-Reply-To: Sender: kvm-owner@vger.kernel.org List-ID: On 09/12/2015 23:27, Andy Lutomirski wrote: > On Wed, Dec 9, 2015 at 2:12 PM, Paolo Bonzini wrote: >> On 09/12/2015 22:49, Andy Lutomirski wrote: >>> On Wed, Dec 9, 2015 at 1:16 PM, Paolo Bonzini wrote: >>>> >>>> >>>> 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 >>> >>> Fine, but we don't need any vdso integration for that. >> >> Well, you still want a fast time source. That was a given. :) > > If the host can't figure out how to give *itself* a fast time source, > I'd be surprised if KVM can manage to give the guest a fast, reliable > time source. There's no vdso integration unless the host has a constant, nonstop (fully "working") TSC. That's the meaning of PVCLOCK_TSC_STABLE_BIT. So, correction: if you can pull it off, you still want a fast time source. Otherwise, you still want one that is as fast as possible, especially on the kernel side. >>>> - 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. >> >> the problem is if you want to solve all three of them. The first >> two are solved by the ACPI PM timer with a decent resolution (70 >> ns---much faster anyway than an I/O port access). The third is solved >> by TSC. To solve all three, you need kvmclock. > > Still confused. Is kvmclock really used in cases where even the host > can't pull of working TSC? You can certainly provide kvmclock even if you lack constant-rate or nonstop TSC. Those are only a requirement for vdso. If the host has a constant-rate TSC, but the rate differs per physical CPU (common on older NUMA machines), you can easily provide a working kvmclock. It cannot support vdso because you'll need to read the time from a non-preemptable section, but it will work because KVM can update the kvmclock parameters on VCPU migration, and it's still faster than anything else. (The purpose of the now-gone migration notifiers was to support vdso even in this case). If the host doesn't even have constant-rate TSC, you can still provide kernel-only kvmclock reads through cpufreq notifiers. Paolo