Received: by 2002:a05:6358:489b:b0:bb:da1:e618 with SMTP id x27csp5339290rwn; Mon, 12 Sep 2022 07:41:54 -0700 (PDT) X-Google-Smtp-Source: AA6agR5aQbCk9zPsE3j5bbN/h/UaJhl5tc04ElqsmPPoz7Nt4071FiQNv2oQpnlmMuu8TAcrLKir X-Received: by 2002:a63:68f:0:b0:434:abbe:caec with SMTP id 137-20020a63068f000000b00434abbecaecmr23635240pgg.363.1662993713958; Mon, 12 Sep 2022 07:41:53 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1662993713; cv=none; d=google.com; s=arc-20160816; b=roA/20D1t2K6crv0KoeN6KKDCv1hqEKQMQYqQA5lMlQZ40MmOYs3bkElZHIeAW4wKe nHmbhHLCpGiNM/rTdIRlxRDbF43vq1lrUhDDv65VCflC/5P2CkReV3qxYdaq9ajGClUu bTNzDykZ9LYvFAA/s4u4DVgPZs7WsN2GHHl78s0o8chVu7N0WTe7HbhVOZ205IM7/opV ivkXuSEPQj3F/hHo8qEVrvd9rjxbQqtstJKB/4wpkHhGbM/J4r8569EwxiT4GoYXEhef zrdOcFgxDJb+G8/LkaZf322bDZRPif2lhodxi9Nke0lYZg3Vj8nOw5v4SDmJ8ifqgs8P siZA== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:in-reply-to:content-disposition:mime-version :references:message-id:subject:cc:to:from:date:dkim-signature; bh=/4RJpDcHTnyeNgFQ8a9TRZhL70VzQaaPYPhwoY3FyM0=; b=0OELFZvwImRBIk/tNwy5smmwqHwPMvz85uboyOAtJEN7uZhRrHcI/uot9Dd2PC2q02 EeFhOtPIuVzxxH2tXgrFsb3srt/N/of44VFfuL4V/XYciQwkWFSQjhIs7gk2uM55czef t8hT6+fXW5UbmnwTh1NY/uITpfcosxS+iYVSx/Ri9anpBJ3qr2rn+xAysPluD4RCBd2q SXKA8iiXaA8DXiqu2ZzZvo+X6ViNqkUWFyqINMWf/0/UOQCCaXd3syx8nrpDLhFs5DsA CrYi4oG7c/SVqC95T1pVFdB81srW/JDGpM59kWx6+gGOVju97w4d3pQRTfky+hqrmW+c dhww== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@google.com header.s=20210112 header.b="TT/m6xXU"; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=REJECT sp=REJECT dis=NONE) header.from=google.com Return-Path: Received: from out1.vger.email (out1.vger.email. [2620:137:e000::1:20]) by mx.google.com with ESMTP id f17-20020a056a00239100b005373f74e4e3si8632737pfc.369.2022.09.12.07.41.42; Mon, 12 Sep 2022 07:41:53 -0700 (PDT) Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) client-ip=2620:137:e000::1:20; Authentication-Results: mx.google.com; dkim=pass header.i=@google.com header.s=20210112 header.b="TT/m6xXU"; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=REJECT sp=REJECT dis=NONE) header.from=google.com Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S229549AbiILNwJ (ORCPT + 99 others); Mon, 12 Sep 2022 09:52:09 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:42670 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S229764AbiILNwG (ORCPT ); Mon, 12 Sep 2022 09:52:06 -0400 Received: from mail-pl1-x62d.google.com (mail-pl1-x62d.google.com [IPv6:2607:f8b0:4864:20::62d]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 01E0230F55 for ; Mon, 12 Sep 2022 06:52:03 -0700 (PDT) Received: by mail-pl1-x62d.google.com with SMTP id d12so8658396plr.6 for ; Mon, 12 Sep 2022 06:52:03 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20210112; h=in-reply-to:content-disposition:mime-version:references:message-id :subject:cc:to:from:date:from:to:cc:subject:date; bh=/4RJpDcHTnyeNgFQ8a9TRZhL70VzQaaPYPhwoY3FyM0=; b=TT/m6xXUYiAmG34jqjtSaXSDf2ErMTttL2bICiiudLeZULeuX9LZLKa7GvR7pU2eYJ A1cV+HEYw8E5U25Kal7cWv7o99RJwGhJflS8tDsgsiUO1R1fpfV/9AxP5XM/9VmSIWHF LndIKnjDB/TfV/2LGrMB8m5SesZ1gd2MrLsqRlUsHNNHSe9pqf1Gb5D6AVAPag024n66 uUqxwN3viPsLuJlP2jaGQRJuJgnS8GeGRCv+5Pw+yIzOxndmffTgkEPdrPL6kA5LGdH6 oDq7Yx5RSg03t+LYPloL5LJTKfz89eTCfFmEperKI1J9qvMU5wEdFQ096hBYWRMRNCWW Bf9g== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=in-reply-to:content-disposition:mime-version:references:message-id :subject:cc:to:from:date:x-gm-message-state:from:to:cc:subject:date; bh=/4RJpDcHTnyeNgFQ8a9TRZhL70VzQaaPYPhwoY3FyM0=; b=vFRVQsg3OrUoz1opjTQ/2nLO0SuzZILyiXvryMtpcoZBp3rxRVwmo/wikiXMmEMz88 2MMcMrJ2ODDsMLX7alX2Jzq5aWcnem6q/b6P35cmRcBtr1UUH3SUtwAVuXdRmjITD+vT +Eoe9tQo+v47NqmaWHVNT+/xhfQnDDtlD32q/YondGM9QmXAugXNkotPk/OYQDprm6Ak 67QKoefC7HH0QZZLT0Wtpk9AdU870kH+sVcr41Ev0v+X0GFT7B7BTf0vNkL3PYL6v+IJ ZV21laFiIHV7etFVgsDRirVd02KNSpncOC/3uJQ85HDnH9my8qGh4RMFhwmbH2bEI6T9 XZow== X-Gm-Message-State: ACgBeo0WoC9ILimysjYj/LkcqU6oObrzKooW1bX4EZ3TZLMYGJq/5gu1 TTwZCaXPqFSDI92bEaGuA3Kfyw== X-Received: by 2002:a17:903:2285:b0:177:ab99:9e5 with SMTP id b5-20020a170903228500b00177ab9909e5mr25087264plh.121.1662990722436; Mon, 12 Sep 2022 06:52:02 -0700 (PDT) Received: from google.com (7.104.168.34.bc.googleusercontent.com. [34.168.104.7]) by smtp.gmail.com with ESMTPSA id n9-20020a170902e54900b00174be817124sm6041785plf.221.2022.09.12.06.52.01 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Mon, 12 Sep 2022 06:52:02 -0700 (PDT) Date: Mon, 12 Sep 2022 13:51:58 +0000 From: Sean Christopherson To: Vitaly Kuznetsov Cc: kvm@vger.kernel.org, Paolo Bonzini , Wanpeng Li , Jim Mattson , Michael Kelley , Maxim Levitsky , linux-hyperv@vger.kernel.org, linux-kernel@vger.kernel.org Subject: Re: [PATCH v2 1/3] KVM: x86: Hyper-V invariant TSC control Message-ID: References: <20220831085009.1627523-1-vkuznets@redhat.com> <20220831085009.1627523-2-vkuznets@redhat.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20220831085009.1627523-2-vkuznets@redhat.com> X-Spam-Status: No, score=-17.6 required=5.0 tests=BAYES_00,DKIMWL_WL_MED, DKIM_SIGNED,DKIM_VALID,DKIM_VALID_AU,DKIM_VALID_EF, ENV_AND_HDR_SPF_MATCH,RCVD_IN_DNSWL_NONE,SPF_HELO_NONE,SPF_PASS, T_SCC_BODY_TEXT_LINE,USER_IN_DEF_DKIM_WL,USER_IN_DEF_SPF_WL autolearn=ham autolearn_force=no version=3.4.6 X-Spam-Checker-Version: SpamAssassin 3.4.6 (2021-04-09) on lindbergh.monkeyblade.net Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Wed, Aug 31, 2022, Vitaly Kuznetsov wrote: > Normally, genuine Hyper-V doesn't expose architectural invariant TSC > (CPUID.80000007H:EDX[8]) to its guests by default. A special PV MSR > (HV_X64_MSR_TSC_INVARIANT_CONTROL, 0x40000118) and corresponding CPUID > feature bit (CPUID.0x40000003.EAX[15]) were introduced. When bit 0 of the > PV MSR is set, invariant TSC bit starts to show up in CPUID. When the > feature is exposed to Hyper-V guests, reenlightenment becomes unneeded. > > Add the feature to KVM. Keep CPUID output intact when the feature > wasn't exposed to L1 and implement the required logic for hiding > invariant TSC when the feature was exposed and invariant TSC control > MSR wasn't written to. Copy genuine Hyper-V behavior and forbid to > disable the feature once it was enabled. > > For the reference, for linux guests, support for the feature was added > in commit dce7cd62754b ("x86/hyperv: Allow guests to enable InvariantTSC"). > > Signed-off-by: Vitaly Kuznetsov > --- > arch/x86/include/asm/kvm_host.h | 1 + > arch/x86/kvm/cpuid.c | 7 +++++++ > arch/x86/kvm/hyperv.c | 19 +++++++++++++++++++ > arch/x86/kvm/hyperv.h | 15 +++++++++++++++ > arch/x86/kvm/x86.c | 4 +++- > 5 files changed, 45 insertions(+), 1 deletion(-) > > diff --git a/arch/x86/include/asm/kvm_host.h b/arch/x86/include/asm/kvm_host.h > index 2c96c43c313a..9098187e13aa 100644 > --- a/arch/x86/include/asm/kvm_host.h > +++ b/arch/x86/include/asm/kvm_host.h > @@ -1021,6 +1021,7 @@ struct kvm_hv { > u64 hv_reenlightenment_control; > u64 hv_tsc_emulation_control; > u64 hv_tsc_emulation_status; > + u64 hv_invtsc; For consistency with the other fields, should this be hv_tsc_invariant_control? > > /* How many vCPUs have VP index != vCPU index */ > atomic_t num_mismatched_vp_indexes; > diff --git a/arch/x86/kvm/cpuid.c b/arch/x86/kvm/cpuid.c > index 75dcf7a72605..8ccd45fd66a9 100644 > --- a/arch/x86/kvm/cpuid.c > +++ b/arch/x86/kvm/cpuid.c > @@ -1444,6 +1444,13 @@ bool kvm_cpuid(struct kvm_vcpu *vcpu, u32 *eax, u32 *ebx, > (data & TSX_CTRL_CPUID_CLEAR)) > *ebx &= ~(F(RTM) | F(HLE)); > } > + /* > + * Filter out invariant TSC (CPUID.80000007H:EDX[8]) for Hyper-V > + * guests if needed. > + */ > + if (function == 0x80000007 && kvm_hv_invtsc_filtered(vcpu)) This can be an else-if. Kinda weird, but it could be written as else if (function = 0x80000007) { if (kvm_hv_invtsc_filtered(vcpu)) *edx &= ~SF(CONSTANT_TSC) } to make it a pure function+index check. > + *edx &= ~(1 << 8); Ugh, scattered. Can you add a kvm_only_cpuid_leafs entry so that the bit doesn't have to be open coded? > + > } else { > *eax = *ebx = *ecx = *edx = 0; > /* > diff --git a/arch/x86/kvm/hyperv.c b/arch/x86/kvm/hyperv.c > index ed804447589c..df90cd7501b9 100644 > --- a/arch/x86/kvm/hyperv.c > +++ b/arch/x86/kvm/hyperv.c > @@ -991,6 +991,7 @@ static bool kvm_hv_msr_partition_wide(u32 msr) > case HV_X64_MSR_REENLIGHTENMENT_CONTROL: > case HV_X64_MSR_TSC_EMULATION_CONTROL: > case HV_X64_MSR_TSC_EMULATION_STATUS: > + case HV_X64_MSR_TSC_INVARIANT_CONTROL: > case HV_X64_MSR_SYNDBG_OPTIONS: > case HV_X64_MSR_SYNDBG_CONTROL ... HV_X64_MSR_SYNDBG_PENDING_BUFFER: > r = true; > @@ -1275,6 +1276,9 @@ static bool hv_check_msr_access(struct kvm_vcpu_hv *hv_vcpu, u32 msr) > case HV_X64_MSR_TSC_EMULATION_STATUS: > return hv_vcpu->cpuid_cache.features_eax & > HV_ACCESS_REENLIGHTENMENT; > + case HV_X64_MSR_TSC_INVARIANT_CONTROL: > + return hv_vcpu->cpuid_cache.features_eax & > + HV_ACCESS_TSC_INVARIANT; > case HV_X64_MSR_CRASH_P0 ... HV_X64_MSR_CRASH_P4: > case HV_X64_MSR_CRASH_CTL: > return hv_vcpu->cpuid_cache.features_edx & > @@ -1402,6 +1406,17 @@ static int kvm_hv_set_msr_pw(struct kvm_vcpu *vcpu, u32 msr, u64 data, > if (!host) > return 1; > break; > + case HV_X64_MSR_TSC_INVARIANT_CONTROL: > + /* Only bit 0 is supported */ > + if (data & ~BIT_ULL(0)) Can a #define be added instead of open coding bit 0? > + return 1; > + Doesn't the host CPUID need to be honored on writes from the guest? > + /* The feature can't be disabled from the guest */ > + if (!host && hv->hv_invtsc && !data) > + return 1; > + > + hv->hv_invtsc = data; > + break; > case HV_X64_MSR_SYNDBG_OPTIONS: > case HV_X64_MSR_SYNDBG_CONTROL ... HV_X64_MSR_SYNDBG_PENDING_BUFFER: > return syndbg_set_msr(vcpu, msr, data, host); > @@ -1577,6 +1592,9 @@ static int kvm_hv_get_msr_pw(struct kvm_vcpu *vcpu, u32 msr, u64 *pdata, > case HV_X64_MSR_TSC_EMULATION_STATUS: > data = hv->hv_tsc_emulation_status; > break; > + case HV_X64_MSR_TSC_INVARIANT_CONTROL: > + data = hv->hv_invtsc; > + break; > case HV_X64_MSR_SYNDBG_OPTIONS: > case HV_X64_MSR_SYNDBG_CONTROL ... HV_X64_MSR_SYNDBG_PENDING_BUFFER: > return syndbg_get_msr(vcpu, msr, pdata, host); > @@ -2497,6 +2515,7 @@ int kvm_get_hv_cpuid(struct kvm_vcpu *vcpu, struct kvm_cpuid2 *cpuid, > ent->eax |= HV_MSR_REFERENCE_TSC_AVAILABLE; > ent->eax |= HV_ACCESS_FREQUENCY_MSRS; > ent->eax |= HV_ACCESS_REENLIGHTENMENT; > + ent->eax |= HV_ACCESS_TSC_INVARIANT; > > ent->ebx |= HV_POST_MESSAGES; > ent->ebx |= HV_SIGNAL_EVENTS; > diff --git a/arch/x86/kvm/hyperv.h b/arch/x86/kvm/hyperv.h > index da2737f2a956..1a6316ab55eb 100644 > --- a/arch/x86/kvm/hyperv.h > +++ b/arch/x86/kvm/hyperv.h > @@ -133,6 +133,21 @@ static inline bool kvm_hv_has_stimer_pending(struct kvm_vcpu *vcpu) > HV_SYNIC_STIMER_COUNT); > } > > +/* > + * With HV_ACCESS_TSC_INVARIANT feature, invariant TSC (CPUID.80000007H:EDX[8]) > + * is only observed after HV_X64_MSR_TSC_INVARIANT_CONTROL was written to. > + */ > +static inline bool kvm_hv_invtsc_filtered(struct kvm_vcpu *vcpu) Can this be more strongly worded, e.g. maybe kvm_hv_is_invtsc_disabled()? "Filtered" doesn't strictly mean disabled and makes it sound like there's something else that needs to act on the "filtering" > +{ > + struct kvm_vcpu_hv *hv_vcpu = to_hv_vcpu(vcpu); > + struct kvm_hv *hv = to_kvm_hv(vcpu->kvm); > + > + if (hv_vcpu && hv_vcpu->cpuid_cache.features_eax & HV_ACCESS_TSC_INVARIANT) Ah, I almost missed the inner check. Can you write this as: if (!hv_vcpu) return false; so that the potentially postive/happy path is at the end? I.e. follow the common pattern of: if (!something) return -ERRNO; return 0; > + return !hv->hv_invtsc; Kinda silly, but I think it's worth checking the exact bit here. I don't see how the TSC can get more invariant, but if another bit is added, this could silently break. And probably no need to grab to_kvm_v() locally. return to_kvm_hv(vcpu->kvm)->hv_invtsc; > + > + return false; Shouldn't this be "return true" if HyperV is enabled but doesn't have the CPUID bit set? I assume the expectation is that host userspace won't set the common INVTSC flag without also setting HV_ACCESS_TSC_INVARIANT, but it's confusing logic as is. All in all, I think this? if (!hv_vcpu) return false; return hv_vcpu->cpuid_cache.features_eax & HV_ACCESS_TSC_INVARIANT && to_kvm_hv(vcpu->kvm)->hv_invtsc & BIT(0); > +} > + > void kvm_hv_process_stimers(struct kvm_vcpu *vcpu); > > void kvm_hv_setup_tsc_page(struct kvm *kvm,