[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20240504124822.GAZjYulrGPPX_4w4zK@fat_crate.local>
Date: Sat, 4 May 2024 14:48:22 +0200
From: Borislav Petkov <bp@...en8.de>
To: Sean Christopherson <seanjc@...gle.com>,
kernel test robot <oliver.sang@...el.com>
Cc: oe-lkp@...ts.linux.dev, lkp@...el.com, linux-kernel@...r.kernel.org,
x86@...nel.org, Ingo Molnar <mingo@...nel.org>,
Srikanth Aithal <sraithal@....com>
Subject: Re: [tip:x86/alternatives] [x86/alternatives] ee8962082a:
WARNING:at_arch/x86/kernel/cpu/cpuid-deps.c:#do_clear_cpu_cap
On Wed, May 01, 2024 at 12:33:05AM +0200, Borislav Petkov wrote:
> On Tue, Apr 30, 2024 at 12:51:02PM -0700, Sean Christopherson wrote:
> > But that would just mask the underlying problem, it wouldn't actually fix anything
> > other than making the WARN go away. Unless I'm misreading the splat+code, the
> > issue isn't that init_ia32_feat_ctl() clears VMX late, it's that the BSP sees
> > VMX as fully enabled, but at least one AP sees VMX as disabled.
> >
> > I don't see how the kernel can expect to function correctly with divergent feature
> > support across CPUs, i.e. the WARN is a _good_ thing in this case, because it
> > alerts the user that their system is messed up, e.g. has a bad BIOS or something.
>
> Yes, and yes.
>
> There are two issues. Clearing feature flags after alternatives have
> been applied should not happen, and this particular issue with that box.
>
> Lemme cook up something in the coming days for the former.
Two simple patches as a reply to this.
Oliver, can you run them on your box pls?
Thx.
--
Regards/Gruss,
Boris.
https://people.kernel.org/tglx/notes-about-netiquette
Powered by blists - more mailing lists