Received: by 2002:a05:6902:102b:0:0:0:0 with SMTP id x11csp780340ybt; Fri, 26 Jun 2020 11:20:57 -0700 (PDT) X-Google-Smtp-Source: ABdhPJxrIxX5vtZTzt4v1JoLoxldCbEII8NHbJujhiLC6Y0TMVgRp3EaVW637lwfoPFN+1dvclDi X-Received: by 2002:a17:906:3407:: with SMTP id c7mr3638048ejb.284.1593195657750; Fri, 26 Jun 2020 11:20:57 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1593195657; cv=none; d=google.com; s=arc-20160816; b=E7Po5Z+g3zrt4mmNoNi8Xnl5r2AzGfoMqpTGdnrhT5mfE64V6nbAO6cUE3QgSt9pPw BwchCy+tVnLU4s2kpl5Akw8xBj7Q0MOU7u6O/HdboOh38lebH16rUFKg3ESiiQpsICfO I6YoSHaWe3wOQSe6CFT7ELT38uFlJrvDDM7jpcglmCUL1stYjGQ6XLqSNozVflBCtpnF QcCptfMu/FmSJWXSJdqG/Ol4671ltw0VJjJ+QAKpa7RBDY7h8bTAheTOS1rskVJVrfbA 3uPECDVf1uxID3gAJKpVRpCppZZu+Rcpb8XRR2puElsGI6qgdvXzwHBERXI1mFTd532D A58w== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:user-agent:in-reply-to :content-disposition:mime-version:references:message-id:subject:cc :to:from:date:ironport-sdr:ironport-sdr; bh=e3Qlp5tBAy6IgJNqci9uT6NuQHOlftHLdhqQvEOUkrQ=; b=Kio82GALW/8Ws599GGdpU/Ls0yDHKoVl9TTALSiqWV1MsWuuXTwFJLd/ciMjFMxzHR HLKTsGGJegyn/z50A1H8eGdEe3cNG2vAmk5vi+8N6JxqF8ybmTxnwVxlf3Or7RPXg3By 55ZVvbJm0PWEBfGP62DAax6/166QR65uh/oHiZjUnLTwQxwrlcPS2dvOcs7hb62k7+UB U22xKo7/I61OGMKfyJJ09YWzWV0IfpPI7o5fFUH4eTElCLsuLDFGm1s79zG3yy8wolQy KjdESsmIoAFVKY1hN6z72DpAsG7eOTd7wLMw5WkJS18HxVAeTJM/YpU78RNlZ0RPDlx/ mb/w== ARC-Authentication-Results: i=1; mx.google.com; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=fail (p=NONE sp=NONE dis=NONE) header.from=intel.com Return-Path: Received: from vger.kernel.org (vger.kernel.org. [23.128.96.18]) by mx.google.com with ESMTP id dm6si3246043edb.169.2020.06.26.11.20.34; Fri, 26 Jun 2020 11:20:57 -0700 (PDT) Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) client-ip=23.128.96.18; Authentication-Results: mx.google.com; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=fail (p=NONE sp=NONE dis=NONE) header.from=intel.com Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1726403AbgFZSS3 (ORCPT + 99 others); Fri, 26 Jun 2020 14:18:29 -0400 Received: from mga02.intel.com ([134.134.136.20]:56435 "EHLO mga02.intel.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1725913AbgFZSS2 (ORCPT ); Fri, 26 Jun 2020 14:18:28 -0400 IronPort-SDR: xMmZJhzWXjmxOCDj5+N2sUOJAylcQiaC1d+0UyHtsg9bLczcZgEukUfbJhf2RFO0pMOKFojWPV zcX2AchrG+1A== X-IronPort-AV: E=McAfee;i="6000,8403,9664"; a="133807647" X-IronPort-AV: E=Sophos;i="5.75,284,1589266800"; d="scan'208";a="133807647" X-Amp-Result: SKIPPED(no attachment in message) X-Amp-File-Uploaded: False Received: from orsmga004.jf.intel.com ([10.7.209.38]) by orsmga101.jf.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 26 Jun 2020 11:18:21 -0700 IronPort-SDR: zt3o9bkoY2+2CVGUSRNpYgXOxP/x4EH7zmKj1n+lLxhmxrtVehX/6N5gbuv7BcmeTMBznrePPY yMz62I503MXg== X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="5.75,284,1589266800"; d="scan'208";a="424152589" Received: from sjchrist-coffee.jf.intel.com (HELO linux.intel.com) ([10.54.74.152]) by orsmga004.jf.intel.com with ESMTP; 26 Jun 2020 11:18:20 -0700 Date: Fri, 26 Jun 2020 11:18:20 -0700 From: Sean Christopherson To: Peter Xu Cc: Paolo Bonzini , linux-kernel@vger.kernel.org, kvm@vger.kernel.org, Vitaly Kuznetsov Subject: Re: [PATCH 1/2] KVM: X86: Move ignore_msrs handling upper the stack Message-ID: <20200626181820.GG6583@linux.intel.com> References: <20200622220442.21998-1-peterx@redhat.com> <20200622220442.21998-2-peterx@redhat.com> <20200625061544.GC2141@linux.intel.com> <1cebc562-89e9-3806-bb3c-771946fc64f3@redhat.com> <20200625162540.GC3437@linux.intel.com> <20200626180732.GB175520@xz-x1> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20200626180732.GB175520@xz-x1> User-Agent: Mutt/1.5.24 (2015-08-30) Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Fri, Jun 26, 2020 at 02:07:32PM -0400, Peter Xu wrote: > On Thu, Jun 25, 2020 at 09:25:40AM -0700, Sean Christopherson wrote: > > diff --git a/arch/x86/kvm/cpuid.c b/arch/x86/kvm/cpuid.c > > index 5eb618dbf211..64322446e590 100644 > > --- a/arch/x86/kvm/cpuid.c > > +++ b/arch/x86/kvm/cpuid.c > > @@ -1013,9 +1013,9 @@ bool kvm_cpuid(struct kvm_vcpu *vcpu, u32 *eax, u32 *ebx, > > *ebx = entry->ebx; > > *ecx = entry->ecx; > > *edx = entry->edx; > > - if (function == 7 && index == 0) { > > + if (function == 7 && index == 0 && (*ebx | (F(RTM) | F(HLE))) { > > u64 data; > > - if (!__kvm_get_msr(vcpu, MSR_IA32_TSX_CTRL, &data, true) && > > + if (!kvm_get_msr(vcpu, MSR_IA32_TSX_CTRL, &data) && > > (data & TSX_CTRL_CPUID_CLEAR)) > > *ebx &= ~(F(RTM) | F(HLE)); > > } > > > > > > On VMX, MSR_IA32_TSX_CTRL will be added to the so called shared MSR array > > regardless of whether or not it is being advertised to userspace (this is > > a bug in its own right). Using the host_initiated variant means KVM will > > incorrectly bypass VMX's ARCH_CAP_TSX_CTRL_MSR check, i.e. incorrectly > > clear the bits if userspace is being weird and stuffed MSR_IA32_TSX_CTRL > > without advertising it to the guest. > > Btw, would it be more staightforward to check "vcpu->arch.arch_capabilities & > ARCH_CAP_TSX_CTRL_MSR" rather than "*ebx | (F(RTM) | F(HLE))" even if we want > to have such a fix? Not really, That ends up duplicating the check in vmx_get_msr(). From an emulation perspective, this really is a "guest" access to the MSR, in the sense that it the virtual CPU is in the guest domain, i.e. not a god-like entity that gets to break the rules of emulation. The other thing to consider is that SVM doesn't have any knowledge of any of this, so arguably the "ignored msr" crud should get logged for SVM as it's effectively a userspace bug if they've configured the VM to have RTM or HLE on a system that can't possibly support either.