[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <78f1be06-0945-4519-98b6-343987926382@intel.com>
Date: Thu, 5 Feb 2026 07:58:58 -0800
From: Dave Hansen <dave.hansen@...el.com>
To: Sean Christopherson <seanjc@...gle.com>,
Greg KH <gregkh@...uxfoundation.org>
Cc: "Nikunj A. Dadhania" <nikunj@....com>, linux-kernel@...r.kernel.org,
kvm@...r.kernel.org, bp@...en8.de, thomas.lendacky@....com, tglx@...nel.org,
mingo@...hat.com, dave.hansen@...ux.intel.com, hpa@...or.com, xin@...or.com,
pbonzini@...hat.com, x86@...nel.org, jon.grimm@....com,
stable@...r.kernel.org
Subject: Re: [PATCH] x86/fred: Fix early boot failures on SEV-ES/SNP guests
On 2/5/26 07:50, Sean Christopherson wrote:
>>>> That sounds like new hardware support, if you really want that, why not
>>>> just use newer kernel versions with this fix in it? Obviously no one is
>>>> running those kernels on that hardware today, so this isn't a regression 🙂
> I disagree, this absolutely is a regression. Kernels without commit 14619d912b65
> will boot on this "new" hardware, kernels with the commit will not.
Yeah, it is a regression for sure. It's a weird one, but it is a regression.
We need to either disable FRED on SEV-ES/SNP+FRED systems or fix it. We
obviously want to fix it in mainline. I guess stable could do something
different here and disable FRED instead if it wanted. That would avoid
even a whiff of appearing to add new hardware support.
I'd personally prefer to just keep stable and mainline as close as possible.
P.S. #VC and #VE are a scourge
Powered by blists - more mailing lists