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=-7.2 required=3.0 tests=BAYES_00,DKIMWL_WL_HIGH, DKIM_SIGNED,DKIM_VALID,DKIM_VALID_AU,HEADER_FROM_DIFFERENT_DOMAINS, MAILING_LIST_MULTI,SPF_HELO_NONE,SPF_PASS,URIBL_BLOCKED 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 42497C64E8A for ; Thu, 3 Dec 2020 11:59:07 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [23.128.96.18]) by mail.kernel.org (Postfix) with ESMTP id D43CA2086A for ; Thu, 3 Dec 2020 11:59:06 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1730192AbgLCL6p (ORCPT ); Thu, 3 Dec 2020 06:58:45 -0500 Received: from us-smtp-delivery-124.mimecast.com ([216.205.24.124]:20183 "EHLO us-smtp-delivery-124.mimecast.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1726360AbgLCL6p (ORCPT ); Thu, 3 Dec 2020 06:58:45 -0500 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com; s=mimecast20190719; t=1606996639; 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: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references; bh=uvudTwkZlrk5cjZrGWhnLWxf/bDsuqFy86ZB03kMeqU=; b=TLRUREJOFjYpa8oCq4Q5L3Mp1nRWVd0bbAX/sZIXro3bMzeIdDbKqjgPr5y8zvpjeK4WJJ UJ8NVbhkrM2NlMav5hsJo3s+ZRTAuBTu5B/A/YdSiYmafUJ1zLmx4fnxyasxIsuk3JwXU3 qQSCc0+QW5SGwjOQ3NAMSjEXd1lvYOw= 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-537-RZmLZlsOMP2e65EnnaD2SQ-1; Thu, 03 Dec 2020 06:57:14 -0500 X-MC-Unique: RZmLZlsOMP2e65EnnaD2SQ-1 Received: from smtp.corp.redhat.com (int-mx06.intmail.prod.int.phx2.redhat.com [10.5.11.16]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by mimecast-mx01.redhat.com (Postfix) with ESMTPS id 78517100A64D; Thu, 3 Dec 2020 11:57:12 +0000 (UTC) Received: from starship (unknown [10.35.206.228]) by smtp.corp.redhat.com (Postfix) with ESMTP id A2BA25C1B4; Thu, 3 Dec 2020 11:57:06 +0000 (UTC) Message-ID: <0d8c407cc81bedc9a344646978c857d26f2b5be8.camel@redhat.com> Subject: Re: [PATCH 0/2] RFC: Precise TSC migration From: Maxim Levitsky To: Andy Lutomirski , Thomas Gleixner Cc: Marcelo Tosatti , kvm@vger.kernel.org, Paolo Bonzini , Oliver Upton , Ingo Molnar , Sean Christopherson , open list , Jonathan Corbet , Wanpeng Li , Borislav Petkov , Jim Mattson , "H. Peter Anvin" , "open list:DOCUMENTATION" , Joerg Roedel , "maintainer:X86 ARCHITECTURE (32-BIT AND 64-BIT)" , Vitaly Kuznetsov Date: Thu, 03 Dec 2020 13:57:04 +0200 In-Reply-To: References: <874kl5hbgp.fsf@nanos.tec.linutronix.de> Content-Type: text/plain; charset="UTF-8" User-Agent: Evolution 3.36.3 (3.36.3-1.fc32) MIME-Version: 1.0 Content-Transfer-Encoding: 8bit X-Scanned-By: MIMEDefang 2.79 on 10.5.11.16 Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Tue, 2020-12-01 at 08:19 -0800, Andy Lutomirski wrote: > > On Dec 1, 2020, at 6:01 AM, Thomas Gleixner wrote: > > > > On Mon, Nov 30 2020 at 16:16, Marcelo Tosatti wrote: > > > Not really. The synchronization logic tries to sync TSCs during > > > BIOS boot (and CPU hotplug), because the TSC values are loaded > > > sequentially, say: > > > > > > CPU realtime TSC val > > > vcpu0 0 usec 0 > > > vcpu1 100 usec 0 > > > vcpu2 200 usec 0 > > > > That's nonsense, really. > > > > > And we'd like to see all vcpus to read the same value at all times. > > > > Providing guests with a synchronized and stable TSC on a host with a > > synchronized and stable TSC is trivial. > > > > Write the _same_ TSC offset to _all_ vcpu control structs and be done > > with it. It's not rocket science. > > > > The guest TSC read is: > > > > hostTSC + vcpu_offset > > > > So if the host TSC is synchronized then the guest TSCs are synchronized > > as well. > > > > If the host TSC is not synchronized, then don't even try. > > This reminds me: if you’re adding a new kvm feature that tells the guest that the TSC works well, could you perhaps only have one structure for all vCPUs in the same guest? I won't mind doing this, but this might be too much work for too little gain. IMHO, modern hosts don't need the kvmclock in the first place, and should just expose the TSC to the guest together with the invtsc bit. Best regards, Maxim Levitsky > > > Thanks, > > > > tglx