Received: by 2002:a05:6a10:f347:0:0:0:0 with SMTP id d7csp4209642pxu; Wed, 9 Dec 2020 11:00:15 -0800 (PST) X-Google-Smtp-Source: ABdhPJzGi4o79LE5csFJfsF6fh8z08ZlayEWWLKgazkK+KIm5P9DooicZBW7cTLcUCtjNzUosQRz X-Received: by 2002:a17:907:1010:: with SMTP id ox16mr3330270ejb.439.1607540415150; Wed, 09 Dec 2020 11:00:15 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; t=1607540415; cv=none; d=google.com; s=arc-20160816; b=OhNoZ6/LkkpAYjVGjo7FnYf24NvoWqEXUICv4nf+YF1GEicrB/gjDJQCdu2cO/deY0 ycQ6bpMstwWuCAbiA1VcHxFjA4t+oD/lWj0+QJJTkM4YSJcDm68mRtAFrrjvrvgL+zj8 4tiTzBzL1VKm7eBosXN713vM/lABn2krrRRw01GYMm0/Wjz8HzaqbD/knFq66MbD/M16 aEs1M83uGMJe1pOdlmEa223hsFM2q/18MYu+0JliQqzNbTMD6BGWKdqc4q/k88QOmoqT 4TGVUOXvemgzlH2IdJbHZTCAsrptqk2L3amEwwUv2wR8TDQncyXCtXGTK16GtG1L3jr7 Sqxg== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:user-agent:in-reply-to:content-disposition :mime-version:references:message-id:subject:cc:to:from:date :dkim-signature; bh=pAnzkkggIin7jYeCuo0D9ShCd/x0gLLXGM9tw9DfkJs=; b=VjTzHF0bg2xRxCl+aYddotEOMQVjjU2Q+uU1aZWVlgLtmSY5Ktdz6jC/2Jp8ufYhQ8 6nYCN6GDj5WMX7y0tYxe50/yqplMy2pB5X2QUWxlYVcqhtKcq5u3g96foeWSC18FLvLo 00E7sLg9YlbnSLd++E0OVA8P81ogK1heTR4gMFDtIl+dlnGnUbOMTu6kIj+YHrAqVFkt 86NO4XgVesUYlS8clr6fumIBWWHMXqBQDPR/51Y8Uzn5EUaxasLx+OvjQqZPjjW4+4+N ZXvfswKW4UAsJlzlAx+YAsXx7LZAxprxEULG5IirVxhqSNH6GcvkPqEPL4lqwsGqDoPC hhJw== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@redhat.com header.s=mimecast20190719 header.b=Y1n0MszP; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=redhat.com Return-Path: Received: from vger.kernel.org (vger.kernel.org. [23.128.96.18]) by mx.google.com with ESMTP id q23si1297087ejn.17.2020.12.09.10.59.52; Wed, 09 Dec 2020 11:00:15 -0800 (PST) Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) client-ip=23.128.96.18; Authentication-Results: mx.google.com; dkim=pass header.i=@redhat.com header.s=mimecast20190719 header.b=Y1n0MszP; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=redhat.com Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S2387562AbgLISzy (ORCPT + 99 others); Wed, 9 Dec 2020 13:55:54 -0500 Received: from us-smtp-delivery-124.mimecast.com ([63.128.21.124]:30276 "EHLO us-smtp-delivery-124.mimecast.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S2387560AbgLISzo (ORCPT ); Wed, 9 Dec 2020 13:55:44 -0500 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com; s=mimecast20190719; t=1607540057; 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=pAnzkkggIin7jYeCuo0D9ShCd/x0gLLXGM9tw9DfkJs=; b=Y1n0MszPX8etkjVh0IlRVvX9JYU0U6YCd52y/2zd4/1A7WDRve9E1Gk5IO/yuWD+Nrmtqg IudHFx610rWyxTTEB2EREYVp+MpTv3ozXjJmUDDnz1asxmcmvAytfkHeWgsmF2j6eojVOb SVfDtjbiut1YgEGcGmG4uidY1cAKt8U= Received: from mimecast-mx01.redhat.com (mimecast-mx01.redhat.com [209.132.183.4]) (Using TLS) by relay.mimecast.com with ESMTP id us-mta-396-wT7oHLPBMnq1hB-gpNuBBA-1; Wed, 09 Dec 2020 13:54:15 -0500 X-MC-Unique: wT7oHLPBMnq1hB-gpNuBBA-1 Received: from smtp.corp.redhat.com (int-mx01.intmail.prod.int.phx2.redhat.com [10.5.11.11]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by mimecast-mx01.redhat.com (Postfix) with ESMTPS id 4BF20966E86; Wed, 9 Dec 2020 18:53:46 +0000 (UTC) Received: from fuller.cnet (ovpn-112-5.gru2.redhat.com [10.97.112.5]) by smtp.corp.redhat.com (Postfix) with ESMTPS id 19EEA63B8C; Wed, 9 Dec 2020 18:53:44 +0000 (UTC) Received: by fuller.cnet (Postfix, from userid 1000) id 7C35C48E58F2; Wed, 9 Dec 2020 13:34:34 -0300 (-03) Date: Wed, 9 Dec 2020 13:34:34 -0300 From: Marcelo Tosatti To: Thomas Gleixner Cc: Maxim Levitsky , kvm@vger.kernel.org, "H. Peter Anvin" , Paolo Bonzini , 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 Message-ID: <20201209163434.GA22851@fuller.cnet> References: <20201203171118.372391-1-mlevitsk@redhat.com> <20201203171118.372391-2-mlevitsk@redhat.com> <20201207232920.GD27492@fuller.cnet> <05aaabedd4aac7d3bce81d338988108885a19d29.camel@redhat.com> <87sg8g2sn4.fsf@nanos.tec.linutronix.de> <20201208181107.GA31442@fuller.cnet> <875z5c2db8.fsf@nanos.tec.linutronix.de> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <875z5c2db8.fsf@nanos.tec.linutronix.de> User-Agent: Mutt/1.10.1 (2018-07-13) X-Scanned-By: MIMEDefang 2.79 on 10.5.11.11 Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Tue, Dec 08, 2020 at 10:33:15PM +0100, Thomas Gleixner wrote: > On Tue, Dec 08 2020 at 15:11, Marcelo Tosatti wrote: > > On Tue, Dec 08, 2020 at 05:02:07PM +0100, Thomas Gleixner wrote: > >> On Tue, Dec 08 2020 at 16:50, Maxim Levitsky wrote: > >> > On Mon, 2020-12-07 at 20:29 -0300, Marcelo Tosatti wrote: > >> >> > +This ioctl allows to reconstruct the guest's IA32_TSC and TSC_ADJUST value > >> >> > +from the state obtained in the past by KVM_GET_TSC_STATE on the same vCPU. > >> >> > + > >> >> > +If 'KVM_TSC_STATE_TIMESTAMP_VALID' is set in flags, > >> >> > +KVM will adjust the guest TSC value by the time that passed since the moment > >> >> > +CLOCK_REALTIME timestamp was saved in the struct and current value of > >> >> > +CLOCK_REALTIME, and set the guest's TSC to the new value. > >> >> > >> >> This introduces the wraparound bug in Linux timekeeping, doesnt it? > >> > >> Which bug? > > > > max_cycles overflow. Sent a message to Maxim describing it. > > Truly helpful. Why the hell did you not talk to me when you ran into > that the first time? Because 1) Users wanted CLOCK_BOOTTIME to stop counting while the VM is paused (so we wanted to stop guest clock when VM is paused anyway). 2) The solution to inject NMIs to the guest seemed overly complicated. > >> For one I have no idea which bug you are talking about and if the bug is > >> caused by the VMM then why would you "fix" it in the guest kernel. > > > > 1) Stop guest, save TSC value of cpu-0 = V. > > 2) Wait for some amount of time = W. > > 3) Start guest, load TSC value with V+W. > > > > Can cause an overflow on Linux timekeeping. > > Yes, because you violate the basic assumption which Linux timekeeping > makes. See the other mail in this thread. > > Thanks, > > tglx