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=-2.3 required=3.0 tests=HEADER_FROM_DIFFERENT_DOMAINS, MAILING_LIST_MULTI,SPF_HELO_NONE,SPF_PASS,USER_AGENT_SANE_1 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 7ED92C55199 for ; Mon, 27 Apr 2020 17:04:30 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [23.128.96.18]) by mail.kernel.org (Postfix) with ESMTP id 645922076A for ; Mon, 27 Apr 2020 17:04:30 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1726238AbgD0RE1 (ORCPT ); Mon, 27 Apr 2020 13:04:27 -0400 Received: from mga04.intel.com ([192.55.52.120]:14897 "EHLO mga04.intel.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1726177AbgD0RE1 (ORCPT ); Mon, 27 Apr 2020 13:04:27 -0400 IronPort-SDR: gfPPhjEYOuBazB9szlvnZePeXJEr1AIXg9T31Pf4iBeRYxI6TNXm70QDt4JYm4hZIEzo57/NSv RWSMv9BHMc+w== X-Amp-Result: SKIPPED(no attachment in message) X-Amp-File-Uploaded: False Received: from fmsmga008.fm.intel.com ([10.253.24.58]) by fmsmga104.fm.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 27 Apr 2020 10:04:26 -0700 IronPort-SDR: ZNs7H9Ukk8zyGkr/Our9PzDLtp6UUPJ+NIkqAv3hbZUbsuFEXt8xARyOBxSoOy8sC9ppr40C+E bLErdy4U/+bA== X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="5.73,324,1583222400"; d="scan'208";a="248928096" Received: from sjchrist-coffee.jf.intel.com (HELO linux.intel.com) ([10.54.74.202]) by fmsmga008.fm.intel.com with ESMTP; 27 Apr 2020 10:04:26 -0700 Date: Mon, 27 Apr 2020 10:04:26 -0700 From: Sean Christopherson To: Yang Weijiang Cc: kvm@vger.kernel.org, linux-kernel@vger.kernel.org, pbonzini@redhat.com, jmattson@google.com, yu.c.zhang@linux.intel.com Subject: Re: [PATCH v11 3/9] KVM: VMX: Set host/guest CET states for vmexit/vmentry Message-ID: <20200427170426.GH14870@linux.intel.com> References: <20200326081847.5870-1-weijiang.yang@intel.com> <20200326081847.5870-4-weijiang.yang@intel.com> <20200423171741.GH17824@linux.intel.com> <20200424143510.GH24039@local-michael-cet-test> <20200424144941.GC30013@linux.intel.com> <20200425092021.GB26221@local-michael-cet-test> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20200425092021.GB26221@local-michael-cet-test> User-Agent: Mutt/1.5.24 (2015-08-30) Sender: kvm-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: kvm@vger.kernel.org On Sat, Apr 25, 2020 at 05:20:21PM +0800, Yang Weijiang wrote: > On Fri, Apr 24, 2020 at 07:49:41AM -0700, Sean Christopherson wrote: > > On Fri, Apr 24, 2020 at 10:35:10PM +0800, Yang Weijiang wrote: > > > On Thu, Apr 23, 2020 at 10:17:41AM -0700, Sean Christopherson wrote: > > > > On Thu, Mar 26, 2020 at 04:18:40PM +0800, Yang Weijiang wrote: > > > > > @@ -7140,8 +7175,23 @@ static void vmx_cpuid_update(struct kvm_vcpu *vcpu) > > > > > } > > > > > > > > > > if (guest_cpuid_has(vcpu, X86_FEATURE_SHSTK) || > > > > > - guest_cpuid_has(vcpu, X86_FEATURE_IBT)) > > > > > + guest_cpuid_has(vcpu, X86_FEATURE_IBT)) { > > > > > vmx_update_intercept_for_cet_msr(vcpu); > > > > > + > > > > > + if (cpu_has_cet_guest_load_ctrl() && is_cet_supported(vcpu)) > > > > > + vm_entry_controls_setbit(to_vmx(vcpu), > > > > > + VM_ENTRY_LOAD_GUEST_CET_STATE); > > > > > + else > > > > > + vm_entry_controls_clearbit(to_vmx(vcpu), > > > > > + VM_ENTRY_LOAD_GUEST_CET_STATE); > > > > > + > > > > > + if (cpu_has_cet_host_load_ctrl() && is_cet_supported(vcpu)) > > > > > + vm_exit_controls_setbit(to_vmx(vcpu), > > > > > + VM_EXIT_LOAD_HOST_CET_STATE); > > > > > + else > > > > > + vm_exit_controls_clearbit(to_vmx(vcpu), > > > > > + VM_EXIT_LOAD_HOST_CET_STATE); > > > > > > > > As above, I think this can be done in vmx_set_cr4(). > > > > > > > Hmm, it's in vmx_set_cr4() in early versions, OK, will move them back. > > > > Did I advise you to move them out of vmx_set_cr4()? It's entirely possible > > I forgot some detail since the last time I reviewed this series. > Things are always changing, I'm willing to change any part of the patch > before it's landed :-). I'm worried that there was a reason for requesting the logic to be moved out vmx_set_cr4() that I've since forgotten. I'll see if I can dredge up the old mail.