From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from smtp.kernel.org (aws-us-west-2-korg-mail-1.web.codeaurora.org [10.30.226.201]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id 32C2D224239; Tue, 8 Apr 2025 12:32:42 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=10.30.226.201 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1744115562; cv=none; b=ZrHDYI+04geqDUXM38mWvEwMLbd8ghKooBQH4DNsYZEMYApGH1a3FY86aNrdK28k9UShSJyipqxT+dt4FUhvyByi7mc4DeivSVhTmUBDsrfLj5VO31fKC8GgkTsrnf31Pk9jjWKFv1Y875ubvmdbMqEFtL3GX6tVcTy5SyJ/iZU= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1744115562; c=relaxed/simple; bh=0gOeyb2rDc0SXrj01hpESQ4vwTMxv9nRpR40SF3pvJQ=; h=From:To:Cc:Subject:Date:Message-ID:In-Reply-To:References: MIME-Version; b=srRN9wRppHnVFVUdUMTdRHT5RuxUdPPqGXjNnATQPZ78M/8+h174F/GQEbzsElmL7JlNnZAMfL31b25m+fnEXWZtZyc6qOzxumNkbvjYI5Qsre6fxnzp2v6TOEZnJB53S4onH2vIylsCyk9pb6TR1g1ebU7wrdAZ9WAXLfCiNdI= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dkim=pass (1024-bit key) header.d=linuxfoundation.org header.i=@linuxfoundation.org header.b=iCDwOvA/; arc=none smtp.client-ip=10.30.226.201 Authentication-Results: smtp.subspace.kernel.org; dkim=pass (1024-bit key) header.d=linuxfoundation.org header.i=@linuxfoundation.org header.b="iCDwOvA/" Received: by smtp.kernel.org (Postfix) with ESMTPSA id 8D5B5C4CEEA; Tue, 8 Apr 2025 12:32:41 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=linuxfoundation.org; s=korg; t=1744115562; bh=0gOeyb2rDc0SXrj01hpESQ4vwTMxv9nRpR40SF3pvJQ=; h=From:To:Cc:Subject:Date:In-Reply-To:References:From; b=iCDwOvA/fHwSPY4PomevkrxUTX8vJbdFOZsqtyXbxXj8NLxp5nwhgrmnNZIgMkm3D PsyDk/Yn3cAsm+CAJLju4InFafK2G7P8lIPLUMrspFRhVnHW4QGpU180IgZFkafsQD /EArJZamjhFk64yj4X6JytyDoB4DdJwUDWAZsbUg= From: Greg Kroah-Hartman To: stable@vger.kernel.org Cc: Greg Kroah-Hartman , patches@lists.linux.dev, "Chang S. Bae" , Chao Gao , Ingo Molnar , Andy Lutomirski , "H. Peter Anvin" , Linus Torvalds , Oleg Nesterov , Dave Hansen , Juergen Gross , Stefano Stabellini , Paolo Bonzini , Vitaly Kuznetsov , Sean Christopherson , David Woodhouse , Sasha Levin Subject: [PATCH 6.1 020/204] x86/fpu/xstate: Fix inconsistencies in guest FPU xfeatures Date: Tue, 8 Apr 2025 12:49:10 +0200 Message-ID: <20250408104820.913837994@linuxfoundation.org> X-Mailer: git-send-email 2.49.0 In-Reply-To: <20250408104820.266892317@linuxfoundation.org> References: <20250408104820.266892317@linuxfoundation.org> User-Agent: quilt/0.68 X-stable: review X-Patchwork-Hint: ignore Precedence: bulk X-Mailing-List: stable@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 Content-Transfer-Encoding: 8bit 6.1-stable review patch. If anyone has any objections, please let me know. ------------------ From: Chao Gao [ Upstream commit dda366083e5ff307a4a728757db874bbfe7550be ] Guest FPUs manage vCPU FPU states. They are allocated via fpu_alloc_guest_fpstate() and are resized in fpstate_realloc() when XFD features are enabled. Since the introduction of guest FPUs, there have been inconsistencies in the kernel buffer size and xfeatures: 1. fpu_alloc_guest_fpstate() uses fpu_user_cfg since its introduction. See: 69f6ed1d14c6 ("x86/fpu: Provide infrastructure for KVM FPU cleanup") 36487e6228c4 ("x86/fpu: Prepare guest FPU for dynamically enabled FPU features") 2. __fpstate_reset() references fpu_kernel_cfg to set storage attributes. 3. fpu->guest_perm uses fpu_kernel_cfg, affecting fpstate_realloc(). A recent commit in the tip:x86/fpu tree partially addressed the inconsistency between (1) and (3) by using fpu_kernel_cfg for size calculation in (1), but left fpu_guest->xfeatures and fpu_guest->perm still referencing fpu_user_cfg: https://lore.kernel.org/all/20250218141045.85201-1-stanspas@amazon.de/ 1937e18cc3cf ("x86/fpu: Fix guest FPU state buffer allocation size") The inconsistencies within fpu_alloc_guest_fpstate() and across the mentioned functions cause confusion. Fix them by using fpu_kernel_cfg consistently in fpu_alloc_guest_fpstate(), except for fields related to the UABI buffer. Referencing fpu_kernel_cfg won't impact functionalities, as: 1. fpu_guest->perm is overwritten shortly in fpu_init_guest_permissions() with fpstate->guest_perm, which already uses fpu_kernel_cfg. 2. fpu_guest->xfeatures is solely used to check if XFD features are enabled. Including supervisor xfeatures doesn't affect the check. Fixes: 36487e6228c4 ("x86/fpu: Prepare guest FPU for dynamically enabled FPU features") Suggested-by: Chang S. Bae Signed-off-by: Chao Gao Signed-off-by: Ingo Molnar Cc: Andy Lutomirski Cc: H. Peter Anvin Cc: Linus Torvalds Cc: Oleg Nesterov Cc: Dave Hansen Cc: Juergen Gross Cc: Stefano Stabellini Cc: Paolo Bonzini Cc: Vitaly Kuznetsov Cc: Sean Christopherson Cc: David Woodhouse Link: https://lore.kernel.org/r/20250317140613.1761633-1-chao.gao@intel.com Signed-off-by: Sasha Levin --- arch/x86/kernel/fpu/core.c | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/arch/x86/kernel/fpu/core.c b/arch/x86/kernel/fpu/core.c index cbaa3afdd223f..80ba0f81a44a6 100644 --- a/arch/x86/kernel/fpu/core.c +++ b/arch/x86/kernel/fpu/core.c @@ -232,8 +232,8 @@ bool fpu_alloc_guest_fpstate(struct fpu_guest *gfpu) fpstate->is_guest = true; gfpu->fpstate = fpstate; - gfpu->xfeatures = fpu_user_cfg.default_features; - gfpu->perm = fpu_user_cfg.default_features; + gfpu->xfeatures = fpu_kernel_cfg.default_features; + gfpu->perm = fpu_kernel_cfg.default_features; /* * KVM sets the FP+SSE bits in the XSAVE header when copying FPU state -- 2.39.5