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: Delivered-To: hi@josie.lol Received: from witcher.mxrouting.net by witcher.mxrouting.net with LMTP id mPlCCEK9hGmAqDkAYBR5ng (envelope-from ) for ; Thu, 05 Feb 2026 15:54:42 +0000 Return-path: 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 ) 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 ; 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 ; 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