Received: by 2002:a05:6a10:1287:0:0:0:0 with SMTP id d7csp5671262pxv; Wed, 28 Jul 2021 17:05:54 -0700 (PDT) X-Google-Smtp-Source: ABdhPJwMsx/XJi970yskJHFXpN7kndczz/uGYmwZKoB6dALNGTPtjDrSasQNb6HOISrrDCSapyE5 X-Received: by 2002:a50:9503:: with SMTP id u3mr2781812eda.135.1627517154601; Wed, 28 Jul 2021 17:05:54 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1627517154; cv=none; d=google.com; s=arc-20160816; b=jwXU4KA06QKilrfRDxvsxyZrIiETynUs5ASYI6071KZife8uEI14HOJNihDKKbTIT5 uulEGw04+cLvUNHzZTcxjBpH0HIcukKEhLelu2Ns6HUDlwVegfWXTUtVgaVgjCfE3Efg GaDS6QPtRiXrROQYuxDjsCh1VrV22UQ1MbAKWqpWsZDxFW5y+QpDi6+AeYSYbHQSd+Q4 KtDZKzRiOP7+vmRoEHKKYgh4IkojR/39DtqFeflpXl4dJPOcQx8D8LK7dF5X1RQ/c+oJ wgoWS8zGLSHlAms6pyBfA0fXXA4BCrdZykg5z6k48gG40cKIHoiOthVsZ3pRtaBqP65f pf6w== 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; bh=CW8QUk9P9o2UEGEcBhQxw6hUF2SB0nBvDvcAFREKWG0=; b=R0EwnlTF3A/jHMNiHwsg6Gwt3l8fbnZmubDThiA5eoEKJIubZkIdub8QTnksmtP1rt w7umQ9ht1BZQfg0eqdN/M7VBm0utnLQHHHL7PbfJmqaM3845sEOPcoswy8hqhZN5Mk3e WfPd45wat6J7XprTJglZ6Sc98OSuRJmsE2gvnzzKj96IVNGNtHd4nTU7R+rA3D1gtxfo gwWJPM4UdlxP5ldJiQVhznkWFGgRXkG6nQMEOMu7PIz+MCkMML/z1o82bTGa7BNw+8yr Aynrj7SLUoDO1xWBc1wdZMWJp6CUeTeB0bposq4Bx4rioOzuh6+ha7eY5O/G90MC8KgK /Row== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@google.com header.s=20161025 header.b=p1HVDJ84; 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=pass (p=REJECT sp=REJECT dis=NONE) header.from=google.com Return-Path: Received: from vger.kernel.org (vger.kernel.org. [23.128.96.18]) by mx.google.com with ESMTP id e22si1081226edq.549.2021.07.28.17.05.31; Wed, 28 Jul 2021 17:05:54 -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; dkim=pass header.i=@google.com header.s=20161025 header.b=p1HVDJ84; 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=pass (p=REJECT sp=REJECT dis=NONE) header.from=google.com Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S232727AbhG2AEF (ORCPT + 99 others); Wed, 28 Jul 2021 20:04:05 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:57698 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S232355AbhG2AED (ORCPT ); Wed, 28 Jul 2021 20:04:03 -0400 Received: from mail-pl1-x632.google.com (mail-pl1-x632.google.com [IPv6:2607:f8b0:4864:20::632]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 16D8FC061757 for ; Wed, 28 Jul 2021 17:04:01 -0700 (PDT) Received: by mail-pl1-x632.google.com with SMTP id a20so4817536plm.0 for ; Wed, 28 Jul 2021 17:04:01 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20161025; h=date:from:to:cc:subject:message-id:references:mime-version :content-disposition:in-reply-to; bh=CW8QUk9P9o2UEGEcBhQxw6hUF2SB0nBvDvcAFREKWG0=; b=p1HVDJ84ai7K3pcXHqczT0rOendqQSnKDQIkJGEQG94mnqrTbD0jqM3+xkRmHP3wi6 DhxPuvPyJjrnCSKldBYopwhFtYIMXRt6Lv7S78/8cFIhPn+WDc9vK6g3oFIb+hSoGElQ KsQ+C6PRajcED+FgMfkZbBD0ZDi5whtifzZKg+rzwtiEO4o71BBsabs9TaHD0S6/2Ims 2wWv0D6Z/rG4Pvq67KOxGEJ0UNTgpYWxl8hPWriw1A2EoUY0sR+SMVnuZU+NMxxc6Wmk tGs4VPywB7ceEtZKcEpQpilJKwdrBTCWhQ5xvKLijSnv/FelikOMx13QCBYu/ysF/7w9 ATJA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:date:from:to:cc:subject:message-id:references :mime-version:content-disposition:in-reply-to; bh=CW8QUk9P9o2UEGEcBhQxw6hUF2SB0nBvDvcAFREKWG0=; b=UPl8QY4gSYHb6frVyElY7quIQywa3MMe3uDloA4xSEOTEgfynvAtnQ4OntepqYbQsc +rrXLsidxXDVTCw5WQJH9jfNzoZgpLRiS4w1uo/mDm16t9lfWt1gPFW240WD+p0eBPov XgRY/zBKVVZkYeXeFlKqWFN0usJoqXHIxLaLqtjvEF7cjMALDJ6R2UlMTTMsQqdafSD1 KOcK/ClH8RshUVvGLUWyKOZCAajLtFcCUQT2YcIqpnhGfw9/x4xWTMECaSh6rFx8/abS qwCJCu9QQh03Ln7xOZNW/LwCIREsdmmkrT/DWKBpNMwnMzlMUHXEFuZgl61n4Op9P5h0 ys7g== X-Gm-Message-State: AOAM533ceyu9K20QuIYVjwxbZN6jwI6d2Q9cXtMY5/F+gqzeVr4bihDr M979QREPMbsmYv6pC+Gfl7QaWA== X-Received: by 2002:aa7:8d56:0:b029:327:6dc:d254 with SMTP id s22-20020aa78d560000b029032706dcd254mr2268607pfe.69.1627517040296; Wed, 28 Jul 2021 17:04:00 -0700 (PDT) Received: from google.com (157.214.185.35.bc.googleusercontent.com. [35.185.214.157]) by smtp.gmail.com with ESMTPSA id u19sm1183457pfi.4.2021.07.28.17.03.59 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Wed, 28 Jul 2021 17:03:59 -0700 (PDT) Date: Thu, 29 Jul 2021 00:03:55 +0000 From: Sean Christopherson To: Zeng Guang Cc: Paolo Bonzini , Vitaly Kuznetsov , Wanpeng Li , Jim Mattson , Joerg Roedel , kvm@vger.kernel.org, Dave Hansen , Tony Luck , Kan Liang , Thomas Gleixner , Ingo Molnar , Borislav Petkov , "H. Peter Anvin" , Kim Phillips , Jarkko Sakkinen , Jethro Beekman , Kai Huang , x86@kernel.org, linux-kernel@vger.kernel.org, Robert Hu , Gao Chao , Robert Hoo Subject: Re: [PATCH 3/6] KVM: VMX: Detect Tertiary VM-Execution control when setup VMCS config Message-ID: References: <20210716064808.14757-1-guang.zeng@intel.com> <20210716064808.14757-4-guang.zeng@intel.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20210716064808.14757-4-guang.zeng@intel.com> Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org 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. > + } > + > 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 >