| Message ID | CALCETrU3to=8SNU+0Hr0MNGqs4GxA8j=0KBKWcy-Schu2PoaFw@mail.gmail.com (mailing list archive) |
|---|---|
| State | New, archived |
| Headers | show |
On 09/12/2015 23:27, Andy Lutomirski wrote: > On Wed, Dec 9, 2015 at 2:12 PM, Paolo Bonzini <pbonzini@redhat.com> wrote: >> On 09/12/2015 22:49, Andy Lutomirski wrote: >>> On Wed, Dec 9, 2015 at 1:16 PM, Paolo Bonzini <pbonzini@redhat.com> 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@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
On Wed, Dec 9, 2015 at 2:27 PM, Andy Lutomirski <luto@amacapital.net> wrote: > On Wed, Dec 9, 2015 at 2:12 PM, Paolo Bonzini <pbonzini@redhat.com> wrote: >> >> >> On 09/12/2015 22:49, Andy Lutomirski wrote: >>> On Wed, Dec 9, 2015 at 1:16 PM, Paolo Bonzini <pbonzini@redhat.com> 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. > >> >>>> - 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. >>> >>> Yup. But TSC by itself gets that benefit, too. >> >> Yes, 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? > >> >>>>> 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. >>> >>> Er? >>> >>> kvmclock is still really quite slow and buggy. >> >> Unless it takes 3-4000 clock cycles for a gettimeofday, which it >> shouldn't even with vdso disabled, it's definitely not slower than PIO. >> >>> And the patch I identified is definitely a problem here: >>> >>> [ 136.131241] KVM: disabling fast timing permanently due to inability >>> to recover from suspend >>> >>> I got that on the host with this whitespace-damaged patch: >>> >>> if (backwards_tsc) { >>> u64 delta_cyc = max_tsc - local_tsc; >>> + if (!backwards_tsc_observed) >>> + pr_warn("KVM: disabling fast timing >>> permanently due to inability to recover from suspend\n"); >>> >>> when I suspended and resumed. >>> >>> Can anyone explain what problem >>> 16a9602158861687c78b6de6dc6a79e6e8a9136f is supposed to solve? On >>> brief inspection, it just seems to be incorrect. Shouldn't KVM's >>> normal TSC logic handle that case right? After all, all vcpus should >>> be paused when we resume from suspend. At worst, we should just need >>> kvm_make_request(KVM_REQ_CLOCK_UPDATE, vcpu) on all vcpus. (Actually, >>> shouldn't we do that regardless of which way the TSC jumped on >>> suspend/resume? After all, the jTSC-to-wall-clock offset is quite >>> likely to change except on the very small handful of CPUs (if any) >>> that keep the TSC running in S3 and hibernate. >> >> I don't recall the details of that patch, so Marcelo will have to answer >> this, or Alex too since he chimed in the original thread. At least it >> should be made conditional on the existence of a VM at suspend time (and >> the master clock stuff should be made per VM, as I suggested at >> https://www.mail-archive.com/kvm@vger.kernel.org/msg102316.html). >> >> It would indeed be great if the master clock could be dropped. But I'm >> definitely missing some of the subtle details. :( > > Me, too. > > Anyway, see the attached untested patch. Marcelo? That patch seems to work. I have valid timing before and after host suspend. When I suspend and resume the host with a running guest, I get: [ 26.504071] clocksource: timekeeping watchdog: Marking clocksource 'tsc' as unstable because the skew is too large: [ 26.505253] clocksource: 'kvm-clock' wd_now: 66744c542 wd_last: 564b09794 mask: ffffffffffffffff [ 26.506436] clocksource: 'tsc' cs_now: fffffee310b133c8 cs_last: cf5d0b952 mask: ffffffffffffffff in the guest, which is arguably correct. KVM could be further improved to update the tsc offset after suspend/resume to get rid of that artifact. --Andy -- To unsubscribe from this list: send the line "unsubscribe kvm" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
On Wed, Dec 09, 2015 at 02:27:36PM -0800, Andy Lutomirski wrote: > On Wed, Dec 9, 2015 at 2:12 PM, Paolo Bonzini <pbonzini@redhat.com> wrote: > > > > > > On 09/12/2015 22:49, Andy Lutomirski wrote: > >> On Wed, Dec 9, 2015 at 1:16 PM, Paolo Bonzini <pbonzini@redhat.com> 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. > > > > >>> - 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. > >> > >> Yup. But TSC by itself gets that benefit, too. > > > > Yes, 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? > > > > >>>> 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. > >> > >> Er? > >> > >> kvmclock is still really quite slow and buggy. > > > > Unless it takes 3-4000 clock cycles for a gettimeofday, which it > > shouldn't even with vdso disabled, it's definitely not slower than PIO. > > > >> And the patch I identified is definitely a problem here: > >> > >> [ 136.131241] KVM: disabling fast timing permanently due to inability > >> to recover from suspend > >> > >> I got that on the host with this whitespace-damaged patch: > >> > >> if (backwards_tsc) { > >> u64 delta_cyc = max_tsc - local_tsc; > >> + if (!backwards_tsc_observed) > >> + pr_warn("KVM: disabling fast timing > >> permanently due to inability to recover from suspend\n"); > >> > >> when I suspended and resumed. > >> > >> Can anyone explain what problem > >> 16a9602158861687c78b6de6dc6a79e6e8a9136f is supposed to solve? On > >> brief inspection, it just seems to be incorrect. Shouldn't KVM's > >> normal TSC logic handle that case right? After all, all vcpus should > >> be paused when we resume from suspend. At worst, we should just need > >> kvm_make_request(KVM_REQ_CLOCK_UPDATE, vcpu) on all vcpus. (Actually, > >> shouldn't we do that regardless of which way the TSC jumped on > >> suspend/resume? After all, the jTSC-to-wall-clock offset is quite > >> likely to change except on the very small handful of CPUs (if any) > >> that keep the TSC running in S3 and hibernate. > > > > I don't recall the details of that patch, so Marcelo will have to answer > > this, or Alex too since he chimed in the original thread. At least it > > should be made conditional on the existence of a VM at suspend time (and > > the master clock stuff should be made per VM, as I suggested at > > https://www.mail-archive.com/kvm@vger.kernel.org/msg102316.html). > > > > It would indeed be great if the master clock could be dropped. But I'm > > definitely missing some of the subtle details. :( > > Me, too. > > Anyway, see the attached untested patch. Marcelo? > > --Andy Read the last email, about the problem. -- To unsubscribe from this list: send the line "unsubscribe kvm" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
From e4a5e834d3fb6fc2499966e1af42cb5bd59f4410 Mon Sep 17 00:00:00 2001 Message-Id: <e4a5e834d3fb6fc2499966e1af42cb5bd59f4410.1449700024.git.luto@kernel.org> From: Andy Lutomirski <luto@kernel.org> Date: Wed, 9 Dec 2015 14:21:05 -0800 Subject: [PATCH] x86/kvm: On KVM re-enable (e.g. after suspect), update clocks This gets rid of the "did TSC go backwards" logic and just updates all clocks. It should work better (no more disabling of fast timing) and more reliably (all of the clocks are actually updated). Signed-off-by: Andy Lutomirski <luto@kernel.org> --- arch/x86/kvm/x86.c | 75 +++--------------------------------------------------- 1 file changed, 3 insertions(+), 72 deletions(-) diff --git a/arch/x86/kvm/x86.c b/arch/x86/kvm/x86.c index eed32283d22c..c88f91f4b1a3 100644 --- a/arch/x86/kvm/x86.c +++ b/arch/x86/kvm/x86.c @@ -123,8 +123,6 @@ module_param(tsc_tolerance_ppm, uint, S_IRUGO | S_IWUSR); unsigned int __read_mostly lapic_timer_advance_ns = 0; module_param(lapic_timer_advance_ns, uint, S_IRUGO | S_IWUSR); -static bool __read_mostly backwards_tsc_observed = false; - #define KVM_NR_SHARED_MSRS 16 struct kvm_shared_msrs_global { @@ -1671,7 +1669,6 @@ static void pvclock_update_vm_gtod_copy(struct kvm *kvm) &ka->master_cycle_now); ka->use_master_clock = host_tsc_clocksource && vcpus_matched - && !backwards_tsc_observed && !ka->boot_vcpu_runs_old_kvmclock; if (ka->use_master_clock) @@ -7369,88 +7366,22 @@ int kvm_arch_hardware_enable(void) struct kvm_vcpu *vcpu; int i; int ret; - u64 local_tsc; - u64 max_tsc = 0; - bool stable, backwards_tsc = false; kvm_shared_msr_cpu_online(); ret = kvm_x86_ops->hardware_enable(); if (ret != 0) return ret; - local_tsc = rdtsc(); - stable = !check_tsc_unstable(); list_for_each_entry(kvm, &vm_list, vm_list) { kvm_for_each_vcpu(i, vcpu, kvm) { - if (!stable && vcpu->cpu == smp_processor_id()) + if (vcpu->cpu == smp_processor_id()) { kvm_make_request(KVM_REQ_CLOCK_UPDATE, vcpu); - if (stable && vcpu->arch.last_host_tsc > local_tsc) { - backwards_tsc = true; - if (vcpu->arch.last_host_tsc > max_tsc) - max_tsc = vcpu->arch.last_host_tsc; + kvm_make_request(KVM_REQ_MASTERCLOCK_UPDATE, + vcpu); } } } - /* - * Sometimes, even reliable TSCs go backwards. This happens on - * platforms that reset TSC during suspend or hibernate actions, but - * maintain synchronization. We must compensate. Fortunately, we can - * detect that condition here, which happens early in CPU bringup, - * before any KVM threads can be running. Unfortunately, we can't - * bring the TSCs fully up to date with real time, as we aren't yet far - * enough into CPU bringup that we know how much real time has actually - * elapsed; our helper function, get_kernel_ns() will be using boot - * variables that haven't been updated yet. - * - * So we simply find the maximum observed TSC above, then record the - * adjustment to TSC in each VCPU. When the VCPU later gets loaded, - * the adjustment will be applied. Note that we accumulate - * adjustments, in case multiple suspend cycles happen before some VCPU - * gets a chance to run again. In the event that no KVM threads get a - * chance to run, we will miss the entire elapsed period, as we'll have - * reset last_host_tsc, so VCPUs will not have the TSC adjusted and may - * loose cycle time. This isn't too big a deal, since the loss will be - * uniform across all VCPUs (not to mention the scenario is extremely - * unlikely). It is possible that a second hibernate recovery happens - * much faster than a first, causing the observed TSC here to be - * smaller; this would require additional padding adjustment, which is - * why we set last_host_tsc to the local tsc observed here. - * - * N.B. - this code below runs only on platforms with reliable TSC, - * as that is the only way backwards_tsc is set above. Also note - * that this runs for ALL vcpus, which is not a bug; all VCPUs should - * have the same delta_cyc adjustment applied if backwards_tsc - * is detected. Note further, this adjustment is only done once, - * as we reset last_host_tsc on all VCPUs to stop this from being - * called multiple times (one for each physical CPU bringup). - * - * Platforms with unreliable TSCs don't have to deal with this, they - * will be compensated by the logic in vcpu_load, which sets the TSC to - * catchup mode. This will catchup all VCPUs to real time, but cannot - * guarantee that they stay in perfect synchronization. - */ - if (backwards_tsc) { - u64 delta_cyc = max_tsc - local_tsc; - backwards_tsc_observed = true; - list_for_each_entry(kvm, &vm_list, vm_list) { - kvm_for_each_vcpu(i, vcpu, kvm) { - vcpu->arch.tsc_offset_adjustment += delta_cyc; - vcpu->arch.last_host_tsc = local_tsc; - kvm_make_request(KVM_REQ_MASTERCLOCK_UPDATE, vcpu); - } - - /* - * We have to disable TSC offset matching.. if you were - * booting a VM while issuing an S4 host suspend.... - * you may have some problem. Solving this issue is - * left as an exercise to the reader. - */ - kvm->arch.last_tsc_nsec = 0; - kvm->arch.last_tsc_write = 0; - } - - } return 0; } -- 2.5.0