Received: by 2002:a05:6a10:c7c6:0:0:0:0 with SMTP id h6csp1399257pxy; Mon, 2 Aug 2021 00:03:12 -0700 (PDT) X-Google-Smtp-Source: ABdhPJwNOOyThJz9Ore7VDa17sEafJ4gUilTrF5ux5wO5s0VnGPvGNhgTjNEIlJqtq1d2X0UbAyP X-Received: by 2002:a17:906:4943:: with SMTP id f3mr13852019ejt.102.1627887792259; Mon, 02 Aug 2021 00:03:12 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1627887792; cv=none; d=google.com; s=arc-20160816; b=W4tlGvaDla+v9IF+40NF9vRdL9hprRHCiyJ70JKNluw/OqBUitaNydkZuhw6W6PLpK 9p8ZvJkpeuYxqlGHRRAYnav13+R2I7wkYuq7lilWaXLqcBfdjaX44TfFvE7mXupU5aR3 oLzFGJzx4aCNnd0YUhwaTwJ2n1B9AYzWDtMplFJP8aM8PglFsLJDXIsSTkMWg0MG/LMr 0fvn1vzurPKHSx/sdrvLR+HhB8JknEJEhu6PnN4u1o7l7rTlOwdBRYa3qbCBeYf2kLDA K5SL+F5HM/DrySTjDuqX5h5maBSeHaPvBHWtAO/2QibqwPZdK/503DXkPgp7nyqYaIhr D8+A== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:content-language:content-transfer-encoding :in-reply-to:mime-version:user-agent:date:message-id:from:references :cc:to:subject; bh=qPggrZDsRAg+CmqB6wjbQP/QnCjgopudxtKuHdMITew=; b=OUL3TLqhUXEcrNl9Bmji+wq+KRjNGMeX20hyv3PWlvS7uoOnJMQJq0uNSVTRPRiYgy 6yy1zLGHbD4kLlTiT0KYV3zvFoiPGODDYPTFzWeFOnVOKPzhvZApzdgOkMCQqPyBSh9T 0K4YJ43D1rDVFPWs9NUq+T3Nakrmqk8Na5sIFI+u/UUk5d9vaxE8qBf3SewtC4PxMjkW zkULDzYozETi4x8RqcPS7H3/LoCVWXFFtOGf07fLqeDugGhUfUv9itwLdDFVTSrrLg59 R7LMNosikKQHw9TkxOGhcNHm3pcZ8oeOf0e4RAKWTtuMdA7wbIPLwpuBG7vvW+f3fKVL PL1g== 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 i10si6873019ejd.745.2021.08.02.00.02.49; Mon, 02 Aug 2021 00:03:12 -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 S232443AbhHBHA2 (ORCPT + 99 others); Mon, 2 Aug 2021 03:00:28 -0400 Received: from mga17.intel.com ([192.55.52.151]:27827 "EHLO mga17.intel.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S232297AbhHBHA1 (ORCPT ); Mon, 2 Aug 2021 03:00:27 -0400 X-IronPort-AV: E=McAfee;i="6200,9189,10063"; a="193681317" X-IronPort-AV: E=Sophos;i="5.84,288,1620716400"; d="scan'208";a="193681317" Received: from fmsmga003.fm.intel.com ([10.253.24.29]) by fmsmga107.fm.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 02 Aug 2021 00:00:10 -0700 X-IronPort-AV: E=Sophos;i="5.84,288,1620716400"; d="scan'208";a="509949522" Received: from zengguan-mobl.ccr.corp.intel.com (HELO [10.238.0.133]) ([10.238.0.133]) by fmsmga003-auth.fm.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 02 Aug 2021 00:00:03 -0700 Subject: Re: [PATCH 3/6] KVM: VMX: Detect Tertiary VM-Execution control when setup VMCS config To: Sean Christopherson Cc: Paolo Bonzini , Vitaly Kuznetsov , Wanpeng Li , Jim Mattson , Joerg Roedel , "kvm@vger.kernel.org" , Dave Hansen , "Luck, Tony" , Kan Liang , Thomas Gleixner , Ingo Molnar , Borislav Petkov , "H. Peter Anvin" , Kim Phillips , Jarkko Sakkinen , Jethro Beekman , "Huang, Kai" , "x86@kernel.org" , "linux-kernel@vger.kernel.org" , "Hu, Robert" , "Gao, Chao" , Robert Hoo References: <20210716064808.14757-1-guang.zeng@intel.com> <20210716064808.14757-4-guang.zeng@intel.com> From: Zeng Guang Message-ID: <05faffb4-c22d-1cd5-7582-823de9dd109a@intel.com> Date: Mon, 2 Aug 2021 14:59:47 +0800 User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:78.0) Gecko/20100101 Firefox/78.0 Thunderbird/78.12.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit Content-Language: en-US Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On 7/29/2021 8:03 AM, Sean Christopherson wrote: > On Fri, Jul 16, 2021, Zeng Guang wrote: >> @@ -4204,6 +4234,13 @@ vmx_adjust_secondary_exec_control(struct vcpu_vmx *vmx, u32 *exec_control, >> #define vmx_adjust_sec_exec_exiting(vmx, exec_control, lname, uname) \ >> vmx_adjust_sec_exec_control(vmx, exec_control, lname, uname, uname##_EXITING, true) >> >> +static void vmx_compute_tertiary_exec_control(struct vcpu_vmx *vmx) >> +{ >> + u32 exec_control = vmcs_config.cpu_based_3rd_exec_ctrl; > This is incorrectly truncating the value. > >> + >> + vmx->tertiary_exec_control = exec_control; >> +} >> + >> static void vmx_compute_secondary_exec_control(struct vcpu_vmx *vmx) >> { >> struct kvm_vcpu *vcpu = &vmx->vcpu; >> @@ -4319,6 +4356,11 @@ static void init_vmcs(struct vcpu_vmx *vmx) >> secondary_exec_controls_set(vmx, vmx->secondary_exec_control); >> } >> >> + if (cpu_has_tertiary_exec_ctrls()) { >> + vmx_compute_tertiary_exec_control(vmx); >> + tertiary_exec_controls_set(vmx, vmx->tertiary_exec_control); > IMO, the existing vmx->secondary_exec_control is an abomination that should not > exist. Looking at the code, it's actually not hard to get rid, there's just one > annoying use in prepare_vmcs02_early() that requires a bit of extra work to get > rid of. > > Anyways, for tertiary controls, I'd prefer to avoid the same mess and instead > follow vmx_exec_control(), both in functionality and in name: > > static u64 vmx_tertiary_exec_control(struct vcpu_vmx *vmx) > { > return vmcs_config.cpu_based_3rd_exec_ctrl; > } > > and: > > if (cpu_has_tertiary_exec_ctrls()) > tertiary_exec_controls_set(vmx, vmx_tertiary_exec_control(vmx)); > > and then the next patch becomes: > > static u64 vmx_tertiary_exec_control(struct vcpu_vmx *vmx) > { > u64 exec_control = vmcs_config.cpu_based_3rd_exec_ctrl; > > if (!kvm_vcpu_apicv_active(vcpu)) > exec_control &= ~TERTIARY_EXEC_IPI_VIRT; > > return exec_control; > } > > > And I'll work on a patch to purge vmx->secondary_exec_control. Ok, it looks much concise. I will change as you suggest. Thanks. >> + } >> + >> if (kvm_vcpu_apicv_active(&vmx->vcpu)) { >> vmcs_write64(EOI_EXIT_BITMAP0, 0); >> vmcs_write64(EOI_EXIT_BITMAP1, 0); >> diff --git a/arch/x86/kvm/vmx/vmx.h b/arch/x86/kvm/vmx/vmx.h >> index 945c6639ce24..c356ceebe84c 100644 >> --- a/arch/x86/kvm/vmx/vmx.h >> +++ b/arch/x86/kvm/vmx/vmx.h >> @@ -266,6 +266,7 @@ struct vcpu_vmx { >> u32 msr_ia32_umwait_control; >> >> u32 secondary_exec_control; >> + u64 tertiary_exec_control; >> >> /* >> * loaded_vmcs points to the VMCS currently used in this vcpu. For a >> -- >> 2.25.1 >>