Received: by 2002:a6b:fb09:0:0:0:0:0 with SMTP id h9csp1104044iog; Mon, 13 Jun 2022 21:58:08 -0700 (PDT) X-Google-Smtp-Source: AGRyM1vZ8oePsYjF7biOdFGsyaBKVzR6GaBB74SX7zxukLJmD8sXwQmwv/py+yp+GRpqZOC42IH9 X-Received: by 2002:a17:907:3e1d:b0:711:dc92:e308 with SMTP id hp29-20020a1709073e1d00b00711dc92e308mr2620970ejc.235.1655182687893; Mon, 13 Jun 2022 21:58:07 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1655182687; cv=none; d=google.com; s=arc-20160816; b=ADZICGoQoA1c6ofhLUUN+3Caw7cnGESS0jyPkbaQ++cTKkknJOeG1xkp37nl7oB5Un yH/rKJQ1efKDlDopaKokbKZFeMpHxQJ5e3EZR7yzOqRltHW/vmZpz/0JxGYOpStj5Rzu Yt9rCK4KXRVfNa9BcCwVAdK0SLUAKZ2raTch0PBqafhxw7IeLKswSJ39p/I2tNetZdWr vczsiSBMHDuf5JBmyPnfUxUVef7F2mc/EJNwFawaMvUC8M2zJpOYakpi8E6Bd2+cOpTC w5MiZHN1aQ0+dmRWXzy5cvZ0sF5Msx8Xk66lPbnijCceQkcbF0LO7b2HMLWJGRu+plRY JQXA== 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 :dkim-filter; bh=li+PNz3Vd3GyStPzFitjj/G0JokV2AZ4Fg5xm9celE8=; b=etbCg/A88m8/6ey/wb1BHs1rroqqsdjQwz4tgcZQL403Tgy607x15rbrGZJhW43VoL q2k25j4keO+OvXPAr00G/hM8Ktta0KoQBWnNg4ZhSNXaDElOzIQ/A2wMotgXYHthSY1K 8+jF+HKJeTxMb0Sn2x+f0LhNI7jcE1jvuUq7y/d49sRZoxz17DL5lP4GPpSo1cHUFFRm yW2Ebr+LkLMgJxUdpBD58Z9bBLLyMIS7PqLB3f/g+3jZe5Rve+ThZ3Sc7xiNsYPoT2xT 7k39Nifw3rhL6nY0g7yaW8sM00vFvCVmLGKt56sHqr+U9EFOwocKK/OhT3X6F6PXGXEh 2j4Q== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@linux.microsoft.com header.s=default header.b=JUVUxD6k; 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=NONE sp=NONE dis=NONE) header.from=linux.microsoft.com Return-Path: Received: from out1.vger.email (out1.vger.email. [2620:137:e000::1:20]) by mx.google.com with ESMTP id n9-20020a17090673c900b006ffa19a00c8si9197828ejl.184.2022.06.13.21.57.40; Mon, 13 Jun 2022 21:58:07 -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=@linux.microsoft.com header.s=default header.b=JUVUxD6k; 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=NONE sp=NONE dis=NONE) header.from=linux.microsoft.com Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S237724AbiFNE4I (ORCPT + 99 others); Tue, 14 Jun 2022 00:56:08 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:40266 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S235061AbiFNE4F (ORCPT ); Tue, 14 Jun 2022 00:56:05 -0400 Received: from linux.microsoft.com (linux.microsoft.com [13.77.154.182]) by lindbergh.monkeyblade.net (Postfix) with ESMTP id 5D02D37BD3; Mon, 13 Jun 2022 21:56:04 -0700 (PDT) Received: from anrayabh-desk (unknown [167.220.238.193]) by linux.microsoft.com (Postfix) with ESMTPSA id E050220C29A6; Mon, 13 Jun 2022 21:55:58 -0700 (PDT) DKIM-Filter: OpenDKIM Filter v2.11.0 linux.microsoft.com E050220C29A6 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=linux.microsoft.com; s=default; t=1655182563; bh=li+PNz3Vd3GyStPzFitjj/G0JokV2AZ4Fg5xm9celE8=; h=Date:From:To:Cc:Subject:References:In-Reply-To:From; b=JUVUxD6k6/ZIF1vOVETFrUQMN+dLMESJqPUUnTazK787X47Vi7B/+JJ/g40qmCEG4 xwOeJTn8++aEQXy3VV/um2ElhpGGa356gcKyQ/CgnXpBPruc/qjYOmxnHa8wYw8aw9 2NrDzhL11Fkn3UWwCDSeqBQNGBkyYqfGnAUkAE7Q= Date: Tue, 14 Jun 2022 10:25:52 +0530 From: Anirudh Rayabharam To: Paolo Bonzini Cc: Sean Christopherson , Vitaly Kuznetsov , Wanpeng Li , Jim Mattson , Joerg Roedel , Thomas Gleixner , Ingo Molnar , Borislav Petkov , Dave Hansen , x86@kernel.org, "H. Peter Anvin" , Ilias Stamatis , Maxim Levitsky , mail@anirudhrb.com, kumarpraveen@linux.microsoft.com, wei.liu@kernel.org, robert.bradford@intel.com, liuwe@microsoft.com, kvm@vger.kernel.org, linux-kernel@vger.kernel.org Subject: Re: [PATCH] KVM: nVMX: Don't expose TSC scaling to L1 when on Hyper-V Message-ID: References: <20220613161611.3567556-1-anrayabh@linux.microsoft.com> <592ab920-51f3-4794-331f-8737e1f5b20a@redhat.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <592ab920-51f3-4794-331f-8737e1f5b20a@redhat.com> X-Spam-Status: No, score=-19.8 required=5.0 tests=BAYES_00,DKIM_SIGNED, DKIM_VALID,DKIM_VALID_AU,ENV_AND_HDR_SPF_MATCH,RCVD_IN_DNSWL_MED, SPF_HELO_PASS,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 Mon, Jun 13, 2022 at 06:49:17PM +0200, Paolo Bonzini wrote: > On 6/13/22 18:16, Anirudh Rayabharam wrote: > > + if (!kvm_has_tsc_control) > > + msrs->secondary_ctls_high &= ~SECONDARY_EXEC_TSC_SCALING; > > + > > msrs->secondary_ctls_low = 0; > > msrs->secondary_ctls_high &= > > SECONDARY_EXEC_DESC | > > @@ -6667,8 +6670,7 @@ void nested_vmx_setup_ctls_msrs(struct nested_vmx_msrs *msrs, u32 ept_caps) > > SECONDARY_EXEC_RDRAND_EXITING | > > SECONDARY_EXEC_ENABLE_INVPCID | > > SECONDARY_EXEC_RDSEED_EXITING | > > - SECONDARY_EXEC_XSAVES | > > - SECONDARY_EXEC_TSC_SCALING; > > + SECONDARY_EXEC_XSAVES; > > /* > > This is wrong because it _always_ disables SECONDARY_EXEC_TSC_SCALING, > even if kvm_has_tsc_control == true. The MSR actually allows 1-setting of the "use TSC scaling" control. So this line is redundant anyway. > > That said, I think a better implementation of this patch is to just add > a version of evmcs_sanitize_exec_ctrls that takes a struct > nested_vmx_msrs *, and call it at the end of nested_vmx_setup_ctl_msrs like > > evmcs_sanitize_nested_vmx_vsrs(msrs); Sanitize at the end might not work because I see some cases in nested_vmx_setup_ctls_msrs() where we want to expose some things to L1 even though the hardware doesn't support it. > > Even better (but I cannot "mentally test it" offhand) would be just > > diff --git a/arch/x86/kvm/vmx/vmx.c b/arch/x86/kvm/vmx/vmx.c > index e802f71a9e8d..b3425ce835c5 100644 > --- a/arch/x86/kvm/vmx/vmx.c > +++ b/arch/x86/kvm/vmx/vmx.c > @@ -1862,7 +1862,7 @@ int vmx_get_msr(struct kvm_vcpu *vcpu, struct msr_data *msr_info) > * sanity checking and refuse to boot. Filter all unsupported > * features out. > */ > - if (!msr_info->host_initiated && > + if (static_branch_unlikely(&enable_evmcs) || > vmx->nested.enlightened_vmcs_enabled) > nested_evmcs_filter_control_msr(msr_info->index, > &msr_info->data); I will try this. Thanks, Anirudh. > > I cannot quite understand the host_initiated check, so I'll defer to > Vitaly on why it is needed. Most likely, removing it would cause some > warnings in QEMU with e.g. "-cpu Haswell,+vmx"; but I think it's a > userspace bug and we should remove that part of the condition. You > don't need to worry about that part, we'll cross that bridge if the > above patch works for your case. > > Thanks, > > Paolo