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=-13.3 required=3.0 tests=BAYES_00,DKIMWL_WL_MED, DKIM_SIGNED,DKIM_VALID,DKIM_VALID_AU,HEADER_FROM_DIFFERENT_DOMAINS, MAILING_LIST_MULTI,SPF_HELO_NONE,SPF_PASS,USER_IN_DEF_DKIM_WL 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 2D5B3C433FE for ; Thu, 10 Dec 2020 18:14:49 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [23.128.96.18]) by mail.kernel.org (Postfix) with ESMTP id D54D723C44 for ; Thu, 10 Dec 2020 18:14:48 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S2392854AbgLJSOX (ORCPT ); Thu, 10 Dec 2020 13:14:23 -0500 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:39308 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S2392768AbgLJSOG (ORCPT ); Thu, 10 Dec 2020 13:14:06 -0500 Received: from mail-lj1-x243.google.com (mail-lj1-x243.google.com [IPv6:2a00:1450:4864:20::243]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id C40D1C06179C for ; Thu, 10 Dec 2020 10:13:25 -0800 (PST) Received: by mail-lj1-x243.google.com with SMTP id s11so7751478ljp.4 for ; Thu, 10 Dec 2020 10:13:25 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=et/f3RjbZyuZ9JQ6heD+AHbTOUp1bUm1tRV1afS0ffo=; b=v19m+I06m7joT/AcjLb0tMF6lAJ5V8z+FKPko5snmNCFHTPv3bdEHyAb+gPnz4se2R +INSchsHDnXs6CHDwyr1OX9D7lgsQLp0+HpPcFPNqyTm2K0h1yTcKG2yEcdN7vKYkDxZ /r5QdIJlQZDG0tU68JwmcZR5S+hOa0hDvt1zdO/fcLCeGHukWpFmaF2PxrCHxWjHeiE0 gaBxJ0NFtD5oc7137LS/skmzqx28uL8EH24BWt9F/nsw2pVhq6uhRBMeYbwhLkauiQ4g kiZ0QTjeICTynLVhctWqyARIy3ebvmQcwkfwaIqdz4p+gTYl4zTCqUoRiuFb3GKZl3vD QPGQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=et/f3RjbZyuZ9JQ6heD+AHbTOUp1bUm1tRV1afS0ffo=; b=H4aVGqmsj+KTrSRZggFOyhhP19Yj+1QrHczPd76iUzSxMu0HpKwjSqTh0utl/K0dOa b4DCOYABY44rju+RkwWiv8jeEU3pFLrFUzfzPRY0PKdoPxvRrGGunJTDq57f0vg/5FL1 Qu5/7Mlz/DohLOzPn2BP0IXZ7wwRYb6cpbr/yBvuKbpIvm4QEgSGoBv3erGcwDJzEg4W 8NJLY4n6Pgi4AlFAxk8RASG4rNUEFHFdkkO7slqYEXtpyZwxJ/irJE27j6Fvm29hEO5m oT7p9sJWjw/Q3k12o3oL5cyXnsyZrKT/Q33pgxuqe8+xkuIH+6INZ6Tu+3g/27QnSCGF c40Q== X-Gm-Message-State: AOAM532CY50fZt7xuSXHDwlXKmVL+msCDm8/3RdXg6WJoXsn3EyaAQO8 3xU9BSngKmT6H6K9MQ8OtBGSjtxP2ClWnNRiZqccrw== X-Google-Smtp-Source: ABdhPJz6mHpgMVqJUnrdAcxtrWUH9N8Z8HVVDmP+wLkbZLA/HDgRzT6WQeKWJ0VSyM8PZFXMwJ9fVjlXIYWpFEccPKQ= X-Received: by 2002:a2e:961a:: with SMTP id v26mr3699249ljh.314.1607624003934; Thu, 10 Dec 2020 10:13:23 -0800 (PST) MIME-Version: 1.0 References: <9389c1198da174bcc9483d6ebf535405aa8bdb45.camel@redhat.com> In-Reply-To: From: Oliver Upton Date: Thu, 10 Dec 2020 12:13:12 -0600 Message-ID: Subject: Re: [PATCH v2 1/3] KVM: x86: implement KVM_{GET|SET}_TSC_STATE To: Paolo Bonzini Cc: Andy Lutomirski , Maxim Levitsky , Thomas Gleixner , Marcelo Tosatti , 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 , "open list:DOCUMENTATION" Content-Type: text/plain; charset="UTF-8" Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Thu, Dec 10, 2020 at 12:05 PM Paolo Bonzini wrote: > > On 10/12/20 18:59, Oliver Upton wrote: > > However, I don't believe we can assume the guest's TSCs to be synchronized, > > even if sane guests will never touch them. In this case, I think a per-vCPU > > ioctl is still warranted, allowing userspace to get at the guest CPU adjust > > component of Thomas' equation below (paraphrased): > > > > TSC guest CPU = host tsc base + guest base offset + guest CPU adjust > > Right now that would be: > > - KVM_GET_TSC_STATE (vm) returns host tsc base + guest base offset (plus > the associated time) > > - KVM_GET_MSR *without* KVM_X86_QUIRK_TSC_HOST_ACCESS for guest CPU adjust > > and the corresponding SET ioctls. What am *I* missing? > > > Alternatively, a write from userspace to the guest's IA32_TSC_ADJUST with > > KVM_X86_QUIRK_TSC_HOST_ACCESS could have the same effect, but that seems to be > > problematic for a couple reasons. First, depending on the guest's CPUID the > > TSC_ADJUST MSR may not even be available, meaning that the guest could've used > > IA32_TSC to adjust the TSC (eww). > > Indeed, the host should always be able to read/write IA32_TSC and > IA32_TSC_ADJUST. So long as it is guaranteed that guest manipulations of IA32_TSC are reflected in IA32_TSC_ADJUST even if it isn't in the guest's CPUID, then this seems OK. I think having clear documentation on this subject is also necessary, as we're going to rely on the combination of KVM_{GET,SET}_TSC_STATE, disabling KVM_X86_QUIRK_TSC_HOST_ACCESS, and userspace reading/writing a possibly hidden MSR to pull this off right. -- Thanks, Oliver > Thanks, > > Paolo > > > Second, userspace replaying writes to IA32_TSC > > (in the case IA32_TSC_ADJUST doesn't exist for the guest) seems_very_ > > unlikely to work given all the magic handling that KVM does for > > writes to it. > > > > Is this roughly where we are or have I entirely missed the mark?:-) >