From nobody Wed Apr 8 06:03:34 2026 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 C2679C32793 for ; Wed, 24 Aug 2022 03:31:18 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S234740AbiHXDbR (ORCPT ); Tue, 23 Aug 2022 23:31:17 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:44252 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S234673AbiHXDbD (ORCPT ); Tue, 23 Aug 2022 23:31:03 -0400 Received: from mail-yw1-x114a.google.com (mail-yw1-x114a.google.com [IPv6:2607:f8b0:4864:20::114a]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 32DD083043 for ; Tue, 23 Aug 2022 20:31:02 -0700 (PDT) Received: by mail-yw1-x114a.google.com with SMTP id 00721157ae682-334d894afd8so271883007b3.19 for ; Tue, 23 Aug 2022 20:31:02 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20210112; h=cc:to:from:subject:references:mime-version:message-id:in-reply-to :date:reply-to:from:to:cc; bh=9IPC0RZFheCu6HPtQaFzEc+kW9Jmfu38UrDWGGGi5M0=; b=R9TiQdriz832WuZrCwqfZK6ZKXp64ULx9Ynn99liQK/mT6Acni54GKWX+PAxoQRZq0 3P4o6JdnizMfTbNCkcN6bRI1NKsTE4fo6+VoxAd062MZqJT6g5gY/SIFl69JhuUjaXs3 vx7AvbXzjHlg5vO18lvjD5h530tLY5iVqtYWH8eb6C/t/vHn26Ujl70gwKhICu94/0KJ h+PCCbUmGxHtgajkuHBje5QsjT3DfulTPEeCTymf88rKKrMEcecwtYNYWv3iP1/qGkQR BFPL5zRAUMWR8+29cmqBPSihDC3K/YM4cGYLmV3ZSwlhIBjJHDkJu5z6pJc9FZBFUoZT fEyQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=cc:to:from:subject:references:mime-version:message-id:in-reply-to :date:reply-to:x-gm-message-state:from:to:cc; bh=9IPC0RZFheCu6HPtQaFzEc+kW9Jmfu38UrDWGGGi5M0=; b=FFPoeXobaM8yXZIaoTzDQFD8cqSvR7huz55uzZUXARDtelMplY0ftEzBuE3YG2olDp AZ1eL3u6iLb3lkUlAD0wveYuvrfXY+udju6hESZI7T7tPo+BP4q0TILAtzZ4CHq/+m8S 1hMvxwJ5CQT4iaHo+T9v+7yfvpww8A+xIb7wWbOywVBtlJuElHaPlWPNdIEUDkAI4HRP WgMSfyGwaLlqi4DOch1lrn7AlEZ20YhBQA1LrmDtxdEZYmAonkMinz3oHleBHfVYUMyD wX/4NkhcbWLzbUWQ1t/jhrb5AjW6kDQvH47NL6UHvk3G6lVlgp2W7V0/Ntcih2fPtjB3 MKUw== X-Gm-Message-State: ACgBeo2q5/Z7tPZ8Ud6OOvvgT47qtxKDp1u+UwrB4ukc1j8Unj8svWmB 77qPPZmabW+MneTrKA+UHwSGkqBQqIY= X-Google-Smtp-Source: AA6agR6WjjPJdaIIt2w61lrBMNCH6OPOnEj03rNvKg4GYyvMXwahq3iOD390HhM8Xud+KyAyfHcONhRhJ4Y= X-Received: from zagreus.c.googlers.com ([fda3:e722:ac3:cc00:7f:e700:c0a8:5c37]) (user=seanjc job=sendgmr) by 2002:a81:39d5:0:b0:33d:a75a:1bdd with SMTP id g204-20020a8139d5000000b0033da75a1bddmr268455ywa.340.1661311861937; Tue, 23 Aug 2022 20:31:01 -0700 (PDT) Reply-To: Sean Christopherson Date: Wed, 24 Aug 2022 03:30:55 +0000 In-Reply-To: <20220824033057.3576315-1-seanjc@google.com> Message-Id: <20220824033057.3576315-2-seanjc@google.com> Mime-Version: 1.0 References: <20220824033057.3576315-1-seanjc@google.com> X-Mailer: git-send-email 2.37.1.595.g718a3a8f04-goog Subject: [PATCH 1/3] KVM: x86: Reinstate kvm_vcpu_arch.guest_supported_xcr0 From: Sean Christopherson To: Sean Christopherson , Paolo Bonzini Cc: kvm@vger.kernel.org, linux-kernel@vger.kernel.org, Leonardo Bras , "Dr . David Alan Gilbert" , Vitaly Kuznetsov Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="utf-8" Reinstate the per-vCPU guest_supported_xcr0 by partially reverting commit 988896bb6182; the implicit assessment that guest_supported_xcr0 is always the same as guest_fpu.fpstate->user_xfeatures was incorrect. kvm_vcpu_after_set_cpuid() isn't the only place that sets user_xfeatures, as user_xfeatures is set to fpu_user_cfg.default_features when guest_fpu is allocated via fpu_alloc_guest_fpstate() =3D> __fpstate_reset(). guest_supported_xcr0 on the other hand is zero-allocated. If userspace never invokes KVM_SET_CPUID2, supported XCR0 will be '0', whereas the allowed user XFEATURES will be non-zero. Practically speaking, the edge case likely doesn't matter as no sane userspace will live migrate a VM without ever doing KVM_SET_CPUID2. The primary motivation is to prepare for KVM intentionally and explicitly setting bits in user_xfeatures that are not set in guest_supported_xcr0. Because KVM_{G,S}ET_XSAVE can be used to svae/restore FP+SSE state even if the host doesn't support XSAVE, KVM needs to set the FP+SSE bits in user_xfeatures even if they're not allowed in XCR0, e.g. because XCR0 isn't exposed to the guest. At that point, the simplest fix is to track the two things separately (allowed save/restore vs. allowed XCR0). Fixes: 988896bb6182 ("x86/kvm/fpu: Remove kvm_vcpu_arch.guest_supported_xcr= 0") Cc: stable@vger.kernel.org Cc: Leonardo Bras Signed-off-by: Sean Christopherson --- arch/x86/include/asm/kvm_host.h | 1 + arch/x86/kvm/cpuid.c | 5 ++--- arch/x86/kvm/x86.c | 9 ++------- 3 files changed, 5 insertions(+), 10 deletions(-) diff --git a/arch/x86/include/asm/kvm_host.h b/arch/x86/include/asm/kvm_hos= t.h index 2c96c43c313a..aa381ab69a19 100644 --- a/arch/x86/include/asm/kvm_host.h +++ b/arch/x86/include/asm/kvm_host.h @@ -729,6 +729,7 @@ struct kvm_vcpu_arch { struct fpu_guest guest_fpu; =20 u64 xcr0; + u64 guest_supported_xcr0; =20 struct kvm_pio_request pio; void *pio_data; diff --git a/arch/x86/kvm/cpuid.c b/arch/x86/kvm/cpuid.c index 75dcf7a72605..2e0f27ad736a 100644 --- a/arch/x86/kvm/cpuid.c +++ b/arch/x86/kvm/cpuid.c @@ -315,7 +315,6 @@ static void kvm_vcpu_after_set_cpuid(struct kvm_vcpu *v= cpu) { struct kvm_lapic *apic =3D vcpu->arch.apic; struct kvm_cpuid_entry2 *best; - u64 guest_supported_xcr0; =20 best =3D kvm_find_cpuid_entry(vcpu, 1); if (best && apic) { @@ -327,10 +326,10 @@ static void kvm_vcpu_after_set_cpuid(struct kvm_vcpu = *vcpu) kvm_apic_set_version(vcpu); } =20 - guest_supported_xcr0 =3D + vcpu->arch.guest_supported_xcr0 =3D cpuid_get_supported_xcr0(vcpu->arch.cpuid_entries, vcpu->arch.cpuid_nent= ); =20 - vcpu->arch.guest_fpu.fpstate->user_xfeatures =3D guest_supported_xcr0; + vcpu->arch.guest_fpu.fpstate->user_xfeatures =3D vcpu->arch.guest_support= ed_xcr0; =20 kvm_update_pv_runtime(vcpu); =20 diff --git a/arch/x86/kvm/x86.c b/arch/x86/kvm/x86.c index d7374d768296..97ab53046052 100644 --- a/arch/x86/kvm/x86.c +++ b/arch/x86/kvm/x86.c @@ -1011,15 +1011,10 @@ void kvm_load_host_xsave_state(struct kvm_vcpu *vcp= u) } EXPORT_SYMBOL_GPL(kvm_load_host_xsave_state); =20 -static inline u64 kvm_guest_supported_xcr0(struct kvm_vcpu *vcpu) -{ - return vcpu->arch.guest_fpu.fpstate->user_xfeatures; -} - #ifdef CONFIG_X86_64 static inline u64 kvm_guest_supported_xfd(struct kvm_vcpu *vcpu) { - return kvm_guest_supported_xcr0(vcpu) & XFEATURE_MASK_USER_DYNAMIC; + return vcpu->arch.guest_supported_xcr0 & XFEATURE_MASK_USER_DYNAMIC; } #endif =20 @@ -1042,7 +1037,7 @@ static int __kvm_set_xcr(struct kvm_vcpu *vcpu, u32 i= ndex, u64 xcr) * saving. However, xcr0 bit 0 is always set, even if the * emulated CPU does not support XSAVE (see kvm_vcpu_reset()). */ - valid_bits =3D kvm_guest_supported_xcr0(vcpu) | XFEATURE_MASK_FP; + valid_bits =3D vcpu->arch.guest_supported_xcr0 | XFEATURE_MASK_FP; if (xcr0 & ~valid_bits) return 1; =20 --=20 2.37.1.595.g718a3a8f04-goog