From nobody Mon Jun 15 10:45:33 2026 Received: from mail-pf1-f202.google.com (mail-pf1-f202.google.com [209.85.210.202]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id 43F6714BF97 for ; Thu, 9 Apr 2026 19:13:46 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=209.85.210.202 ARC-Seal: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1775762027; cv=none; b=PZ7gzp3VmCLmPrOUgtfqkiqeExTWX2y9M4baenoUgTViReaWYXfvivxmbaWmZVqBgzEYtAUg9z4zI6B4OEPnVaNBeSTV+GSSrnSWrgHYCXXnPF78kQzEntNFx83MdJo9VaYTwsITSiaCUi4xE4DBbSH37jjxzCJpTqSgLqwkLEY= ARC-Message-Signature: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1775762027; c=relaxed/simple; bh=7evDpf8/MuQK6ymOnS11bdC2v8Y7C22a1shrByEz0Gc=; h=Date:Mime-Version:Message-ID:Subject:From:To:Cc:Content-Type; b=ZPF+f+9fTAFGYpn/0temKI9AGbMsGDUj6tAHUx/igKaAgJpB1h2ec7yoTzCdygGscMARAVQ7ksidaPmUtr5xrw4+ZYJVxyz/nAF5uB/ElvwkO3y5VB+sIrwEhCGq06uvGFhTCxt8oIxeHctBkR0F5dzeTnYqySpnUU+SXUbostM= ARC-Authentication-Results: i=1; smtp.subspace.kernel.org; dmarc=pass (p=reject dis=none) header.from=google.com; spf=pass smtp.mailfrom=flex--seanjc.bounces.google.com; dkim=pass (2048-bit key) header.d=google.com header.i=@google.com header.b=UQYNf2bL; arc=none smtp.client-ip=209.85.210.202 Authentication-Results: smtp.subspace.kernel.org; dmarc=pass (p=reject dis=none) header.from=google.com Authentication-Results: smtp.subspace.kernel.org; spf=pass smtp.mailfrom=flex--seanjc.bounces.google.com Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=google.com header.i=@google.com header.b="UQYNf2bL" Received: by mail-pf1-f202.google.com with SMTP id d2e1a72fcca58-82f07078eaaso337064b3a.0 for ; Thu, 09 Apr 2026 12:13:46 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20251104; t=1775762025; x=1776366825; darn=vger.kernel.org; h=cc:to:from:subject:message-id:mime-version:date:reply-to:from:to:cc :subject:date:message-id:reply-to; bh=1tcSis0dTsgDbrWJ8dsR6LRX6y5aLVwLIFFJ5krnbbQ=; b=UQYNf2bL6RpEibnKXoH6UNJjyNaBzhVvyFu2wSNEaE1TvT2m6JuOe8v4/qmDIyztZC 3uAvYLAvwvTtJZqpeyVrPlLdgYx3najJZgkZiXMm7MyKrh37fvhQHYCDIiRGvd1XXtAg Nom+D6t5nSJ+j7UUb9fx+LoiduNUwUdlmF0oOXkJhMhiUu6ZcwLtKwS6DdFO+c+vJfEU Bymaxn0j6dmOVS26qFP53KMr200vbmJ0D5rHbs6nSYHHh79eR0+p+9Aht57Mh//4vQcg oIUFuyqj+HW8ISBkRT2N4MHDKVH3AtPetTmDawqQ5HZkZYrCe3n3c/8FoJOLCYcVdmMh yaDA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20251104; t=1775762025; x=1776366825; h=cc:to:from:subject:message-id:mime-version:date:reply-to :x-gm-message-state:from:to:cc:subject:date:message-id:reply-to; bh=1tcSis0dTsgDbrWJ8dsR6LRX6y5aLVwLIFFJ5krnbbQ=; b=nsSfvtTZ6NJfi74fJJp9RZUAuP4tVxnHTmSvk53b65EnzSWWIBem+/fbMIjru4PO0v oQ2soI6dXzaIypn8EceUIGapNJ82225mzCCTWFgg6Rd/OmxeLuvLuwQEHXmX7WX/gVEB IAv5kTlJARmbCgHT8zKQSEDkPOdRQmuCUI94K27SB/Q1UOBOAnLOff4nThsyM25gul/0 OtwsqX2PNjAeuXiMFXGUw7Nt7gTbizhtxJet4BYyGwESFHK00NSV+919ebCMFkFCO86U Mjj7y89mgYgJgLRg5vqrIB3KrDlZV9oG8MwSjrBoUTUISPQJS55X8DOHvUa8kVYOUiRy mavQ== X-Gm-Message-State: AOJu0YwQ4HPRODCMBBLWFX26Izd88g0xr1jMhkBbjlZ8iYsGy4pZNq6Z j0f3cxM5DrftqFurdgHMdAucVLTXuZimlxbblF6PUe3LJV/khp20FckvMsJocwPMUve9Px3Lmhz uTC7k2w== X-Received: from pfwz37.prod.google.com ([2002:a05:6a00:1da5:b0:82a:6880:1253]) (user=seanjc job=prod-delivery.src-stubby-dispatcher) by 2002:a05:6a00:3e13:b0:82a:190b:2225 with SMTP id d2e1a72fcca58-82f0c2991c6mr435652b3a.31.1775762025334; Thu, 09 Apr 2026 12:13:45 -0700 (PDT) Reply-To: Sean Christopherson Date: Thu, 9 Apr 2026 12:13:41 -0700 Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: Mime-Version: 1.0 X-Mailer: git-send-email 2.53.0.1213.gd9a14994de-goog Message-ID: <20260409191341.1932853-1-seanjc@google.com> Subject: [PATCH] x86/virt: Treat SVM as unsupported when running as an SEV+ guest From: Sean Christopherson To: Thomas Gleixner , Ingo Molnar , Borislav Petkov , Dave Hansen , x86@kernel.org Cc: linux-kernel@vger.kernel.org, Srikanth Aithal , Sean Christopherson Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="utf-8" When running as an SEV+ guest, treat SVM as unsupported even if CPUID (and other reporting, e.g. MSRs) enumerate support for SVM, as KVM doesn't support nested virtualization within an SEV VM (KVM would need to explicitly share all VMCBs and other assets with the untrusted host), let alone running nested VMs within SEV-ES+ guests (e.g. emulating VMLOAD, VMSAVE, and VMRUN all require access to guest register state). And outside of KVM, there is no in-tree user of SVM enabling. Arguably, the hypervisor/VMM (e.g. QEMU) should clear SVM from guest CPUID for SEV VMs, especially for SEV-ES+, but super duper technically, it's feasible to run nested VMs in SEV+ guests (with many caveats). More importantly, Linux-as-a-guest has played nice with SVM being advertised to SEV+ guests for a long time. Treating SVM as unsupported fixes a regression where a clean shutdown of an SEV-ES+ guest degrades into an abrupt termination. Due to a gnarly virtualization hole in SEV-ES (the architecture), where EFER must NOT be intercepted by the hypervisor (because the untrusted hypervisor can't set e.g. EFER.LME on behalf o the guest), the _host's_ EFER.SVME is visible to the guest. Because EFER.SVME must be always '1' while in guest mode, Linux-the-guest sees EFER.SVME=3D1 even when _its_ EFER.SVME is '0', thinks it has enabled virtualization, and ultimately can cause x86_svm_emergency_disable_virtualization_cpu() to execute STGI to ensure GIF is enabled. Executing STGI _should_ be fine, except Linux is a also wee bit paranoid when running as an SEV-ES guest. Because L0 sees EFER.SVME=3D0 for the guest, a well-behaved L0 hypervisor will intercept STGI (to inject #UD), and thus generate a #VC on the STGI. Which, again, should be fine. Unfortunately, vc_check_opcode_bytes() fails to account for STGI and other SVM instructions, throws a fatal error, and triggers a termination request. In a perfect world, the #VC handler would be more forgiving of unknown intercepts, especially when the #VC happened on an instruction with exception fixup. For now, just fix the immediate regression. Fixes: 428afac5a8ea ("KVM: x86: Move bulk of emergency virtualizaton logic = to virt subsystem") Reported-by: Srikanth Aithal Closes: https://lore.kernel.org/all/c820e242-9f3a-4210-b414-19d11b022404@am= d.com Signed-off-by: Sean Christopherson --- FYI, I'm going to fast-track this into kvm-x86 vmxon, so that the initial P= ULL request for 7.1 isn't broken (assuming it survives a day in -next). arch/x86/virt/hw.c | 3 ++- 1 file changed, 2 insertions(+), 1 deletion(-) diff --git a/arch/x86/virt/hw.c b/arch/x86/virt/hw.c index c898f16fe612..f647557d38ac 100644 --- a/arch/x86/virt/hw.c +++ b/arch/x86/virt/hw.c @@ -269,7 +269,8 @@ static __init int x86_svm_init(void) .emergency_disable_virtualization_cpu =3D x86_svm_emergency_disable_virt= ualization_cpu, }; =20 - if (!cpu_feature_enabled(X86_FEATURE_SVM)) + if (!cpu_feature_enabled(X86_FEATURE_SVM) || + cc_platform_has(CC_ATTR_GUEST_MEM_ENCRYPT)) return -EOPNOTSUPP; =20 memcpy(&virt_ops, &svm_ops, sizeof(virt_ops)); base-commit: b89df297a47e641581ee67793592e5c6ae0428f4 --=20 2.53.0.1213.gd9a14994de-goog