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.2 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 0FD37C43603 for ; Wed, 18 Dec 2019 13:54:16 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [209.132.180.67]) by mail.kernel.org (Postfix) with ESMTP id E39E72176D for ; Wed, 18 Dec 2019 13:54:15 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1726977AbfLRNyH (ORCPT ); Wed, 18 Dec 2019 08:54:07 -0500 Received: from mga11.intel.com ([192.55.52.93]:5017 "EHLO mga11.intel.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1726856AbfLRNyH (ORCPT ); Wed, 18 Dec 2019 08:54:07 -0500 X-Amp-Result: UNKNOWN X-Amp-Original-Verdict: FILE UNKNOWN X-Amp-File-Uploaded: False Received: from orsmga005.jf.intel.com ([10.7.209.41]) by fmsmga102.fm.intel.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 18 Dec 2019 05:54:06 -0800 X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="5.69,329,1571727600"; d="scan'208";a="390195126" Received: from unknown (HELO localhost) ([10.239.159.128]) by orsmga005.jf.intel.com with ESMTP; 18 Dec 2019 05:54:04 -0800 Date: Wed, 18 Dec 2019 21:55:13 +0800 From: Yang Weijiang To: Sean Christopherson Cc: Yang Weijiang , kvm@vger.kernel.org, linux-kernel@vger.kernel.org, pbonzini@redhat.com, jmattson@google.com, yu.c.zhang@linux.intel.com, yu-cheng.yu@intel.com Subject: Re: [PATCH v8 3/7] KVM: VMX: Pass through CET related MSRs Message-ID: <20191218135513.GB7926@local-michael-cet-test> References: <20191101085222.27997-1-weijiang.yang@intel.com> <20191101085222.27997-4-weijiang.yang@intel.com> <20191210211821.GL15758@linux.intel.com> <20191216021816.GA10764@local-michael-cet-test> <20191218003455.GP11771@linux.intel.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20191218003455.GP11771@linux.intel.com> User-Agent: Mutt/1.11.3 (2019-02-01) Sender: kvm-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: kvm@vger.kernel.org On Tue, Dec 17, 2019 at 04:34:55PM -0800, Sean Christopherson wrote: > On Mon, Dec 16, 2019 at 10:18:16AM +0800, Yang Weijiang wrote: > > On Tue, Dec 10, 2019 at 01:18:21PM -0800, Sean Christopherson wrote: > > > On Fri, Nov 01, 2019 at 04:52:18PM +0800, Yang Weijiang wrote: > > > > CET MSRs pass through Guest directly to enhance performance. > > > > CET runtime control settings are stored in MSR_IA32_{U,S}_CET, > > > > Shadow Stack Pointer(SSP) are stored in MSR_IA32_PL{0,1,2,3}_SSP, > > > > SSP table base address is stored in MSR_IA32_INT_SSP_TAB, > > > > these MSRs are defined in kernel and re-used here. > > > > > > > + > > > > static void vmx_cpuid_update(struct kvm_vcpu *vcpu) > > > > { > > > > struct vcpu_vmx *vmx = to_vmx(vcpu); > > > > @@ -7025,6 +7087,9 @@ static void vmx_cpuid_update(struct kvm_vcpu *vcpu) > > > > if (boot_cpu_has(X86_FEATURE_INTEL_PT) && > > > > guest_cpuid_has(vcpu, X86_FEATURE_INTEL_PT)) > > > > update_intel_pt_cfg(vcpu); > > > > + > > > > + if (!is_guest_mode(vcpu)) > > > > + vmx_pass_cet_msrs(vcpu); > > > > > > Hmm, this looks insufficent, e.g. deliberately toggling CET from on->off > > > while in guest mode would put KVM in a weird state as the msr bitmap for > > > L1 would still allow L1 to access the CET MSRs. > > > > > Hi, Sean, > > I don't get you, there's guest mode check before access CET msrs, it'll > > fail if it's in guest mode. > > KVM can exit to userspae while L2 is active. If userspace then did a > KVM_SET_CPUID2, e.g. instead of KVM_RUN, vmx_cpuid_update() would skip > vmx_pass_cet_msrs() and KVM would never update L1's MSR bitmaps. > Thanks, it makes sense to me. Given current implementation, how about removing above check and adding it in CET CPUID enumeration for L2 so that no CET msrs passed through to L2 when is_guest_mode() is true? > > > Allowing KVM_SET_CPUID{2} while running a nested guest seems bogus, can we > > > kill that path entirely with -EINVAL? > > > > > Do you mean don't expose CET cpuids to L2 guest? > > I mean completely disallow KVM_SET_CPUID and KVM_SET_CPUID2 if > is_guest_mode() is true. My question is mostly directed at Paolo and > anyone else that has an opinion on whether we can massage the ABI to > retroactively change KVM_SET_CPUID{2} behavior. This sounds like something deserving an individual patch after get agreement in community. I'll put it aside right now.