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 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 B7CE8C64E8A for ; Thu, 3 Dec 2020 11:13:28 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [23.128.96.18]) by mail.kernel.org (Postfix) with ESMTP id 4E0F821D91 for ; Thu, 3 Dec 2020 11:13:28 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S2388647AbgLCLN1 (ORCPT ); Thu, 3 Dec 2020 06:13:27 -0500 Received: from us-smtp-delivery-124.mimecast.com ([63.128.21.124]:23656 "EHLO us-smtp-delivery-124.mimecast.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S2387757AbgLCLN1 (ORCPT ); Thu, 3 Dec 2020 06:13:27 -0500 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com; s=mimecast20190719; t=1606993920; 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=Oj9Eb3KtE+2YyHKM1FeeyiYyawdfTwBxc5qATzsgyHM=; b=Mp+26P8jymnLkxpyWSClj4JTaceqhh+stXq+ip/bIwVCe9AOcL1vPHk9iSpjJFXSaQ1EEQ vapBReA8KMU9H8F9QACytSZy240kUUeGllRSXzSXJCZwcZoE5VAXSM3pltgcvQAlbWZz+F pGMyZnaCcWY9o8vfqe6vSnNVV/WDqM8= 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-464-0Ehb4NofNIuuNpcntl7fgQ-1; Thu, 03 Dec 2020 06:11:59 -0500 X-MC-Unique: 0Ehb4NofNIuuNpcntl7fgQ-1 Received: from smtp.corp.redhat.com (int-mx08.intmail.prod.int.phx2.redhat.com [10.5.11.23]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by mimecast-mx01.redhat.com (Postfix) with ESMTPS id 802F780732C; Thu, 3 Dec 2020 11:11:56 +0000 (UTC) Received: from starship (unknown [10.35.206.228]) by smtp.corp.redhat.com (Postfix) with ESMTP id 6787A1A8A0; Thu, 3 Dec 2020 11:11:49 +0000 (UTC) Message-ID: Subject: Re: [PATCH 1/2] KVM: x86: implement KVM_SET_TSC_PRECISE/KVM_GET_TSC_PRECISE From: Maxim Levitsky To: Thomas Gleixner , kvm@vger.kernel.org Cc: Paolo Bonzini , Oliver Upton , Ingo Molnar , Sean Christopherson , open list , Marcelo Tosatti , 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:11:47 +0200 In-Reply-To: <87h7p5fh1m.fsf@nanos.tec.linutronix.de> References: <20201130133559.233242-1-mlevitsk@redhat.com> <20201130133559.233242-2-mlevitsk@redhat.com> <87h7p5fh1m.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: 7bit X-Scanned-By: MIMEDefang 2.84 on 10.5.11.23 Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Tue, 2020-12-01 at 20:43 +0100, Thomas Gleixner wrote: > On Mon, Nov 30 2020 at 15:35, Maxim Levitsky wrote: > > + struct kvm_tsc_info { > > + __u32 flags; > > + __u64 nsec; > > + __u64 tsc; > > + __u64 tsc_adjust; > > + }; > > + > > +flags values for ``struct kvm_tsc_info``: > > + > > +``KVM_TSC_INFO_TSC_ADJUST_VALID`` > > + > > + ``tsc_adjust`` contains valid IA32_TSC_ADJUST value > > Why exposing TSC_ADJUST at all? Just because? It's because we want to reduce the number of cases where KVM's msr/read write behavior differs between guest and host (e.g qemu) writes. TSC and TSC_ADJUST are tied on architectural level, such as chang ing one, changes the other. However for the migration to work we must be able to set each one separately. Currently, KVM does this by turning the host write to TSC_ADJUST into a special case that bypasses the actual TSC adjustment, and just sets this MSR. The next patch in this series, will allow to disable this special behavior, making host TSC_ADJUST write work the same way as in guest. Therefore to still allow to set TSC_ADJUST and TSC independently after migration this ioctl will be used instead. Best regards, Maxim Levitsky > > Thanks, > > tglx >