From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org X-Spam-Level: X-Spam-Status: No, score=-6.0 required=3.0 tests=BAYES_00,DKIMWL_WL_HIGH, DKIM_SIGNED,DKIM_VALID,DKIM_VALID_AU,MAILING_LIST_MULTI,SPF_HELO_NONE, SPF_PASS autolearn=no autolearn_force=no version=3.4.0 Received: from mail.kernel.org (mail.kernel.org [198.145.29.99]) by smtp.lore.kernel.org (Postfix) with ESMTP id 20147C4361B for ; Tue, 15 Dec 2020 16:56:48 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [23.128.96.18]) by mail.kernel.org (Postfix) with ESMTP id D40A622515 for ; Tue, 15 Dec 2020 16:56:47 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1730232AbgLOQ4V (ORCPT ); Tue, 15 Dec 2020 11:56:21 -0500 Received: from mail.kernel.org ([198.145.29.99]:56120 "EHLO mail.kernel.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1729665AbgLOQ4I (ORCPT ); Tue, 15 Dec 2020 11:56:08 -0500 X-Gm-Message-State: AOAM531hqTOMYM5zJ0Y32R+Jjvb4lbp7aFiM3Gqh59RZS6Z2hI6v8+BU SAW8psa7OIta17po8Ys7Po2q9N8i8Ms1OKg6T6YiKA== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1608051328; bh=wxgX7rhYWEdaXnSJ6bJp8xImT47Xo70cIxCVXhRWJMk=; h=References:In-Reply-To:From:Date:Subject:To:Cc:From; b=bKx5sHyUxlKUO5O1VSKvYl+KlaKh1xk5TM0+wfneX+9+TIBF2Ie4C+vqt8p2kpB3X CK624/Y76U1sBgrmcfi9FCN5fcukZN45Lozelv3Ea3HzoxndJlYYC5+FfQulzZuYrN Pvj8RGFxAewuiKi2Wg7CczDgRFskM9e+OZWs/SX0PoGuSI0wPr+kvIVzKZ4UoU2BcC nTdolSOetdQAWReQbNu/yqGiSiJ/Q73LRR/2qzl8i57W/cmJxFNNCI/vQRq92AKEgc ZtCO8fqfbsYDLZpZ7/FWmhc94qBXM4EIVTO/xtLEhZSwreSN1H61I3dOjCj25I7bKK rUViwgN8UvXhA== X-Google-Smtp-Source: ABdhPJw+VfdnYClq2C1NfMWCzjVSwytcRYUNwbuO86jDcwu7QTrd/YpYWhMAV2WfVcfj0qIb+FX0haGZwRfdhSVCd1Y= X-Received: by 2002:a5d:4905:: with SMTP id x5mr19403633wrq.75.1608051326140; Tue, 15 Dec 2020 08:55:26 -0800 (PST) MIME-Version: 1.0 References: <875z5c2db8.fsf@nanos.tec.linutronix.de> <20201209163434.GA22851@fuller.cnet> <87r1nyzogg.fsf@nanos.tec.linutronix.de> <20201210152618.GB23951@fuller.cnet> <87zh2lib8l.fsf@nanos.tec.linutronix.de> <20201211002703.GA47016@fuller.cnet> <87v9d8h3lx.fsf@nanos.tec.linutronix.de> <20201211141822.GA67764@fuller.cnet> <87k0togikr.fsf@nanos.tec.linutronix.de> <20201215105927.GA3321@fuller.cnet> In-Reply-To: <20201215105927.GA3321@fuller.cnet> From: Andy Lutomirski Date: Tue, 15 Dec 2020 08:55:15 -0800 X-Gmail-Original-Message-ID: Message-ID: Subject: Re: [PATCH v2 1/3] KVM: x86: implement KVM_{GET|SET}_TSC_STATE To: Marcelo Tosatti Cc: Paolo Bonzini , Thomas Gleixner , Maxim Levitsky , kvm list , "H. Peter Anvin" , Jonathan Corbet , Jim Mattson , Wanpeng Li , "open list:KERNEL SELFTEST FRAMEWORK" , Vitaly Kuznetsov , Sean Christopherson , open list , Ingo Molnar , "maintainer:X86 ARCHITECTURE (32-BIT AND 64-BIT)" , Joerg Roedel , Borislav Petkov , Shuah Khan , Andrew Jones , Oliver Upton , "open list:DOCUMENTATION" Content-Type: text/plain; charset="UTF-8" Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Tue, Dec 15, 2020 at 3:35 AM Marcelo Tosatti wrote: > > On Fri, Dec 11, 2020 at 10:59:59PM +0100, Paolo Bonzini wrote: > > On 11/12/20 22:04, Thomas Gleixner wrote: > > > > Its 100ms off with migration, and can be reduced further (customers > > > > complained about 5 seconds but seem happy with 0.1ms). > > > What is 100ms? Guaranteed maximum migration time? > > > > I suppose it's the length between the time from KVM_GET_CLOCK and > > KVM_GET_MSR(IA32_TSC) to KVM_SET_CLOCK and KVM_SET_MSR(IA32_TSC). But the > > VM is paused for much longer, the sequence for the non-live part of the > > migration (aka brownout) is as follows: > > > > pause > > finish sending RAM receive RAM ~1 sec > > send paused-VM state finish receiving RAM \ > > receive paused-VM state ) 0.1 sec > > restart / > > > > The nanosecond and TSC times are sent as part of the paused-VM state at the > > very end of the live migration process. > > > > So it's still true that the time advances during live migration brownout; > > 0.1 seconds is just the final part of the live migration process. But for > > _live_ migration there is no need to design things according to "people are > > happy if their clock is off by 0.1 seconds only". > > Agree. What would be a good way to fix this? > Could you implement the Hyper-V clock interface? It's much, much simpler than the kvmclock interface. It has the downside that CLOCK_BOOTTIME won't do what you want, but I'm not really convinced that's a problem, and you could come up with a minimal extension to fix that.