dd stable tag:
> > >>
> > >> With FRED support for SVM here 
> > >> https://lore.kernel.org/kvm/20260129063653.3553076-1-shivansh.dhiman@amd.com,
> > >> SVM and SEV guests running 6.9 and later kernels will support FRED.
> > >> However, *SEV-ES and SNP guests cannot support FRED* and will fail to boot
> > >> with the following error:
> > >>
> > >>     [    0.005144] Using GB pages for direct mapping
> > >>     [    0.008402] Initialize FRED on CPU0
> > >>     qemu-system-x86_64: cpus are not resettable, terminating
> > >>
> > >> Three problems were identified as detailed in the commit message above and
> > >> is fixed with this patch.
> > >>
> > >> I would like the patch to be backported to the LTS kernels (6.12 and 6.18) to
> > >> ensure SEV-ES and SNP guests running these stable kernel versions can boot
> > >> with FRED enabled on FRED-enabled hypervisors.
> > > 
> > > 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.

> > Fair point.
> > 
> > However, the situation is a bit nuanced: FRED hardware is available now, and
> > users running current stable kernels as guests will encounter boot
> > failures when the hypervisor is updated to support FRED. While not a traditional
> > regression, it creates a compatibility gap where stable guest kernels cannot run
> > on updated hypervisors.
> 
> Great, then upgrade those guest kernels as they have never been able to
> run on those hypervisors :)

As above, *upgrading* from e.g. 6.6 to 6.12 will suddenly fail to boot.

> > Other option would be to disable FRED for SEV-ES and SNP guest in stable kernel.
> 
> That's a choice for the hypervisor vendors to choose.

No, because the hypervisor has no clue what kernel version the guest is running.


From - Thu Feb 05 15:54:47 2026
X-Mozilla-Status: 0001
X-Mozilla-Status2: 00000000
Return-Path: <stable+bounces-214497-hi=josie.lol@vger.kernel.org>
Delivered-To: hi@josie.lol
Received: from witcher.mxrouting.net
	by witcher.mxrouting.net with LMTP
	id mPlCCEK9hGmAqDkAYBR5ng
	(envelope-from <stable+bounces-214497-hi=josie.lol@vger.kernel.org>)
	for <hi@josie.lol>; Thu, 05 Feb 2026 15:54:42 +0000
Return-path: <stable+bounces-214497-hi=josie.lol@vger.kernel.org>
Envelope-to: hi@josie.lol
Delivery-date: Thu, 05 Feb 2026 15:54:42 +0000
Received: from sto.lore.kernel.org ([172.232.135.74])
	by witcher.mxrouting.net with esmtps  (TLS1.3) tls TLS_AES_256_GCM_SHA384
	(Exim 4.98)
	(envelope-from <stable+bounces-214497-hi=josie.lol@vger.kernel.org>)
	id 1vo1gn-0000000GimM-34Kw
	for hi@josie.lol;
	Thu, 05 Feb 2026 15:54:42 +0000
Received: from smtp.subspace.kernel.org (conduit.subspace.kernel.org [100.90.174.1])
	by sto.lore.kernel.org (Postfix) with ESMTP id 263F730039A9
	for <hi@josie.lol>; Thu,  5 Feb 2026 15:54:40 +0000 (UTC)
Received: from localhost.localdomain (localhost.localdomain [127.0.0.1])
	by smtp.subspace.kernel.org (Postfix) with ESMTP id 3FECE421F1E;
	Thu,  5 Feb 2026 15:54:39 +0000 (UTC)
Authentication-Results: smtp.subspace.kernel.org;
	dkim=pass (1024-bit key) header.d=redhat.com header.i=@redhat.com header.b="VyAvWgYx"
X-Original-To: stable@vger.kernel.org
Received: from us-smtp-delivery-124.mimecast.com (us-smtp-delivery-124.mimecast.com [170.10.133.124])
	(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 DE7F43D3D15
	for <stable@vger.kernel.org>; Thu,  5 Feb 2026 15:54:38 +0000 (UTC)
Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=170.10.133.124
ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116;
	t=1770306879; cv=none; b=sN6VFG9JR/WmtNF1WMri+fRorfJklB4RubabKr8XjKn9ToK9IxhEb