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=-5.8 required=3.0 tests=BAYES_00,DKIM_SIGNED, DKIM_VALID,DKIM_VALID_AU,HEADER_FROM_DIFFERENT_DOMAINS,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 0BE5AC433FE for ; Sat, 12 Dec 2020 13:05:20 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [23.128.96.18]) by mail.kernel.org (Postfix) with ESMTP id D107F22CA1 for ; Sat, 12 Dec 2020 13:05:19 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S2439020AbgLLNFC (ORCPT ); Sat, 12 Dec 2020 08:05:02 -0500 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:42438 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S2394867AbgLLNEF (ORCPT ); Sat, 12 Dec 2020 08:04:05 -0500 Received: from galois.linutronix.de (Galois.linutronix.de [IPv6:2a0a:51c0:0:12e:550::1]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id A410CC0613CF; Sat, 12 Dec 2020 05:03:24 -0800 (PST) From: Thomas Gleixner DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=linutronix.de; s=2020; t=1607778202; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc:mime-version:mime-version:content-type:content-type: in-reply-to:in-reply-to:references:references; bh=dm0h1kETERLgrH3MYccPKguhl9RAaSD+kQ67+0pK7gQ=; b=Ym3dRr/Y+Sb79nbnelKOQlClJALoto3behsFcq1miJktOuA0kzzOVdVcS7UUx0se15/m/t wdvP10HVpZpXTGthQrL3UhPTwRqNWAjn3RI4/3+an4yBMaR5kBF9P6VaMjj8XIkiXn6CFe kYm6Bd7x/KzQqV8DBtfRgy1lz3PD4DI8Dma4mTgIbJWMUVwdzyqU86OpLKN2f3MULD3jyc ZyXN1Vw7dfr6kisWY7hBvz9bCCZG2bZCD099FWS6Uyl3E75nsk3JBisz0hBcGPOkerunbi zcEFOeB63/oY/6EuQ2uDCwdts6e87L0ImP/iZ8wdf90bvd4x3Z4TJuMmmEPSWQ== DKIM-Signature: v=1; a=ed25519-sha256; c=relaxed/relaxed; d=linutronix.de; s=2020e; t=1607778202; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc:mime-version:mime-version:content-type:content-type: in-reply-to:in-reply-to:references:references; bh=dm0h1kETERLgrH3MYccPKguhl9RAaSD+kQ67+0pK7gQ=; b=limZ6dagZ2Cmsj35YZ/sv7F5dIwrMyk02ULK2mEBjFv3NwSiZb0GC8oYw4z+0SXtD+K7jO /ZCrQTiJ9XcpZVAA== To: Paolo Bonzini , Marcelo Tosatti Cc: Maxim Levitsky , kvm@vger.kernel.org, "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" Subject: Re: [PATCH v2 1/3] KVM: x86: implement KVM_{GET|SET}_TSC_STATE In-Reply-To: References: <05aaabedd4aac7d3bce81d338988108885a19d29.camel@redhat.com> <87sg8g2sn4.fsf@nanos.tec.linutronix.de> <20201208181107.GA31442@fuller.cnet> <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> Date: Sat, 12 Dec 2020 14:03:22 +0100 Message-ID: <87lfe3fa79.fsf@nanos.tec.linutronix.de> MIME-Version: 1.0 Content-Type: text/plain Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Fri, Dec 11 2020 at 22:59, Paolo Bonzini wrote: > On 11/12/20 22:04, Thomas Gleixner wrote: > 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". The problem is not the 0.1 second jump of the TSC. That's just a minor nuisance. The problem is the incorrectness of CLOCK_REALTIME after this operation which is far larger than 0.1s and this needs to be fixed. > Again, save-to-disk, reverse debugging and the like are a different > story, which is why KVM should delegate policy to userspace (while > documenting how to do it right). One ready to use option would be suspend to idle. It's fast and readily available including all the notifications and kernel side handling of time and whatever. Thanks, tglx