On 09/12/2015 23:27, Andy Lutomirski wrote: > On Wed, Dec 9, 2015 at 2:12 PM, Paolo Bonzini <pbonzini@xxxxxxxxxx> wrote: >> On 09/12/2015 22:49, Andy Lutomirski wrote: >>> On Wed, Dec 9, 2015 at 1:16 PM, Paolo Bonzini <pbonzini@xxxxxxxxxx> 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 -- To unsubscribe from this list: send the line "unsubscribe kvm" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
