[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <87r0nsddb5.ffs@tglx>
Date: Thu, 24 Aug 2023 11:01:18 +0200
From: Thomas Gleixner <tglx@...utronix.de>
To: Feng Tang <feng.tang@...el.com>, Ingo Molnar <mingo@...hat.com>,
Borislav Petkov <bp@...en8.de>,
Dave Hansen <dave.hansen@...el.com>,
"H . Peter Anvin" <hpa@...or.com>,
Peter Zijlstra <peterz@...radead.org>, x86@...nel.org,
kernel test robot <oliver.sang@...el.com>,
linux-kernel@...r.kernel.org
Cc: Feng Tang <feng.tang@...el.com>
Subject: Re: [PATCH] x86/fpu: set X86_FEATURE_OSXSAVE feature after enabling
OSXSAVE in CR4
On Wed, Aug 23 2023 at 14:57, Feng Tang wrote:
> diff --git a/arch/x86/kernel/fpu/xstate.c b/arch/x86/kernel/fpu/xstate.c
> index 0bab497c9436..8ebea0d522d2 100644
> --- a/arch/x86/kernel/fpu/xstate.c
> +++ b/arch/x86/kernel/fpu/xstate.c
> @@ -173,6 +173,9 @@ void fpu__init_cpu_xstate(void)
>
> cr4_set_bits(X86_CR4_OSXSAVE);
>
> + if (!boot_cpu_has(X86_FEATURE_OSXSAVE))
> + setup_force_cpu_cap(X86_FEATURE_OSXSAVE);
This is wrong in several aspects:
1) You force the feature bit _before_ XSAVE is completely
initialized. fpu__init_system_xstate() has error paths which
disable XSAVE.
2) This conditional should have been a red flag for you simply
because fpu__init_cpu_xstate() is invoked on all CPUs not only
on the BSP.
I fixed it up and added a proper comment explaining it.
Powered by blists - more mailing lists