From nobody Thu Sep 11 16:10:52 2025 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org Received: from vger.kernel.org (vger.kernel.org [23.128.96.18]) by smtp.lore.kernel.org (Postfix) with ESMTP id 2A580C10F00 for ; Tue, 15 Aug 2023 20:38:21 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S238838AbjHOUh4 (ORCPT ); Tue, 15 Aug 2023 16:37:56 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:54064 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S238657AbjHOUhg (ORCPT ); Tue, 15 Aug 2023 16:37:36 -0400 Received: from mail-pf1-x449.google.com (mail-pf1-x449.google.com [IPv6:2607:f8b0:4864:20::449]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 2C76A269D for ; Tue, 15 Aug 2023 13:37:04 -0700 (PDT) Received: by mail-pf1-x449.google.com with SMTP id d2e1a72fcca58-686f0605dbfso8703472b3a.3 for ; Tue, 15 Aug 2023 13:37:04 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20221208; t=1692131821; x=1692736621; h=cc:to:from:subject:message-id:references:mime-version:in-reply-to :date:reply-to:from:to:cc:subject:date:message-id:reply-to; bh=o5Fw8iHbcV8xK4DrDbdpdFHBEPCT+wzf42bdYUnsFwM=; b=QqYZTngZalMttEh18rnC4PLxQefF07rtAGLtY6TXMgEH5QDZ289O7UXT4u1Ujkwclo 9oLd+5MeuHlx3XfhoH+reDRGW8NM2wVSV6DTFEvO2Ad8BZBeY++BTiclLN/VLRgySn2O xN0/fty+SJ6WTlTTl5p7cQ2HsUR/yaPIidYp38zwNmfPqPSWlsvVr9sAa40dv7517GxB OxTrqJu0AjmAzGxdBvV2cyBSmiqRgGrpUr4Gh3I+xeBxzYth56V+Q1J3M5Wf72YZLbDd zf7LTpbcwizvQLy0Hwzx2fy/KdK9wqvZKfiKVnC+EwLMHH2W/FogYww1Q+KjVLjA+CFD B5TQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20221208; t=1692131821; x=1692736621; h=cc:to:from:subject:message-id:references:mime-version:in-reply-to :date:reply-to:x-gm-message-state:from:to:cc:subject:date:message-id :reply-to; bh=o5Fw8iHbcV8xK4DrDbdpdFHBEPCT+wzf42bdYUnsFwM=; b=epvLZJdl2uByR8r5KI4C9UkCY2w7FR1qppsM8aksC8pG19YVFxXDagdxYmQlC/zONt HnrNoX3W8mpEBxsF7Z+2LjrVrw4Ee5n7xpPxnTdFX9BDv2y7VdsAqXNHx6IWmTifI8x5 9YpJLduB5EShm/ioZPKSwjBIN8sqY5UhxDiHZ7tsA4pn1DPUwzaz2s5q2HTU51vpAXIr Rpp4tih8UZrsbCQurLO9pw+pf5/ZWepBaBVoI7aOUyMFmeh16K24m6jfcJuiqrF1a1Yx EybF/CPrKF4XAfUGBj2lK/FtAftU10ZmItKTHh4YatSwUyLRpskOfvd0euh60BM98DmO Jh5Q== X-Gm-Message-State: AOJu0YwW6SDAR9KWlhaS0hk54zCC9SRpkneiVHyYRx4Zg57WGuCjU1y3 CSOguZT+kleu6K1XxxM7xlFNzfWCvAA= X-Google-Smtp-Source: AGHT+IFe12jxTHjrc7c6wUko5dd5R5Y8ZCoG71Ke9T+D+UtA3k/jZBXLzkxawfZKTlJHI3Ts++fg66QePJI= X-Received: from zagreus.c.googlers.com ([fda3:e722:ac3:cc00:7f:e700:c0a8:5c37]) (user=seanjc job=sendgmr) by 2002:a05:6a00:1ad3:b0:687:3f7a:aea7 with SMTP id f19-20020a056a001ad300b006873f7aaea7mr6546953pfv.0.1692131821648; Tue, 15 Aug 2023 13:37:01 -0700 (PDT) Reply-To: Sean Christopherson Date: Tue, 15 Aug 2023 13:36:41 -0700 In-Reply-To: <20230815203653.519297-1-seanjc@google.com> Mime-Version: 1.0 References: <20230815203653.519297-1-seanjc@google.com> X-Mailer: git-send-email 2.41.0.694.ge786442a9b-goog Message-ID: <20230815203653.519297-4-seanjc@google.com> Subject: [PATCH v3 03/15] KVM: VMX: Recompute "XSAVES enabled" only after CPUID update From: Sean Christopherson To: Sean Christopherson , Paolo Bonzini , Vitaly Kuznetsov Cc: kvm@vger.kernel.org, linux-kernel@vger.kernel.org, Zeng Guang , Yuan Yao Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="utf-8" Recompute whether or not XSAVES is enabled for the guest only if the guest's CPUID model changes instead of redoing the computation every time KVM generates vmcs01's secondary execution controls. The boot_cpu_has() and cpu_has_vmx_xsaves() checks should never change after KVM is loaded, and if they do the kernel/KVM is hosed. Opportunistically add a comment explaining _why_ XSAVES is effectively exposed to the guest if and only if XSAVE is also exposed to the guest. Practically speaking, no functional change intended (KVM will do fewer computations, but should still see the same xsaves_enabled value whenever KVM looks at it). Signed-off-by: Sean Christopherson Reviewed-by: Yuan Yao --- arch/x86/kvm/vmx/vmx.c | 24 +++++++++++------------- 1 file changed, 11 insertions(+), 13 deletions(-) diff --git a/arch/x86/kvm/vmx/vmx.c b/arch/x86/kvm/vmx/vmx.c index 434bf524e712..1bf85bd53416 100644 --- a/arch/x86/kvm/vmx/vmx.c +++ b/arch/x86/kvm/vmx/vmx.c @@ -4612,19 +4612,10 @@ static u32 vmx_secondary_exec_control(struct vcpu_v= mx *vmx) if (!enable_pml || !atomic_read(&vcpu->kvm->nr_memslots_dirty_logging)) exec_control &=3D ~SECONDARY_EXEC_ENABLE_PML; =20 - if (cpu_has_vmx_xsaves()) { - /* Exposing XSAVES only when XSAVE is exposed */ - bool xsaves_enabled =3D - boot_cpu_has(X86_FEATURE_XSAVE) && - guest_cpuid_has(vcpu, X86_FEATURE_XSAVE) && - guest_cpuid_has(vcpu, X86_FEATURE_XSAVES); - - vcpu->arch.xsaves_enabled =3D xsaves_enabled; - + if (cpu_has_vmx_xsaves()) vmx_adjust_secondary_exec_control(vmx, &exec_control, SECONDARY_EXEC_XSAVES, - xsaves_enabled, false); - } + vcpu->arch.xsaves_enabled, false); =20 /* * RDPID is also gated by ENABLE_RDTSCP, turn on the control if either @@ -7749,8 +7740,15 @@ static void vmx_vcpu_after_set_cpuid(struct kvm_vcpu= *vcpu) { struct vcpu_vmx *vmx =3D to_vmx(vcpu); =20 - /* xsaves_enabled is recomputed in vmx_compute_secondary_exec_control(). = */ - vcpu->arch.xsaves_enabled =3D false; + /* + * XSAVES is effectively enabled if and only if XSAVE is also exposed + * to the guest. XSAVES depends on CR4.OSXSAVE, and CR4.OSXSAVE can be + * set if and only if XSAVE is supported. + */ + vcpu->arch.xsaves_enabled =3D cpu_has_vmx_xsaves() && + boot_cpu_has(X86_FEATURE_XSAVE) && + guest_cpuid_has(vcpu, X86_FEATURE_XSAVE) && + guest_cpuid_has(vcpu, X86_FEATURE_XSAVES); =20 vmx_setup_uret_msrs(vmx); =20 --=20 2.41.0.694.ge786442a9b-goog