From nobody Fri Dec 19 06:21:03 2025 Received: from mail-pj1-f74.google.com (mail-pj1-f74.google.com [209.85.216.74]) (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 475DF145B25 for ; Thu, 27 Feb 2025 01:25:46 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=209.85.216.74 ARC-Seal: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1740619548; cv=none; b=ofjKNoQaRx0hVShJXfubBN422MrU9ngS3aGiOVvAgch3ljhwSZk4mDxdpQKjzbvHgomOQ9W4ekUE4ohPsWm+FPoYRldnHBgBRYWC4G/kzXWbzyk113rHv80Y+TsxfGe3fDCY6KNxUVppdRAjPaPVJ4yIPCrsxc2eVAFfvDWo4jU= ARC-Message-Signature: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1740619548; c=relaxed/simple; bh=kEAizSXrh46aeFhOp+VD1iskoyu83eS9VfMafXdoPyw=; h=Date:In-Reply-To:Mime-Version:References:Message-ID:Subject:From: To:Cc:Content-Type; b=g7g9k1+SrvcgtGQqEiFrYzI9bbmPCtpL6me8z/0Vs7yRzmQnnDb9Lu2NuaZQUpMD55BFLh+nTXISSH1/aZZ69MuDOugj49WnDGxyRofdGooMG/8/rVEOXF2NNC8sfdiWubfD3EpEG16IzhNIQT11vYSYXmS9stsIDZbV8/jkWuM= 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=YlIK2f0e; arc=none smtp.client-ip=209.85.216.74 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="YlIK2f0e" Received: by mail-pj1-f74.google.com with SMTP id 98e67ed59e1d1-2fc1a4c14d4so965126a91.0 for ; Wed, 26 Feb 2025 17:25:46 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20230601; t=1740619545; x=1741224345; darn=vger.kernel.org; h=cc:to:from:subject:message-id:references:mime-version:in-reply-to :date:reply-to:from:to:cc:subject:date:message-id:reply-to; bh=WBxe6FmXCGOPrPFuVLhffc7/ElAQfUF91a/RZlH0SFI=; b=YlIK2f0ep01e3unET3wZ9cspamj371E0ovB/7pMWFyYyzcsx2b0dvYfYJg2J2/qVz4 rcWLly3sQsO7/7Tm4yzQ+cDOmHrq1DwYFBpm75y03thRTCWzQiKDsKuIDjF4yuUkKql8 A4jonxLdsvuTzuS+LUOzrJHhlaiKyG42XgwBzxjhSyuEj93lcv2lL2CketCFh3ET+4Ec u1ABhrE8qXWbFY2CJr3ju0HqyIOpREVCo0O56Cjua4kz4G9HA1BUckagflQfJxnn1Tl/ 2tf6z+1rRW3NxqBhyjf8EK94T08RlEpoxH2apQLWn9pb9qE9mrGWnk4Zw+6DMaCaMme0 tFcw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1740619545; x=1741224345; h=cc:to:from:subject:message-id:references:mime-version:in-reply-to :date:reply-to:x-gm-message-state:from:to:cc:subject:date:message-id :reply-to; bh=WBxe6FmXCGOPrPFuVLhffc7/ElAQfUF91a/RZlH0SFI=; b=GK5Ilg31fMWY+d5txVJ2yvo2+DyW5WMTAeF/7WsBTKXgqrDDDRmiVu6zt5fgZmVxiu CazCYEIOV7aHSLqxq5AZmqa7Ze23nlsMDpCyhDm5Ms3IT85blv/P6p27ELbEv4g1nTKf vNhqHZUVdmhS5MruJ4oYepTjAIVQ542jj3B2bhhJfsXSdRdRilZUpjLn9nz3gzpU8FzG +tA2+VMWRMJARYfYQiuj/spT/YaMMgo5kgR81mOZyW7kojXK2bne7CHEQTK0nXHADNML YsKvfaGf1EtmUNh7owX4hb88dZG4/dsQaiUaIF9eFgU/XFZc4NqqtMuHSektRN3gBa+U gpeg== X-Forwarded-Encrypted: i=1; AJvYcCVDd24A2fd70kE3m91i5HLtfx+re2y/0yoDHz/679SolkJRZWQdfFw127yHUJCTO2ec5XRdHh6NLQoasoo=@vger.kernel.org X-Gm-Message-State: AOJu0YzVydOBXE2+nemAtfXP3gukRHrfSvwnIYOwx9GnTGNItmdqi3jf ghxCm8yfHh1P3bzB0ofGk5zK/+F+OZT63wZq8WJqzXURW3qowxoekXXI6L/6KA+p4hgEp3mpFCS bhw== X-Google-Smtp-Source: AGHT+IFLLB2ah5LUDPH7+jBTjfbaA9q03uHcgdVTCPpDNBjOdpdUzsxjWAd40Su+shcjHt/50lC87iRJyZ0= X-Received: from pjb3.prod.google.com ([2002:a17:90b:2f03:b0:2fa:a101:743]) (user=seanjc job=prod-delivery.src-stubby-dispatcher) by 2002:a17:90b:4ecf:b0:2ee:f19b:86e5 with SMTP id 98e67ed59e1d1-2fe68ada443mr17254991a91.14.1740619545636; Wed, 26 Feb 2025 17:25:45 -0800 (PST) Reply-To: Sean Christopherson Date: Wed, 26 Feb 2025 17:25:32 -0800 In-Reply-To: <20250227012541.3234589-1-seanjc@google.com> Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: Mime-Version: 1.0 References: <20250227012541.3234589-1-seanjc@google.com> X-Mailer: git-send-email 2.48.1.711.g2feabab25a-goog Message-ID: <20250227012541.3234589-2-seanjc@google.com> Subject: [PATCH v2 01/10] KVM: SVM: Save host DR masks on CPUs with DebugSwap From: Sean Christopherson To: Sean Christopherson , Paolo Bonzini Cc: kvm@vger.kernel.org, linux-kernel@vger.kernel.org, Naveen N Rao , Kim Phillips , Tom Lendacky , Alexey Kardashevskiy , Pankaj Gupta Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="utf-8" When running SEV-SNP guests on a CPU that supports DebugSwap, always save the host's DR0..DR3 mask MSR values irrespective of whether or not DebugSwap is enabled, to ensure the host values aren't clobbered by the CPU. And for now, also save DR0..DR3, even though doing so isn't necessary (see below). SVM_VMGEXIT_AP_CREATE is deeply flawed in that it allows the *guest* to create a VMSA with guest-controlled SEV_FEATURES. A well behaved guest can inform the hypervisor, i.e. KVM, of its "requested" features, but on CPUs without ALLOWED_SEV_FEATURES support, nothing prevents the guest from lying about which SEV features are being enabled (or not!). If a misbehaving guest enables DebugSwap in a secondary vCPU's VMSA, the CPU will load the DR0..DR3 mask MSRs on #VMEXIT, i.e. will clobber the MSRs with '0' if KVM doesn't save its desired value. Note, DR0..DR3 themselves are "ok", as DR7 is reset on #VMEXIT, and KVM restores all DRs in common x86 code as needed via hw_breakpoint_restore(). I.e. there is no risk of host DR0..DR3 being clobbered (when it matters). However, there is a flaw in the opposite direction; because the guest can lie about enabling DebugSwap, i.e. can *disable* DebugSwap without KVM's knowledge, KVM must not rely on the CPU to restore DRs. Defer fixing that wart, as it's more of a documentation issue than a bug in the code. Note, KVM added support for DebugSwap on commit d1f85fbe836e ("KVM: SEV: Enable data breakpoints in SEV-ES"), but that is not an appropriate Fixes, as the underlying flaw exists in hardware, not in KVM. I.e. all kernels that support SEV-SNP need to be patched, not just kernels with KVM's full support for DebugSwap (ignoring that DebugSwap support landed first). Opportunistically fix an incorrect statement in the comment; on CPUs without DebugSwap, the CPU does NOT save or load debug registers, i.e. Fixes: e366f92ea99e ("KVM: SEV: Support SEV-SNP AP Creation NAE event") Cc: stable@vger.kernel.org Cc: Naveen N Rao Cc: Kim Phillips Cc: Tom Lendacky Cc: Alexey Kardashevskiy Reviewed-by: Tom Lendacky Signed-off-by: Sean Christopherson --- arch/x86/kvm/svm/sev.c | 13 ++++++++++--- 1 file changed, 10 insertions(+), 3 deletions(-) diff --git a/arch/x86/kvm/svm/sev.c b/arch/x86/kvm/svm/sev.c index 74525651770a..5c3d8618b722 100644 --- a/arch/x86/kvm/svm/sev.c +++ b/arch/x86/kvm/svm/sev.c @@ -4568,6 +4568,8 @@ void sev_es_vcpu_reset(struct vcpu_svm *svm) =20 void sev_es_prepare_switch_to_guest(struct vcpu_svm *svm, struct sev_es_sa= ve_area *hostsa) { + struct kvm *kvm =3D svm->vcpu.kvm; + /* * All host state for SEV-ES guests is categorized into three swap types * based on how it is handled by hardware during a world switch: @@ -4591,10 +4593,15 @@ void sev_es_prepare_switch_to_guest(struct vcpu_svm= *svm, struct sev_es_save_are =20 /* * If DebugSwap is enabled, debug registers are loaded but NOT saved by - * the CPU (Type-B). If DebugSwap is disabled/unsupported, the CPU both - * saves and loads debug registers (Type-A). + * the CPU (Type-B). If DebugSwap is disabled/unsupported, the CPU does + * not save or load debug registers. Sadly, on CPUs without + * ALLOWED_SEV_FEATURES, KVM can't prevent SNP guests from enabling + * DebugSwap on secondary vCPUs without KVM's knowledge via "AP Create". + * Save all registers if DebugSwap is supported to prevent host state + * from being clobbered by a misbehaving guest. */ - if (sev_vcpu_has_debug_swap(svm)) { + if (sev_vcpu_has_debug_swap(svm) || + (sev_snp_guest(kvm) && cpu_feature_enabled(X86_FEATURE_DEBUG_SWAP))) { hostsa->dr0 =3D native_get_debugreg(0); hostsa->dr1 =3D native_get_debugreg(1); hostsa->dr2 =3D native_get_debugreg(2); --=20 2.48.1.711.g2feabab25a-goog From nobody Fri Dec 19 06:21:03 2025 Received: from mail-pj1-f74.google.com (mail-pj1-f74.google.com [209.85.216.74]) (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 228281537C6 for ; Thu, 27 Feb 2025 01:25:47 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=209.85.216.74 ARC-Seal: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1740619549; cv=none; b=sHat8UQ2OVXl2oKRfsGi/Yw2DODRq+Y0GrKTYzj7Q1Bcm2syVFuZCOPD0EqCQkhznxFmX9zPjfFfZ9V+M/8M7Kgm6QL5LdxgfoowjjyzoVDKfITZyL9CAra/g8DPiBWRKoKQtmBqOOGwzx5g9g7CIgcJxBEFVa+5/gNGanJrytI= ARC-Message-Signature: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1740619549; c=relaxed/simple; bh=o7YIiPy0L+iXjiHb8AA0Ly3jDIFWOKKVvokPylQxXQ4=; h=Date:In-Reply-To:Mime-Version:References:Message-ID:Subject:From: To:Cc:Content-Type; b=Pu01s77A4S8g4gVzf8eVhk6gNrKuse2ctNHruE9c8hqsVJetE71GZC+e2qZz1fSqkXqznDnDaq0DqajMbC/D+vs18tDdB9S7otKmp2lYHdLn5J9JAYdV3yo77MSegmQrSiuqLAgNYB2ffenkf2GqgK7MSRR+hFCyYge2ZEry7Ec= 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=D92oqqMI; arc=none smtp.client-ip=209.85.216.74 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="D92oqqMI" Received: by mail-pj1-f74.google.com with SMTP id 98e67ed59e1d1-2fe98fad333so964587a91.2 for ; Wed, 26 Feb 2025 17:25:47 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20230601; t=1740619547; x=1741224347; darn=vger.kernel.org; h=cc:to:from:subject:message-id:references:mime-version:in-reply-to :date:reply-to:from:to:cc:subject:date:message-id:reply-to; bh=I3z60PyMclA7mj8jFqKxMTzcWzViARYic6y8atlWZws=; b=D92oqqMIOjvjUd1mjlw2/j5gXRKo5E3FR0dHWT8wLnlZiXt69oHzJJha9yUkJ+efCA 9Wp3H4ty3lXx60YYGo283UjmHQYowWaGOd9cvu56WHczy2wzLnJ4MIherDlrGCpGWbVd rZovOCEmVfdHJnEQ6iX5fWwzraO5a5IXcGR6VKFhbLhsrc9IPuHrAdgWL/2Osh5HwFeA cpppusL3QZ6NA/Qi0uDQw4pELsbT9o5pOQJ8vItFnI3rp6wp06EgKj0N9ruDg2ov9MAt fGg9+wnet6sF7ah+3LM6QhV8MYD/LlbOiqnBpspZ4s+thPU3J4UNgvD4hxPDu7H/7mYZ owuA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1740619547; x=1741224347; h=cc:to:from:subject:message-id:references:mime-version:in-reply-to :date:reply-to:x-gm-message-state:from:to:cc:subject:date:message-id :reply-to; bh=I3z60PyMclA7mj8jFqKxMTzcWzViARYic6y8atlWZws=; b=lxJTI2W8XLiXSY7ybRL+n3Y/CZMRLL6EHY1FxUwh1IuvRv0BI+CMBqCzOCZdXZGSIL IL2GjoScNLMF+74M5eu/Qd6WAGV/MwhJTWY0y0GmJSVwY+AC2PhUbiAD+Vox8vNQBAld H1GtKoWQUfY+8G0oCrYflupt4/PqkAyKFjFu0583R8uS7Hf8Z3g/qIblDfG7DJDKiUzk ORksEkZn1ikWWL4YnVbAvSoLCQRonHW29TYhhx3N6hvJ2Ryr+HAolipuOtpx5bjTZ5Au ejMUqzCGfYn7wn0A/4pX2AveabDGLYWGSDz+kT/3dc/HTuAXKv7dvAmUDZzpbERGqVAF 03/A== X-Forwarded-Encrypted: i=1; AJvYcCUTgFtAExX3XIaSbdOcjre1roiElSmd6QVrv6cFg4Bl/n4goAOatPOdy9mPFE+/K97BMBQ728el1qHJmmM=@vger.kernel.org X-Gm-Message-State: AOJu0YzH3GSlz/gNXiR3tKUUgv04slaM2xu5Nt++TUMWxxe+B2AIbF4a Bxu1PZVklHV7dUUr+nYZkhtDWUupN3khjnpQkRlo2VDWXjSeVb9aiORc7AFhKRVaFoKI4czQmba Myg== X-Google-Smtp-Source: AGHT+IHge2PUPDhQVHWderK3qNVut5fMR2npsRs1k9qIMwEd1T0TG6+5b5xVL5Lj7czmJ3HyOQZWBoz5m3s= X-Received: from pjbst5.prod.google.com ([2002:a17:90b:1fc5:b0:2fa:210c:d068]) (user=seanjc job=prod-delivery.src-stubby-dispatcher) by 2002:a17:90b:17cd:b0:2f9:c139:b61f with SMTP id 98e67ed59e1d1-2fce78a3812mr43989600a91.14.1740619547337; Wed, 26 Feb 2025 17:25:47 -0800 (PST) Reply-To: Sean Christopherson Date: Wed, 26 Feb 2025 17:25:33 -0800 In-Reply-To: <20250227012541.3234589-1-seanjc@google.com> Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: Mime-Version: 1.0 References: <20250227012541.3234589-1-seanjc@google.com> X-Mailer: git-send-email 2.48.1.711.g2feabab25a-goog Message-ID: <20250227012541.3234589-3-seanjc@google.com> Subject: [PATCH v2 02/10] KVM: SVM: Don't rely on DebugSwap to restore host DR0..DR3 From: Sean Christopherson To: Sean Christopherson , Paolo Bonzini Cc: kvm@vger.kernel.org, linux-kernel@vger.kernel.org, Naveen N Rao , Kim Phillips , Tom Lendacky , Alexey Kardashevskiy , Pankaj Gupta Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="utf-8" Never rely on the CPU to restore/load host DR0..DR3 values, even if the CPU supports DebugSwap, as there are no guarantees that SNP guests will actually enable DebugSwap on APs. E.g. if KVM were to rely on the CPU to load DR0..DR3 and skipped them during hw_breakpoint_restore(), KVM would run with clobbered-to-zero DRs if an SNP guest created APs without DebugSwap enabled. Update the comment to explain the dangers, and hopefully prevent breaking KVM in the future. Reviewed-by: Tom Lendacky Signed-off-by: Sean Christopherson --- arch/x86/kvm/svm/sev.c | 21 ++++++++++++--------- 1 file changed, 12 insertions(+), 9 deletions(-) diff --git a/arch/x86/kvm/svm/sev.c b/arch/x86/kvm/svm/sev.c index 5c3d8618b722..719cd48330f1 100644 --- a/arch/x86/kvm/svm/sev.c +++ b/arch/x86/kvm/svm/sev.c @@ -4594,18 +4594,21 @@ void sev_es_prepare_switch_to_guest(struct vcpu_svm= *svm, struct sev_es_save_are /* * If DebugSwap is enabled, debug registers are loaded but NOT saved by * the CPU (Type-B). If DebugSwap is disabled/unsupported, the CPU does - * not save or load debug registers. Sadly, on CPUs without - * ALLOWED_SEV_FEATURES, KVM can't prevent SNP guests from enabling - * DebugSwap on secondary vCPUs without KVM's knowledge via "AP Create". - * Save all registers if DebugSwap is supported to prevent host state - * from being clobbered by a misbehaving guest. + * not save or load debug registers. Sadly, KVM can't prevent SNP + * guests from lying about DebugSwap on secondary vCPUs, i.e. the + * SEV_FEATURES provided at "AP Create" isn't guaranteed to match what + * the guest has actually enabled (or not!) in the VMSA. + * + * If DebugSwap is *possible*, save the masks so that they're restored + * if the guest enables DebugSwap. But for the DRs themselves, do NOT + * rely on the CPU to restore the host values; KVM will restore them as + * needed in common code, via hw_breakpoint_restore(). Note, KVM does + * NOT support virtualizing Breakpoint Extensions, i.e. the mask MSRs + * don't need to be restored per se, KVM just needs to ensure they are + * loaded with the correct values *if* the CPU writes the MSRs. */ if (sev_vcpu_has_debug_swap(svm) || (sev_snp_guest(kvm) && cpu_feature_enabled(X86_FEATURE_DEBUG_SWAP))) { - hostsa->dr0 =3D native_get_debugreg(0); - hostsa->dr1 =3D native_get_debugreg(1); - hostsa->dr2 =3D native_get_debugreg(2); - hostsa->dr3 =3D native_get_debugreg(3); hostsa->dr0_addr_mask =3D amd_get_dr_addr_mask(0); hostsa->dr1_addr_mask =3D amd_get_dr_addr_mask(1); hostsa->dr2_addr_mask =3D amd_get_dr_addr_mask(2); --=20 2.48.1.711.g2feabab25a-goog From nobody Fri Dec 19 06:21:03 2025 Received: from mail-pl1-f202.google.com (mail-pl1-f202.google.com [209.85.214.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 E00A415E5B8 for ; Thu, 27 Feb 2025 01:25:49 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=209.85.214.202 ARC-Seal: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1740619551; cv=none; b=jHsH2OtcTYPIF93yK6A1ZPdAtsscRd7lrpKWnbqhcJFsybHei+/tCX5GhJuNer1mZ6pbqX8rIaSsOhXsFjDno0vJpxkKhjA8qWJeBrCUBUZQjElnDrWq1J0PLnXFTnewP1e+kTKNq90l7oSQP84cSI9NmJm37KJ5YUkSmB9994c= ARC-Message-Signature: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1740619551; c=relaxed/simple; bh=Bd2jcIIVus5KKhQQxvEgLThZpvhnEnb0Zp6oqmiDeNc=; h=Date:In-Reply-To:Mime-Version:References:Message-ID:Subject:From: To:Cc:Content-Type; b=NZ9tEiR4j+UbI5qp9a8z9pEORBygkQElcz4Mv//45ly2bKHES1yZt4ToaMe7lE3mWtqUgQliNcnjIdLgWugy0e1FB5hn2m3jXBxNz9C+oSXS89sP3QunDLcSfOJTPvbuRiviQqWVnAr7EO++OAZ4xq4EHCBTMRZka5/x27Me5Do= 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=sX+ytRaW; arc=none smtp.client-ip=209.85.214.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="sX+ytRaW" Received: by mail-pl1-f202.google.com with SMTP id d9443c01a7336-2234c09240fso6801315ad.0 for ; Wed, 26 Feb 2025 17:25:49 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20230601; t=1740619549; x=1741224349; darn=vger.kernel.org; h=cc:to:from:subject:message-id:references:mime-version:in-reply-to :date:reply-to:from:to:cc:subject:date:message-id:reply-to; bh=SpiV/7IGUVGhPtuzMA7ncb1Ov7eVPXJdzTw8o7Y+oeM=; b=sX+ytRaWgmh8rx/g4QSbKm4lQHPMSzGHtVbJ1Wy1V6TnQmybyQVt3YbiYQhlmKEX0Z 2RvmjqrzNyGl1bsd5mzPU7rwEeFVPEPS8T41yUQ1RZrVmKtT+iOFxaGPqrpUCbNNm7n+ LZISBDJVVeYa4d5Bpr+qs0+IJgciD7wVX1EAyacNOYGjZGLsTHQ8VW8+BpMigcz9pZ9y j3pSFDXvf66VcAD0827ALYTduV2zO3kFm83FcgeJJviRyb4klyIM6g4WXvrr0f1n3/jP 23kpn4GtmZBTYmm3Td5KnZHXpuR2HgwP2Km/tOfevX4u6ymLvrFBl5P+GSywf7IcofXT f+tQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1740619549; x=1741224349; h=cc:to:from:subject:message-id:references:mime-version:in-reply-to :date:reply-to:x-gm-message-state:from:to:cc:subject:date:message-id :reply-to; bh=SpiV/7IGUVGhPtuzMA7ncb1Ov7eVPXJdzTw8o7Y+oeM=; b=Jk/klWQ9RQPCIaTRP/TVs6UyaVvB4ZI1HHKuPHjegjPzgiKlMVcfy5iY5LHxIxth9O qvoALHrSZwrdiXKfg6rPUZ157IyjeOQYdrZF5kiw8bwCoXXjzKN56ZCzf/NrzABNCHN5 SjLoC74LjKfd9u76tq3cbBweszdmWy5wgcL0aRhZ5mpR2mnCMu3sc4+r/fUuhVeEM4N8 JKySK8RwnjC0W8Oah3ATUe5aE6zA/q+wsUUdnfpi40uLz7CgYTzuIKPsTtKluNfFzt+M jdgqyLpS8u51pEsHNtLNIbAoqSDyHZKH7di0vGZwMD+UHrxPGvdHu8r+Av9wqmN+Mpa9 or2Q== X-Forwarded-Encrypted: i=1; AJvYcCXrCeT701Mr6/I990hLpxmCVlPIeEjEawDJcGlNdYwBBi/QzI/psWou4gi0vL8ox7rqnurAXA2V2mt9AQs=@vger.kernel.org X-Gm-Message-State: AOJu0YwuJFGo1e/NyB+ZzFGss62rhez4V6UqxFjLzcx7vmC6GOEm4nW2 uOrL9kEpeWVfEm99mvBTJKm1i2C1UdxIY2g1dgCCHHwzOeD9ymAv2k2LRpFBhTFkSjz6UhMkyR2 V6Q== X-Google-Smtp-Source: AGHT+IEBhn1N/oyrrmPhXLjz3V/jBJme9qVZVIFVvFpCt+5P1PKn2MbmobZJwvu3dN1sDK4eJAez625G97g= X-Received: from pfcg22.prod.google.com ([2002:a05:6a00:23d6:b0:730:880d:7ed5]) (user=seanjc job=prod-delivery.src-stubby-dispatcher) by 2002:a05:6a00:1310:b0:730:9567:c3d5 with SMTP id d2e1a72fcca58-7347909fee5mr15105470b3a.4.1740619549128; Wed, 26 Feb 2025 17:25:49 -0800 (PST) Reply-To: Sean Christopherson Date: Wed, 26 Feb 2025 17:25:34 -0800 In-Reply-To: <20250227012541.3234589-1-seanjc@google.com> Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: Mime-Version: 1.0 References: <20250227012541.3234589-1-seanjc@google.com> X-Mailer: git-send-email 2.48.1.711.g2feabab25a-goog Message-ID: <20250227012541.3234589-4-seanjc@google.com> Subject: [PATCH v2 03/10] KVM: SVM: Refuse to attempt VRMUN if an SEV-ES+ guest has an invalid VMSA From: Sean Christopherson To: Sean Christopherson , Paolo Bonzini Cc: kvm@vger.kernel.org, linux-kernel@vger.kernel.org, Naveen N Rao , Kim Phillips , Tom Lendacky , Alexey Kardashevskiy , Pankaj Gupta Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="utf-8" Explicitly reject KVM_RUN with KVM_EXIT_FAIL_ENTRY if userspace "coerces" KVM into running an SEV-ES+ guest with an invalid VMSA, e.g. by modifying a vCPU's mp_state to be RUNNABLE after an SNP vCPU has undergone a Destroy event. On Destroy or failed Create, KVM marks the vCPU HALTED so that *KVM* doesn't run the vCPU, but nothing prevents a misbehaving VMM from manually making the vCPU RUNNABLE via KVM_SET_MP_STATE. Attempting VMRUN with an invalid VMSA should be harmless, but knowingly executing VMRUN with bad control state is at best dodgy. Fixes: e366f92ea99e ("KVM: SEV: Support SEV-SNP AP Creation NAE event") Signed-off-by: Sean Christopherson Reviewed-by: Pankaj Gupta Reviewed-by: Tom Lendacky --- arch/x86/kvm/svm/sev.c | 16 +++++++++++++--- arch/x86/kvm/svm/svm.c | 11 +++++++++-- arch/x86/kvm/svm/svm.h | 2 +- 3 files changed, 23 insertions(+), 6 deletions(-) diff --git a/arch/x86/kvm/svm/sev.c b/arch/x86/kvm/svm/sev.c index 719cd48330f1..218738a360ba 100644 --- a/arch/x86/kvm/svm/sev.c +++ b/arch/x86/kvm/svm/sev.c @@ -3452,10 +3452,19 @@ void sev_es_unmap_ghcb(struct vcpu_svm *svm) svm->sev_es.ghcb =3D NULL; } =20 -void pre_sev_run(struct vcpu_svm *svm, int cpu) +int pre_sev_run(struct vcpu_svm *svm, int cpu) { struct svm_cpu_data *sd =3D per_cpu_ptr(&svm_data, cpu); - unsigned int asid =3D sev_get_asid(svm->vcpu.kvm); + struct kvm *kvm =3D svm->vcpu.kvm; + unsigned int asid =3D sev_get_asid(kvm); + + /* + * Reject KVM_RUN if userspace attempts to run the vCPU with an invalid + * VMSA, e.g. if userspace forces the vCPU to be RUNNABLE after an SNP + * AP Destroy event. + */ + if (sev_es_guest(kvm) && !VALID_PAGE(svm->vmcb->control.vmsa_pa)) + return -EINVAL; =20 /* Assign the asid allocated with this SEV guest */ svm->asid =3D asid; @@ -3468,11 +3477,12 @@ void pre_sev_run(struct vcpu_svm *svm, int cpu) */ if (sd->sev_vmcbs[asid] =3D=3D svm->vmcb && svm->vcpu.arch.last_vmentry_cpu =3D=3D cpu) - return; + return 0; =20 sd->sev_vmcbs[asid] =3D svm->vmcb; svm->vmcb->control.tlb_ctl =3D TLB_CONTROL_FLUSH_ASID; vmcb_mark_dirty(svm->vmcb, VMCB_ASID); + return 0; } =20 #define GHCB_SCRATCH_AREA_LIMIT (16ULL * PAGE_SIZE) diff --git a/arch/x86/kvm/svm/svm.c b/arch/x86/kvm/svm/svm.c index b8aa0f36850f..f72bcf2e590e 100644 --- a/arch/x86/kvm/svm/svm.c +++ b/arch/x86/kvm/svm/svm.c @@ -3587,7 +3587,7 @@ static int svm_handle_exit(struct kvm_vcpu *vcpu, fas= tpath_t exit_fastpath) return svm_invoke_exit_handler(vcpu, exit_code); } =20 -static void pre_svm_run(struct kvm_vcpu *vcpu) +static int pre_svm_run(struct kvm_vcpu *vcpu) { struct svm_cpu_data *sd =3D per_cpu_ptr(&svm_data, vcpu->cpu); struct vcpu_svm *svm =3D to_svm(vcpu); @@ -3609,6 +3609,8 @@ static void pre_svm_run(struct kvm_vcpu *vcpu) /* FIXME: handle wraparound of asid_generation */ if (svm->current_vmcb->asid_generation !=3D sd->asid_generation) new_asid(svm, sd); + + return 0; } =20 static void svm_inject_nmi(struct kvm_vcpu *vcpu) @@ -4231,7 +4233,12 @@ static __no_kcsan fastpath_t svm_vcpu_run(struct kvm= _vcpu *vcpu, if (force_immediate_exit) smp_send_reschedule(vcpu->cpu); =20 - pre_svm_run(vcpu); + if (pre_svm_run(vcpu)) { + vcpu->run->exit_reason =3D KVM_EXIT_FAIL_ENTRY; + vcpu->run->fail_entry.hardware_entry_failure_reason =3D SVM_EXIT_ERR; + vcpu->run->fail_entry.cpu =3D vcpu->cpu; + return EXIT_FASTPATH_EXIT_USERSPACE; + } =20 sync_lapic_to_cr8(vcpu); =20 diff --git a/arch/x86/kvm/svm/svm.h b/arch/x86/kvm/svm/svm.h index 5b159f017055..e51852977b70 100644 --- a/arch/x86/kvm/svm/svm.h +++ b/arch/x86/kvm/svm/svm.h @@ -713,7 +713,7 @@ void avic_refresh_virtual_apic_mode(struct kvm_vcpu *vc= pu); =20 /* sev.c */ =20 -void pre_sev_run(struct vcpu_svm *svm, int cpu); +int pre_sev_run(struct vcpu_svm *svm, int cpu); void sev_init_vmcb(struct vcpu_svm *svm); void sev_vcpu_after_set_cpuid(struct vcpu_svm *svm); int sev_es_string_io(struct vcpu_svm *svm, int size, unsigned int port, in= t in); --=20 2.48.1.711.g2feabab25a-goog From nobody Fri Dec 19 06:21:03 2025 Received: from mail-pj1-f74.google.com (mail-pj1-f74.google.com [209.85.216.74]) (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 4AEA217A2ED for ; Thu, 27 Feb 2025 01:25:51 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=209.85.216.74 ARC-Seal: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1740619552; cv=none; b=PKDV1yzVCwEnlLp8qSdnYQ7+SSXsjW1dmbGOUCISRnORIOK32eev0Rl6Cnr8g6T2fJyOsCNcZE4UnclbprygW3y87eAZs3WNQam5Ly87/EJpC3TsAFanSwbeMN5eTRca5entxmWNvCwIfG+869DXYnw5tAYOD3P2/O43t6yvPsc= ARC-Message-Signature: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1740619552; c=relaxed/simple; bh=Ewaz9FSthSc+aO9YPlgCWiZASwxM0Q3IHNbCrYZLtjE=; h=Date:In-Reply-To:Mime-Version:References:Message-ID:Subject:From: To:Cc:Content-Type; b=kGE47uO6kJuQcpazWKd8EECRwYQZ45AWOX7BfttPcexyUFoBugZ13pqhxj6NHU7enZcsRrQhds3JDo5fT/uA/byJAj7x8eqfAAep+A6oc/sC368/THvj2RiqNZZ1wMFvO4cGKgkz8S2xF2LhrRhXMdriIyvEMZnXXfP1Hhh2GLo= 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=ImvSxEue; arc=none smtp.client-ip=209.85.216.74 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="ImvSxEue" Received: by mail-pj1-f74.google.com with SMTP id 98e67ed59e1d1-2fce2954a10so1399927a91.1 for ; Wed, 26 Feb 2025 17:25:51 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20230601; t=1740619551; x=1741224351; darn=vger.kernel.org; h=cc:to:from:subject:message-id:references:mime-version:in-reply-to :date:reply-to:from:to:cc:subject:date:message-id:reply-to; bh=sGOwbvJmfkCQ/c7rRacZC8cGcdWEXYUj8tUGbmEnuuE=; b=ImvSxEueIAH4AOmrXFYV2IcuZtNnCapc0pNkrVWrOiqXXZtDcPrkyDfcVYIWWTRrAS uPARJMNA2kUev5LdmFd/mnNkb3JLTFON1kGj2gTceIkPduV8JuQ6lQqTNZZNuiDW3N4V U9Z8Zohb63sxYcvniUoj0PdqH+aOrgr0y4u0H1fyOoSFHAWce9X09N27ov8We47D4mP5 2f8udvpxvvuF3DNtq1cE/AAJHMe00N0rudyXnuQlxReudj7duckLRdZkONPKFGBlDbRx 9SUau9LHho3HrBtUWmaWYcU2Y1x55qBa66FC33jW97Tul0bkf98VQksi205GvsXTIYRG 8+JA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1740619551; x=1741224351; h=cc:to:from:subject:message-id:references:mime-version:in-reply-to :date:reply-to:x-gm-message-state:from:to:cc:subject:date:message-id :reply-to; bh=sGOwbvJmfkCQ/c7rRacZC8cGcdWEXYUj8tUGbmEnuuE=; b=JDoRc0KAefbTkXsCWECaxzqSlcAZAhxmNh6UM5/JQn+YDkW6orL5KvugE3KKvvdQIo GeWkhii+oCFMMF9Vd+2X+TMtKfJ031ttgoEUYRAQRXkIZqqayLwCkZ/xZpYo6D2Qe88F Uag9ukDg2ripEVUpCwY4n7d+M4op+tmJKLSkTABZk9wjDm5x7G1VKj3/w7VTrYfKHEik hHZkYILkqR+zKGWMrpojcQFqZnBZwAilpiakMf2+i/msPr6Zs2rsdIzLpLlatlVm1xta jTMp+Ddrxibz0OvwiJ4xf3aETi+ITBBPCEp0lpNPqYlz7gTCNYupGQM9J0hfFMG8nSa5 qWOw== X-Forwarded-Encrypted: i=1; AJvYcCVhLq4N72bOH39ft9AnNK+atIyKee2Ap/F9r62UMz5qbXbEoJ4dUtXXFQnUZ8PukPlYlpUlHY1ZLXyASWo=@vger.kernel.org X-Gm-Message-State: AOJu0Yzh6f+801rTeMoaTKvbHw9psYU3ajNNcPaTnuBNSgJsC5yfK+6j le/PjCpT/ZonklBdsSC20KGxUxZSs2mj7azJcPADCIk/qPLaAzoBEpjAHfKSano2bey7ZgzXoV9 ZMA== X-Google-Smtp-Source: AGHT+IFyryo7Y/u0uoVmOAJ5RVcaLpqcG1z9HpmL8i/TdRHGqTe/axQ2uqXYM/vYbUj6f5PszfDahrT6N+s= X-Received: from pjtu16.prod.google.com ([2002:a17:90a:c890:b0:2ee:3128:390f]) (user=seanjc job=prod-delivery.src-stubby-dispatcher) by 2002:a17:90b:3c84:b0:2fc:c262:ef4b with SMTP id 98e67ed59e1d1-2fce86cf0e0mr42713073a91.18.1740619550877; Wed, 26 Feb 2025 17:25:50 -0800 (PST) Reply-To: Sean Christopherson Date: Wed, 26 Feb 2025 17:25:35 -0800 In-Reply-To: <20250227012541.3234589-1-seanjc@google.com> Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: Mime-Version: 1.0 References: <20250227012541.3234589-1-seanjc@google.com> X-Mailer: git-send-email 2.48.1.711.g2feabab25a-goog Message-ID: <20250227012541.3234589-5-seanjc@google.com> Subject: [PATCH v2 04/10] KVM: SVM: Don't change target vCPU state on AP Creation VMGEXIT error From: Sean Christopherson To: Sean Christopherson , Paolo Bonzini Cc: kvm@vger.kernel.org, linux-kernel@vger.kernel.org, Naveen N Rao , Kim Phillips , Tom Lendacky , Alexey Kardashevskiy , Pankaj Gupta Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="utf-8" If KVM rejects an AP Creation event, leave the target vCPU state as-is. Nothing in the GHCB suggests the hypervisor is *allowed* to muck with vCPU state on failure, let alone required to do so. Furthermore, kicking only in the !ON_INIT case leads to divergent behavior, and even the "kick" case is non-deterministic. E.g. if an ON_INIT request fails, the guest can successfully retry if the fixed AP Creation request is made prior to sending INIT. And if a !ON_INIT fails, the guest can successfully retry if the fixed AP Creation request is handled before the target vCPU processes KVM's KVM_REQ_UPDATE_PROTECTED_GUEST_STATE. Fixes: e366f92ea99e ("KVM: SEV: Support SEV-SNP AP Creation NAE event") Cc: stable@vger.kernel.org Reviewed-by: Tom Lendacky Signed-off-by: Sean Christopherson Reviewed-by: Pankaj Gupta --- arch/x86/kvm/svm/sev.c | 13 ++++++------- 1 file changed, 6 insertions(+), 7 deletions(-) diff --git a/arch/x86/kvm/svm/sev.c b/arch/x86/kvm/svm/sev.c index 218738a360ba..9aad0dae3a80 100644 --- a/arch/x86/kvm/svm/sev.c +++ b/arch/x86/kvm/svm/sev.c @@ -3957,16 +3957,12 @@ static int sev_snp_ap_creation(struct vcpu_svm *svm) =20 /* * The target vCPU is valid, so the vCPU will be kicked unless the - * request is for CREATE_ON_INIT. For any errors at this stage, the - * kick will place the vCPU in an non-runnable state. + * request is for CREATE_ON_INIT. */ kick =3D true; =20 mutex_lock(&target_svm->sev_es.snp_vmsa_mutex); =20 - target_svm->sev_es.snp_vmsa_gpa =3D INVALID_PAGE; - target_svm->sev_es.snp_ap_waiting_for_reset =3D true; - /* Interrupt injection mode shouldn't change for AP creation */ if (request < SVM_VMGEXIT_AP_DESTROY) { u64 sev_features; @@ -4012,20 +4008,23 @@ static int sev_snp_ap_creation(struct vcpu_svm *svm) target_svm->sev_es.snp_vmsa_gpa =3D svm->vmcb->control.exit_info_2; break; case SVM_VMGEXIT_AP_DESTROY: + target_svm->sev_es.snp_vmsa_gpa =3D INVALID_PAGE; break; default: vcpu_unimpl(vcpu, "vmgexit: invalid AP creation request [%#x] from guest= \n", request); ret =3D -EINVAL; - break; + goto out; } =20 -out: + target_svm->sev_es.snp_ap_waiting_for_reset =3D true; + if (kick) { kvm_make_request(KVM_REQ_UPDATE_PROTECTED_GUEST_STATE, target_vcpu); kvm_vcpu_kick(target_vcpu); } =20 +out: mutex_unlock(&target_svm->sev_es.snp_vmsa_mutex); =20 return ret; --=20 2.48.1.711.g2feabab25a-goog From nobody Fri Dec 19 06:21:03 2025 Received: from mail-pj1-f73.google.com (mail-pj1-f73.google.com [209.85.216.73]) (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 02CAF1BEF87 for ; Thu, 27 Feb 2025 01:25:52 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=209.85.216.73 ARC-Seal: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1740619554; cv=none; b=q2qf0E3hzQLrYiex6RI+laZCVXAr+JY7GMsCOJhaCldJhT1kR12L65o0Z1AwzJykn1kb9oxwo3zgh8qIGVnelelfSTwsLmgYeiTdxjR//j+KusarznAS4SGHAVuIhuk47FWCx6F2EnpYP7QFiTKBPllhrE5qBKEAB8YWTFLnB/4= ARC-Message-Signature: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1740619554; c=relaxed/simple; bh=8wNkxswFWdGH1HQRrKpFkvy/1TsnRMIlEykX12vyE8U=; h=Date:In-Reply-To:Mime-Version:References:Message-ID:Subject:From: To:Cc:Content-Type; b=jS8uKePfaCJNPN0KaiT/lQjdCCMMFnDQ4niE62GPb7UcCxjkNZswVFbLVHxLPSgfp8lyQLTS+UWgEOxrbcO5xCYd6pmFxgOchhc/fCrL37Q66f7U2xE1tXDCMVTZnYOlLyBKFsYTXwVcnHi5XhkikOq7ut1wxlJsuT2QzURYRwY= 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=25Zw1OxU; arc=none smtp.client-ip=209.85.216.73 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="25Zw1OxU" Received: by mail-pj1-f73.google.com with SMTP id 98e67ed59e1d1-2fc43be27f8so1428880a91.1 for ; Wed, 26 Feb 2025 17:25:52 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20230601; t=1740619552; x=1741224352; darn=vger.kernel.org; h=cc:to:from:subject:message-id:references:mime-version:in-reply-to :date:reply-to:from:to:cc:subject:date:message-id:reply-to; bh=/9g8YvMgE4u3p57YSBM8Zk/O02fgzICd+Y1XSuEDMWk=; b=25Zw1OxU+5yPGgv5C+BWcIzSDzSiQgS9yLR8C9b+G/Ga9PQFfUfhQNrrKJcQ/UNCHG CWWCiZgWydKcKq1W7hXeRaJNQRchuKJCCHC7icKZjjZ5leQJhsHgpZOvmmWblFWzAxF6 C3FsPysw+Ih/M1/A/LQrzdUbl8AsdLqw4T9G3aYvuAFIVvSISixTX0Gy1Is25aCJsNLh OJsvJ9ud0W8dE918JCOAD4KmBSnBY9EGN2TysHGfFpyQqcE4RoBF2ROJzwXwsNA37Okp YQbgsLPVIi2NvFNPNBi59xjUlLcEw2NOxJcKgUMrgExmsz96xOxj+TKc6ZFY9Zs3+yIG C3dA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1740619552; x=1741224352; h=cc:to:from:subject:message-id:references:mime-version:in-reply-to :date:reply-to:x-gm-message-state:from:to:cc:subject:date:message-id :reply-to; bh=/9g8YvMgE4u3p57YSBM8Zk/O02fgzICd+Y1XSuEDMWk=; b=mxBJ0h8FeXGI8KhSUFYccD9LCq560LsJRnoUIHJ63efUvDykkyreSyNAZ/pETyh5vW 2bbvtpKlNUWyhEPjVMBb68kRqy+xLnaLKZbkf8XMAZT6342FCVRzSo/Ou/Rw8MMIUsQP 2hd8XY7bmZgF9RYTrUIlmr/HinOzKNV6WGu+/FrauivFzHYQn0XCs9us7cv5AwJKk6Ng 9z8ryN+meCVItwGaklLa2ei3j6sOXL1YPLaxXKMLu2+VD33YKnItIfOAUmdM6jMfUKQT 9bwhFCAsHJyPtLn7FfIeSjYPPEKtvkzpKoVJ+IunihrBWG/VhSPDGXXSGn3FUPFWYmqI XmSQ== X-Forwarded-Encrypted: i=1; AJvYcCWxRjl02f8w/N78BnrvFeezf0PdyH+KXRuMVAYdgrLrmiyQvWur/4to7LT2DntPhI/Vj9qR1hedjCSFN+Y=@vger.kernel.org X-Gm-Message-State: AOJu0YzUWVdc81t5EtfVyZqoY4NujRFYD3W6GaYt4C2nekIDt4bAU0TR Ys4inKDLS0DeloSyPZRqhwMPi2C0iim7blbJUdEgBkYUemi1AZQaSuu837kNv1d1LxHdbiwPWdf AgA== X-Google-Smtp-Source: AGHT+IF65rUIuTMqRgVl+qHoagCMc0Oa679N7rInTQJ8+VGZg85VOD9YW+b2TmMSzy1ThwGbMVoYpUEMUg8= X-Received: from pjbse7.prod.google.com ([2002:a17:90b:5187:b0:2ee:4a90:3d06]) (user=seanjc job=prod-delivery.src-stubby-dispatcher) by 2002:a17:90b:2248:b0:2fa:2124:8782 with SMTP id 98e67ed59e1d1-2fe7e39f185mr8673035a91.25.1740619552385; Wed, 26 Feb 2025 17:25:52 -0800 (PST) Reply-To: Sean Christopherson Date: Wed, 26 Feb 2025 17:25:36 -0800 In-Reply-To: <20250227012541.3234589-1-seanjc@google.com> Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: Mime-Version: 1.0 References: <20250227012541.3234589-1-seanjc@google.com> X-Mailer: git-send-email 2.48.1.711.g2feabab25a-goog Message-ID: <20250227012541.3234589-6-seanjc@google.com> Subject: [PATCH v2 05/10] KVM: SVM: Require AP's "requested" SEV_FEATURES to match KVM's view From: Sean Christopherson To: Sean Christopherson , Paolo Bonzini Cc: kvm@vger.kernel.org, linux-kernel@vger.kernel.org, Naveen N Rao , Kim Phillips , Tom Lendacky , Alexey Kardashevskiy , Pankaj Gupta Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="utf-8" When handling an "AP Create" event, return an error if the "requested" SEV features for the vCPU don't exactly match KVM's view of the VM-scoped features. There is no known use case for heterogeneous SEV features across vCPUs, and while KVM can't actually enforce an exact match since the value in RAX isn't guaranteed to match what the guest shoved into the VMSA, KVM can at least avoid knowingly letting the guest run in an unsupported state. E.g. if a VM is created with DebugSwap disabled, KVM will intercept #DBs and DRs for all vCPUs, even if an AP is "created" with DebugSwap enabled in its VMSA. Note, the GHCB spec only "requires" that "AP use the same interrupt injection mechanism as the BSP", but given the disaster that is DebugSwap and SEV_FEATURES in general, it's safe to say that AMD didn't consider all possible complications with mismatching features between the BSP and APs. Opportunistically fold the check into the relevant request flavors; the "request < AP_DESTROY" check is just a bizarre way of implementing the AP_CREATE_ON_INIT =3D> AP_CREATE fallthrough. Fixes: e366f92ea99e ("KVM: SEV: Support SEV-SNP AP Creation NAE event") Reviewed-by: Tom Lendacky Signed-off-by: Sean Christopherson Reviewed-by: Pankaj Gupta --- arch/x86/kvm/svm/sev.c | 23 ++++++++--------------- 1 file changed, 8 insertions(+), 15 deletions(-) diff --git a/arch/x86/kvm/svm/sev.c b/arch/x86/kvm/svm/sev.c index 9aad0dae3a80..bad5834ec143 100644 --- a/arch/x86/kvm/svm/sev.c +++ b/arch/x86/kvm/svm/sev.c @@ -3932,6 +3932,7 @@ void sev_snp_init_protected_guest_state(struct kvm_vc= pu *vcpu) =20 static int sev_snp_ap_creation(struct vcpu_svm *svm) { + struct kvm_sev_info *sev =3D to_kvm_sev_info(svm->vcpu.kvm); struct kvm_vcpu *vcpu =3D &svm->vcpu; struct kvm_vcpu *target_vcpu; struct vcpu_svm *target_svm; @@ -3963,26 +3964,18 @@ static int sev_snp_ap_creation(struct vcpu_svm *svm) =20 mutex_lock(&target_svm->sev_es.snp_vmsa_mutex); =20 - /* Interrupt injection mode shouldn't change for AP creation */ - if (request < SVM_VMGEXIT_AP_DESTROY) { - u64 sev_features; - - sev_features =3D vcpu->arch.regs[VCPU_REGS_RAX]; - sev_features ^=3D to_kvm_sev_info(svm->vcpu.kvm)->vmsa_features; - - if (sev_features & SVM_SEV_FEAT_INT_INJ_MODES) { - vcpu_unimpl(vcpu, "vmgexit: invalid AP injection mode [%#lx] from guest= \n", - vcpu->arch.regs[VCPU_REGS_RAX]); - ret =3D -EINVAL; - goto out; - } - } - switch (request) { case SVM_VMGEXIT_AP_CREATE_ON_INIT: kick =3D false; fallthrough; case SVM_VMGEXIT_AP_CREATE: + if (vcpu->arch.regs[VCPU_REGS_RAX] !=3D sev->vmsa_features) { + vcpu_unimpl(vcpu, "vmgexit: mismatched AP sev_features [%#lx] !=3D [%#l= lx] from guest\n", + vcpu->arch.regs[VCPU_REGS_RAX], sev->vmsa_features); + ret =3D -EINVAL; + goto out; + } + if (!page_address_valid(vcpu, svm->vmcb->control.exit_info_2)) { vcpu_unimpl(vcpu, "vmgexit: invalid AP VMSA address [%#llx] from guest\= n", svm->vmcb->control.exit_info_2); --=20 2.48.1.711.g2feabab25a-goog From nobody Fri Dec 19 06:21:03 2025 Received: from mail-pl1-f202.google.com (mail-pl1-f202.google.com [209.85.214.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 61EAF1C6FF8 for ; Thu, 27 Feb 2025 01:25:54 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=209.85.214.202 ARC-Seal: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1740619555; cv=none; b=kdDbs05Pqk9Mo1iphmZg3FtQZRDUB+CINnXYcK6xMk2CCOToRHaE48nR9QXoW1+5KNJsaYfam+U/JrsOWvLMNGdVTGvcx6kCYN2CyLLcEiP5zCvxIMjAUow9xgndkpVuYpe8BL9fxpRPOoytbDXiBBLXW8QGnC/mVH4wwF3gadw= ARC-Message-Signature: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1740619555; c=relaxed/simple; bh=dDR1QpQVcSQvKqFE0KvEiZ7AYWgfuYaS5/Kd55ia8vU=; h=Date:In-Reply-To:Mime-Version:References:Message-ID:Subject:From: To:Cc:Content-Type; b=jq541uysl0qHad4pH37Ul9gNR8iipIkCOzgKh+g46nkWkdRdrxyYzk5iyVl79RZD4VaoFLnFkRnG4sv247kWymL5Ga/zgYvFn4MScJsHRFV11TjvnbJKKpgGyDY6/6i0MCBQdA48ip9phAn78db0xj7H4eyn5duCKaEMvWYTLp8= 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=CN7O9/qy; arc=none smtp.client-ip=209.85.214.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="CN7O9/qy" Received: by mail-pl1-f202.google.com with SMTP id d9443c01a7336-22328fb6cbfso7431975ad.2 for ; Wed, 26 Feb 2025 17:25:54 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20230601; t=1740619554; x=1741224354; darn=vger.kernel.org; h=cc:to:from:subject:message-id:references:mime-version:in-reply-to :date:reply-to:from:to:cc:subject:date:message-id:reply-to; bh=HpoG9IAubpCDT+wLYzi42QtAGv2cg0ICoGBus9dCqMw=; b=CN7O9/qysEZ8W+P+Y8JduIxwXS2sDL4Me2lMWiDi7LESsP5BCCnccbncUpeSJTYcpi AAmcjnGBP/RZG2mCGZUXAJli5V2K0JjJxClbE8h7gN+Mv2UwF8Ol0Kmr40EDP8blk3ox VQBJvLq2wetwBcfB/3E6FhMIZ89PmZv4ZQ517KqAdNQC+jy+iGDrBE/QR9XsobDFT7rg jR+uqqx/hhkgPUPwN6ORVzSwixoEFVPiX5rq7x1agydCpHnnfzaBtEgptafHe5yDhA16 8jevoINcvTB1L/WI5jekykFJU0LKVhHWqYiP2uPiZUaE3iLcZkcdJqqWYdOUSQG8mdoc IU2A== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1740619554; x=1741224354; h=cc:to:from:subject:message-id:references:mime-version:in-reply-to :date:reply-to:x-gm-message-state:from:to:cc:subject:date:message-id :reply-to; bh=HpoG9IAubpCDT+wLYzi42QtAGv2cg0ICoGBus9dCqMw=; b=DP4u5ouD89qh/LRbxB554YHqpbe7urTs1w1f2t6w039IytgEs0/3SOXy1kWWQR9hS/ VHiJGRBCt4kiEBJmJs5WqIXIXmbFnxhgZ4JC2phW6MeXUIi9Er7C3yXK66l943sh58ZD YbdBhRLDmAzZdmrykZBDS3uZ23wG/t8gOMeyGmXMwE9AzSWKlLqP8g0/p+xAQahn5XJZ EINn4ODsohGk3Bl12TB9q4F+xMct5F2S/EG2LB3Kcrsc+Blc2YYwzkze2zdjKi0N6Ejl hZsOEWR+yzEW7JZifZ/BLKd2S37bG9Nl07HEDQd9WAXDNKJhYrakDW5Nt+3cbMQQJK/n kJ3Q== X-Forwarded-Encrypted: i=1; AJvYcCVPh297yq2kZcfexarRHg02afxAxnkdw3TH0O4rVcrwP1wfz/zQ/O3KNLplGVZfamg8hB5sziGQgiadAqc=@vger.kernel.org X-Gm-Message-State: AOJu0YwEj3+44cx9Z18c9JTzt4et87/kG4Zfc1d8JerJdar9OR1tJl5N zMQGx5YqwjHyC/VkladIyA0Ncxoq9nGUxy4AJzRD0iXx5LolqTugk08JxKepirkumb59mk0dPqq rAA== X-Google-Smtp-Source: AGHT+IGescKmvLpkcPFFde/D5wUCncfjV68Ld5mkBOALQrlPwQFVWlWLOcBp8zNKxty+sQjM+lwnvjXZb/A= X-Received: from pjbsw3.prod.google.com ([2002:a17:90b:2c83:b0:2fa:15aa:4d2b]) (user=seanjc job=prod-delivery.src-stubby-dispatcher) by 2002:a17:903:22c7:b0:220:cd7f:cde8 with SMTP id d9443c01a7336-22307b5b218mr150692835ad.29.1740619553863; Wed, 26 Feb 2025 17:25:53 -0800 (PST) Reply-To: Sean Christopherson Date: Wed, 26 Feb 2025 17:25:37 -0800 In-Reply-To: <20250227012541.3234589-1-seanjc@google.com> Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: Mime-Version: 1.0 References: <20250227012541.3234589-1-seanjc@google.com> X-Mailer: git-send-email 2.48.1.711.g2feabab25a-goog Message-ID: <20250227012541.3234589-7-seanjc@google.com> Subject: [PATCH v2 06/10] KVM: SVM: Simplify request+kick logic in SNP AP Creation handling From: Sean Christopherson To: Sean Christopherson , Paolo Bonzini Cc: kvm@vger.kernel.org, linux-kernel@vger.kernel.org, Naveen N Rao , Kim Phillips , Tom Lendacky , Alexey Kardashevskiy , Pankaj Gupta Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="utf-8" Drop the local "kick" variable and the unnecessary "fallthrough" logic from sev_snp_ap_creation(), and simply pivot on the request when deciding whether or not to immediate force a state update on the target vCPU. No functional change intended. Reviewed-by: Pankaj Gupta Reviewed-by: Tom Lendacky Signed-off-by: Sean Christopherson --- arch/x86/kvm/svm/sev.c | 15 +++++---------- 1 file changed, 5 insertions(+), 10 deletions(-) diff --git a/arch/x86/kvm/svm/sev.c b/arch/x86/kvm/svm/sev.c index bad5834ec143..ccac840ee7be 100644 --- a/arch/x86/kvm/svm/sev.c +++ b/arch/x86/kvm/svm/sev.c @@ -3938,7 +3938,6 @@ static int sev_snp_ap_creation(struct vcpu_svm *svm) struct vcpu_svm *target_svm; unsigned int request; unsigned int apic_id; - bool kick; int ret; =20 request =3D lower_32_bits(svm->vmcb->control.exit_info_1); @@ -3956,18 +3955,10 @@ static int sev_snp_ap_creation(struct vcpu_svm *svm) =20 target_svm =3D to_svm(target_vcpu); =20 - /* - * The target vCPU is valid, so the vCPU will be kicked unless the - * request is for CREATE_ON_INIT. - */ - kick =3D true; - mutex_lock(&target_svm->sev_es.snp_vmsa_mutex); =20 switch (request) { case SVM_VMGEXIT_AP_CREATE_ON_INIT: - kick =3D false; - fallthrough; case SVM_VMGEXIT_AP_CREATE: if (vcpu->arch.regs[VCPU_REGS_RAX] !=3D sev->vmsa_features) { vcpu_unimpl(vcpu, "vmgexit: mismatched AP sev_features [%#lx] !=3D [%#l= lx] from guest\n", @@ -4012,7 +4003,11 @@ static int sev_snp_ap_creation(struct vcpu_svm *svm) =20 target_svm->sev_es.snp_ap_waiting_for_reset =3D true; =20 - if (kick) { + /* + * Unless Creation is deferred until INIT, signal the vCPU to update + * its state. + */ + if (request !=3D SVM_VMGEXIT_AP_CREATE_ON_INIT) { kvm_make_request(KVM_REQ_UPDATE_PROTECTED_GUEST_STATE, target_vcpu); kvm_vcpu_kick(target_vcpu); } --=20 2.48.1.711.g2feabab25a-goog From nobody Fri Dec 19 06:21:03 2025 Received: from mail-pj1-f74.google.com (mail-pj1-f74.google.com [209.85.216.74]) (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 3BAA61D5AD3 for ; Thu, 27 Feb 2025 01:25:56 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=209.85.216.74 ARC-Seal: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1740619557; cv=none; b=twNGsODgofmpr6VgM+QjwQYBJirj6SCahzTDiSLHiTB1pToF1xdup//Z/rGpZDVafc23Ee6YwIKSjg3B+w79eusuJijSp6LG4+e8YtXKF0GzOryG1FdA77Hl1sufdla12BleoT3rdblDFKVpQH4uXpPBR8EQjQ5RIGUSXCVTTJY= ARC-Message-Signature: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1740619557; c=relaxed/simple; bh=ihlJ9tzG+mbom6E97CofCJ2twZFC8ydoAcNMa4ieq/g=; h=Date:In-Reply-To:Mime-Version:References:Message-ID:Subject:From: To:Cc:Content-Type; b=abIY4/97pBztDFqtum86EIa2ypF1oqJl/wtntQRVTWjprge7/bJhmHZUI/6xSjPXMbjC/PTG91AAE+anKI14gzcsTRJBRS59icjJPLst02wBB8gUlx1Zr7U4gy5R3eXgNaxx74o11I5jCxwrJl8e1QsyoVfZzEWmjLI/C1fgoMQ= 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=1y5yYQbJ; arc=none smtp.client-ip=209.85.216.74 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="1y5yYQbJ" Received: by mail-pj1-f74.google.com with SMTP id 98e67ed59e1d1-2fe870bc003so894887a91.1 for ; Wed, 26 Feb 2025 17:25:55 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20230601; t=1740619555; x=1741224355; darn=vger.kernel.org; h=cc:to:from:subject:message-id:references:mime-version:in-reply-to :date:reply-to:from:to:cc:subject:date:message-id:reply-to; bh=BEh4czcyv0mwjR2KnuYAlHnHA3zyOkXJCuOnzE1/d90=; b=1y5yYQbJIZe7LrJamcdgKbiKDM1gPax2kmBZlGbVuISqYPUr5DzcJmczf/VOsqMyXw n9QpFnxmkNF0Of3cxcFb0HU3BsLjmLDtPU/f28oqXLHYiQqiA5TuLx9gu8QxWblXNlEm QZSTAIv7bgc+n/Dwj7JtTmPV205sNYqGFOechCs1o/VU1IUFb0VBFogmfHGehx64n/QO OkgV5ot0orbQ6rylpCwLHshubY5j557zgamF/iaFGlSkWVKq3uq0EKhjROU3lT+YYBnA /oWlEwsxvDiTgDvn8EvubnbDYwHfvK49layanvqeRslra155l4y1Rob6kgyhuuI4nYO0 Rwgw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1740619555; x=1741224355; h=cc:to:from:subject:message-id:references:mime-version:in-reply-to :date:reply-to:x-gm-message-state:from:to:cc:subject:date:message-id :reply-to; bh=BEh4czcyv0mwjR2KnuYAlHnHA3zyOkXJCuOnzE1/d90=; b=Dz3qeLxD9Y1ud19JYDPp1YeJO6lN/ACLuNZU2Nfjrw2hNl55uuRHAmMnUYRoaF5VM6 or3MPAqgEodq3f2c46I1BjfBnECDQfqL93xR8SC4+qI9vYRS5hXgmyriwC9Nm/D3YfWc 3SBsQ2aqv+5b2RP68HNNME7kFU2bRAbtdw5EJ6zjUKRxhgFINXIepwfhba+tFH10wxaS b8hZ+bcGEMl4S8Id3OR1WD8R1AJJ+RPI4eMuZbZrTeDaJx++D9kVW6vWtU5FUEOupfLX mbOFV1KUAzQwTjmPGF8fNsdC07r+4zdh40tLz4Z+srZMWhA0DcB1flc/84LD60W87Hj2 He2Q== X-Forwarded-Encrypted: i=1; AJvYcCVpzWswTVY+UFDuXl+g8KvZXTaQmnILPJ7FNpVjbFRcsfcQRMvcbOGT7/2YX4oeBWPNnfoO8OCgw+dm0/w=@vger.kernel.org X-Gm-Message-State: AOJu0YwZgcsVX69G4l04ujIafVWbjdS9fqX950DWFzJVh0gCervKhBtg KfjQ1yCnP4pPoHJ17bB8XLw9mmFQ4agbGlOqqzIVd2CuSIui+I04VTqLxrpFL8uk6+yrnbf7dyT RGg== X-Google-Smtp-Source: AGHT+IExjvD2wlKO1qXHAmeJHBp9Socb/v6Efvhq9YmZiRdyzuZ7b7PT/K+5yF4GkgpWs3T5dFKOYmAE6Qs= X-Received: from pjbtd3.prod.google.com ([2002:a17:90b:5443:b0:2ef:d283:5089]) (user=seanjc job=prod-delivery.src-stubby-dispatcher) by 2002:a17:90b:38d2:b0:2f6:e47c:1750 with SMTP id 98e67ed59e1d1-2fea12f2a2amr2349083a91.13.1740619555492; Wed, 26 Feb 2025 17:25:55 -0800 (PST) Reply-To: Sean Christopherson Date: Wed, 26 Feb 2025 17:25:38 -0800 In-Reply-To: <20250227012541.3234589-1-seanjc@google.com> Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: Mime-Version: 1.0 References: <20250227012541.3234589-1-seanjc@google.com> X-Mailer: git-send-email 2.48.1.711.g2feabab25a-goog Message-ID: <20250227012541.3234589-8-seanjc@google.com> Subject: [PATCH v2 07/10] KVM: SVM: Use guard(mutex) to simplify SNP AP Creation error handling From: Sean Christopherson To: Sean Christopherson , Paolo Bonzini Cc: kvm@vger.kernel.org, linux-kernel@vger.kernel.org, Naveen N Rao , Kim Phillips , Tom Lendacky , Alexey Kardashevskiy , Pankaj Gupta Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="utf-8" Use guard(mutex) in sev_snp_ap_creation() and modify the error paths to return directly instead of jumping to a common exit point. No functional change intended. Reviewed-by: Tom Lendacky Signed-off-by: Sean Christopherson Reviewed-by: Pankaj Gupta --- arch/x86/kvm/svm/sev.c | 22 ++++++---------------- 1 file changed, 6 insertions(+), 16 deletions(-) diff --git a/arch/x86/kvm/svm/sev.c b/arch/x86/kvm/svm/sev.c index ccac840ee7be..dd9511a2254b 100644 --- a/arch/x86/kvm/svm/sev.c +++ b/arch/x86/kvm/svm/sev.c @@ -3938,7 +3938,6 @@ static int sev_snp_ap_creation(struct vcpu_svm *svm) struct vcpu_svm *target_svm; unsigned int request; unsigned int apic_id; - int ret; =20 request =3D lower_32_bits(svm->vmcb->control.exit_info_1); apic_id =3D upper_32_bits(svm->vmcb->control.exit_info_1); @@ -3951,11 +3950,9 @@ static int sev_snp_ap_creation(struct vcpu_svm *svm) return -EINVAL; } =20 - ret =3D 0; - target_svm =3D to_svm(target_vcpu); =20 - mutex_lock(&target_svm->sev_es.snp_vmsa_mutex); + guard(mutex)(&target_svm->sev_es.snp_vmsa_mutex); =20 switch (request) { case SVM_VMGEXIT_AP_CREATE_ON_INIT: @@ -3963,15 +3960,13 @@ static int sev_snp_ap_creation(struct vcpu_svm *svm) if (vcpu->arch.regs[VCPU_REGS_RAX] !=3D sev->vmsa_features) { vcpu_unimpl(vcpu, "vmgexit: mismatched AP sev_features [%#lx] !=3D [%#l= lx] from guest\n", vcpu->arch.regs[VCPU_REGS_RAX], sev->vmsa_features); - ret =3D -EINVAL; - goto out; + return -EINVAL; } =20 if (!page_address_valid(vcpu, svm->vmcb->control.exit_info_2)) { vcpu_unimpl(vcpu, "vmgexit: invalid AP VMSA address [%#llx] from guest\= n", svm->vmcb->control.exit_info_2); - ret =3D -EINVAL; - goto out; + return -EINVAL; } =20 /* @@ -3985,8 +3980,7 @@ static int sev_snp_ap_creation(struct vcpu_svm *svm) vcpu_unimpl(vcpu, "vmgexit: AP VMSA address [%llx] from guest is unsafe as it is 2M = aligned\n", svm->vmcb->control.exit_info_2); - ret =3D -EINVAL; - goto out; + return -EINVAL; } =20 target_svm->sev_es.snp_vmsa_gpa =3D svm->vmcb->control.exit_info_2; @@ -3997,8 +3991,7 @@ static int sev_snp_ap_creation(struct vcpu_svm *svm) default: vcpu_unimpl(vcpu, "vmgexit: invalid AP creation request [%#x] from guest= \n", request); - ret =3D -EINVAL; - goto out; + return -EINVAL; } =20 target_svm->sev_es.snp_ap_waiting_for_reset =3D true; @@ -4012,10 +4005,7 @@ static int sev_snp_ap_creation(struct vcpu_svm *svm) kvm_vcpu_kick(target_vcpu); } =20 -out: - mutex_unlock(&target_svm->sev_es.snp_vmsa_mutex); - - return ret; + return 0; } =20 static int snp_handle_guest_req(struct vcpu_svm *svm, gpa_t req_gpa, gpa_t= resp_gpa) --=20 2.48.1.711.g2feabab25a-goog From nobody Fri Dec 19 06:21:03 2025 Received: from mail-pl1-f201.google.com (mail-pl1-f201.google.com [209.85.214.201]) (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 E338B22DF84 for ; Thu, 27 Feb 2025 01:25:57 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=209.85.214.201 ARC-Seal: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1740619559; cv=none; b=MGobCFy+WY1eNvPDQ4NzlBq12ZqQVPXvq8NfM34romHm7pHcOhJdaNDdw9VIqev5Zfs2Tmybq/hXdzeoOJI0zMFdp6MAjchG3TM1rjQH+xwXwGd05WkGoLKpSpDZgekDb8lnEiavVNM4J4GRqQafnamREoEwluuefsDJBtxeRPQ= ARC-Message-Signature: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1740619559; c=relaxed/simple; bh=3rMdxdgx2qWe5YUgeEwNff8fTKobVmh249Xk/BEEAbw=; h=Date:In-Reply-To:Mime-Version:References:Message-ID:Subject:From: To:Cc:Content-Type; b=V/p3CGKVvUxTeBhEh7hcYNaA+rNI2d7l3fiwgLj4OapHPMAz+1E4nd2oBnKK7ffLdoX7kB3RIqKDqO+h6g5B5zZrMyKs9Yeb5tWTw+YSPd1O7m+gYLWShodEAJFQXZGPFzvNVWsj4cBMfckIjB2HCU9O3OP/ovMSSZT0Kb0gYQg= 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=27shFyFa; arc=none smtp.client-ip=209.85.214.201 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="27shFyFa" Received: by mail-pl1-f201.google.com with SMTP id d9443c01a7336-22331df540aso11214745ad.1 for ; Wed, 26 Feb 2025 17:25:57 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20230601; t=1740619557; x=1741224357; darn=vger.kernel.org; h=cc:to:from:subject:message-id:references:mime-version:in-reply-to :date:reply-to:from:to:cc:subject:date:message-id:reply-to; bh=lmdAwPEyCZdB0cvoeTHRqa3iDsz832lsztWM5iTizzQ=; b=27shFyFa7us91YMSdCLNQFswgRfPh3a60qe4ZSGaUmrTexGUEHhGJq9E7wpAcy0A3X CWumEerMK5luUsBakwMWHBMPujn4G1dFkx47+CO8YM0keftCapeTcH5BfeQyEwLg54Qs RvsF1mAC1xFrU5YNtOTkRoNDTVbc9bx81Xc123nvzwvAwzuikUqBgWYNMrRF8muYqE3e d67MMFx4zJkbTmibnG40wwRlPYEqM6smB5aaaIJctBJon8vS9qAcfiSA+esPa9ULN+86 f4GdKWzXV4aTA7YH7PvIP0xLgaUmWiJnVjV9coFVdA5WfUajXLBPa0LD1rZbk8k8e1VM YpLw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1740619557; x=1741224357; h=cc:to:from:subject:message-id:references:mime-version:in-reply-to :date:reply-to:x-gm-message-state:from:to:cc:subject:date:message-id :reply-to; bh=lmdAwPEyCZdB0cvoeTHRqa3iDsz832lsztWM5iTizzQ=; b=tsto+vqk5Ll0nzkNES7f/nasndF++nzvmWxbtMSUoRjAadDaplDvOjt/JDxLaL3FWc czmcKAVxrFkSQpwRlfKIa+JVTQ2mvyY5ga079xA+NUVkFXVzjb+42XmF8pH9fGQfmcxb HXkhITLtnBBG+cgYeJqA/kdO1P4HZvoTqhE8JxheFcDGTOwhkxquqDkRIuTy3f6dXhXb p5Tzjug3t/kmVQMRI32/PNZdjsp/3BitCNfsax7ioOlCrA0LNt4O2YK/nx4ICyloRGH1 URpk/t0wC2HDQFVjkgIFbwDg4pRPz/63dUyfffLprUC4YoTdIo/XDHuppoDcPSkfjuKo uQDg== X-Forwarded-Encrypted: i=1; AJvYcCWC7gRR38YL9xjVUwvB+Q0xam4+ObNHwcNDzN6QQo3Aa0jlqHCGhq9JGWRg4mogLuchAzOXOMZDrbe0HQw=@vger.kernel.org X-Gm-Message-State: AOJu0YyiT8PPKmYizeWtGk+RjD4+IzqJxSjigMheOdaBYjIydBTlKWNL SLKlIugvOX5DGkmYuyi6j6URn3p6P0YfodKlbs2Fx715VSp01TcxuNvl8FCZcRfbFpZmqfYeFs5 Zmw== X-Google-Smtp-Source: AGHT+IGyW+IanDv2gn10X8mgRJgrQ6dxChAv+7NcHxpQspV9qJhboJEE29I20MwBycuSfUIjaysnSToTWm4= X-Received: from pfbik10.prod.google.com ([2002:a05:6a00:8d0a:b0:730:4672:64ac]) (user=seanjc job=prod-delivery.src-stubby-dispatcher) by 2002:a05:6a00:1709:b0:732:2967:400 with SMTP id d2e1a72fcca58-7347910977emr15073690b3a.12.1740619557217; Wed, 26 Feb 2025 17:25:57 -0800 (PST) Reply-To: Sean Christopherson Date: Wed, 26 Feb 2025 17:25:39 -0800 In-Reply-To: <20250227012541.3234589-1-seanjc@google.com> Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: Mime-Version: 1.0 References: <20250227012541.3234589-1-seanjc@google.com> X-Mailer: git-send-email 2.48.1.711.g2feabab25a-goog Message-ID: <20250227012541.3234589-9-seanjc@google.com> Subject: [PATCH v2 08/10] KVM: SVM: Mark VMCB dirty before processing incoming snp_vmsa_gpa From: Sean Christopherson To: Sean Christopherson , Paolo Bonzini Cc: kvm@vger.kernel.org, linux-kernel@vger.kernel.org, Naveen N Rao , Kim Phillips , Tom Lendacky , Alexey Kardashevskiy , Pankaj Gupta Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="utf-8" Mark the VMCB dirty, i.e. zero control.clean, prior to handling the new VMSA. Nothing in the VALID_PAGE() case touches control.clean, and isolating the VALID_PAGE() code will allow simplifying the overall logic. Note, the VMCB probably doesn't need to be marked dirty when the VMSA is invalid, as KVM will disallow running the vCPU in such a state. But it also doesn't hurt anything. Reviewed-by: Tom Lendacky Signed-off-by: Sean Christopherson --- arch/x86/kvm/svm/sev.c | 12 ++++++------ 1 file changed, 6 insertions(+), 6 deletions(-) diff --git a/arch/x86/kvm/svm/sev.c b/arch/x86/kvm/svm/sev.c index dd9511a2254b..c74cc64ceb81 100644 --- a/arch/x86/kvm/svm/sev.c +++ b/arch/x86/kvm/svm/sev.c @@ -3850,6 +3850,12 @@ static int __sev_snp_update_protected_guest_state(st= ruct kvm_vcpu *vcpu) /* Clear use of the VMSA */ svm->vmcb->control.vmsa_pa =3D INVALID_PAGE; =20 + /* + * When replacing the VMSA during SEV-SNP AP creation, + * mark the VMCB dirty so that full state is always reloaded. + */ + vmcb_mark_all_dirty(svm->vmcb); + if (VALID_PAGE(svm->sev_es.snp_vmsa_gpa)) { gfn_t gfn =3D gpa_to_gfn(svm->sev_es.snp_vmsa_gpa); struct kvm_memory_slot *slot; @@ -3895,12 +3901,6 @@ static int __sev_snp_update_protected_guest_state(st= ruct kvm_vcpu *vcpu) kvm_release_page_clean(page); } =20 - /* - * When replacing the VMSA during SEV-SNP AP creation, - * mark the VMCB dirty so that full state is always reloaded. - */ - vmcb_mark_all_dirty(svm->vmcb); - return 0; } =20 --=20 2.48.1.711.g2feabab25a-goog From nobody Fri Dec 19 06:21:03 2025 Received: from mail-pj1-f73.google.com (mail-pj1-f73.google.com [209.85.216.73]) (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 8C5C622E3E6 for ; Thu, 27 Feb 2025 01:25:59 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=209.85.216.73 ARC-Seal: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1740619561; cv=none; b=U1NPF91YoAW1vvA8dhhnLm+1j1vwkYhROdlzS8h0zuR5noLa4WLhwj++zVGS3X2L0cjidD0KQYm0zxhqjvjJ18EKg92CCcs87kqVSE9SDIYia3F0N/nEO1LFvlam5gMuL395elAJ/HqOghpolN+VatqbqdJKhFkuNDdp9AlZjWM= ARC-Message-Signature: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1740619561; c=relaxed/simple; bh=SlIP7vUVEAl3Nff6A3KsmF5s6lnEtycCZy5mDlywOrM=; h=Date:In-Reply-To:Mime-Version:References:Message-ID:Subject:From: To:Cc:Content-Type; b=nSo3Ygn3d8GgsnEwkF+gJL2veuD3A2Y8NNrjD9K0fxtJ0k9xncCpslBqdny9uWHVw1S93ky9pMAxxKw50JSNHV8BMpaM9NpW9cUlFs7Fj+m8h7pj/cH5bUQMClTpFbBpPrH52/LVoXg9Vw5aztYErnWpH5TkqohBhmfpB4u7oHM= 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=gISGwIj3; arc=none smtp.client-ip=209.85.216.73 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="gISGwIj3" Received: by mail-pj1-f73.google.com with SMTP id 98e67ed59e1d1-2fe8c5dbdb0so960943a91.3 for ; Wed, 26 Feb 2025 17:25:59 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20230601; t=1740619559; x=1741224359; darn=vger.kernel.org; h=cc:to:from:subject:message-id:references:mime-version:in-reply-to :date:reply-to:from:to:cc:subject:date:message-id:reply-to; bh=IOWwEu0l/k3HhYntL/yg0gERPToOEmSlz8zTPMBWJgM=; b=gISGwIj3vhxdRYYF83elUi4DoTM6Y4ggEZPZtUJhMf4xfHehe3LNKkSQtpWVhpBBF4 0N/86YkqRAaoW/xtpjwAhVDro6pDvS8WGJ+ubOAbeciuhkTBFtTqIyuHcH6S+CfsmbC4 ahO1TJSJ+Aw2WHtsCijR4R5m7PlQI8WNIIrfrSIKjfhfuq40jypKHVSPwz5VHNIWG8s1 jpBIKMx1YrO97yQrxZwRcDRT2suMMfJ5xxRlxPZ5T6i8TLmH2BBXqx4tAvSgN38arWf/ ZdM9kJMEM77TBdtkjFNJXPpkozBAMYYAlrPBUV7rm3GGX6uEAftRyO6sx8O5veYVTgdg 1U2Q== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1740619559; x=1741224359; h=cc:to:from:subject:message-id:references:mime-version:in-reply-to :date:reply-to:x-gm-message-state:from:to:cc:subject:date:message-id :reply-to; bh=IOWwEu0l/k3HhYntL/yg0gERPToOEmSlz8zTPMBWJgM=; b=js3UmB+71tul40ZD7UW4UBmmiu2wkeNJdtXb1mZMOH+dUUERn5is0TgdfqhXpRshrU MwfAKWWCum8BWBYmgnvcmyvgbgGCm+TEn7jX+HtLLWn3EOBb9EjGzaF9k9x9ApwLg3BX 3poKbZFXYiP0QhLFQTS1xxYCkzmYD6PCzkTuV/e7OYMsDT0pj0tLBne2ROPq4b0YHJK1 9CONNRh9pXFDk3FejAPeiXCHCdtaBKt3KS2V8wzVnePXw+8Mw18G9UUhbc+LMw2ef+F4 vv63eGQ/aQC70RPvOR/ki/U3pGWBALfbmyOGJ75L7OxcpEbzLeJ4UbJC9NpYuecIIx7X /4eQ== X-Forwarded-Encrypted: i=1; AJvYcCWOueKX98Kg6USlXAer8MBKrPdgCAcc89vGsV4aRu40d5HNawybq3tedeavY8LP9OwX3RCb2/clIrId7SQ=@vger.kernel.org X-Gm-Message-State: AOJu0YwsFrXNWue9f0Gr5SopE7sP8FXpjZhOipOlxo7MWGzNwgJl0LUs 29f4+izT/i/FpyGPBPQekpZvz3pErYGcB8YcbOQt9bw8ofCHaaDJVUUaypAC3Smnk/XHGGQKMXY CIg== X-Google-Smtp-Source: AGHT+IGFu8FDn0du2s+v5ekzGMy8fn8oWBPrPcbohW0kjuPN3LZYNucs2Vyp5314eaCBsaigs6BDRwkMzfU= X-Received: from pja5.prod.google.com ([2002:a17:90b:5485:b0:2fa:1fac:2695]) (user=seanjc job=prod-delivery.src-stubby-dispatcher) by 2002:a17:90b:2502:b0:2fe:9783:afd3 with SMTP id 98e67ed59e1d1-2fe9783b117mr3818666a91.2.1740619558983; Wed, 26 Feb 2025 17:25:58 -0800 (PST) Reply-To: Sean Christopherson Date: Wed, 26 Feb 2025 17:25:40 -0800 In-Reply-To: <20250227012541.3234589-1-seanjc@google.com> Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: Mime-Version: 1.0 References: <20250227012541.3234589-1-seanjc@google.com> X-Mailer: git-send-email 2.48.1.711.g2feabab25a-goog Message-ID: <20250227012541.3234589-10-seanjc@google.com> Subject: [PATCH v2 09/10] KVM: SVM: Use guard(mutex) to simplify SNP vCPU state updates From: Sean Christopherson To: Sean Christopherson , Paolo Bonzini Cc: kvm@vger.kernel.org, linux-kernel@vger.kernel.org, Naveen N Rao , Kim Phillips , Tom Lendacky , Alexey Kardashevskiy , Pankaj Gupta Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="utf-8" Use guard(mutex) in sev_snp_init_protected_guest_state() and pull in its lock-protected inner helper. Without an unlock trampoline (and even with one), there is no real need for an inner helper. Eliminating the helper also avoids having to fixup the open coded "lockdep" WARN_ON(). Opportunistically drop the error message if KVM can't obtain the pfn for the new target VMSA. The error message provides zero information that can't be gleaned from the fact that the vCPU is stuck. Reviewed-by: Tom Lendacky Signed-off-by: Sean Christopherson --- arch/x86/kvm/svm/sev.c | 122 ++++++++++++++++++----------------------- 1 file changed, 53 insertions(+), 69 deletions(-) diff --git a/arch/x86/kvm/svm/sev.c b/arch/x86/kvm/svm/sev.c index c74cc64ceb81..3f85bd1cac37 100644 --- a/arch/x86/kvm/svm/sev.c +++ b/arch/x86/kvm/svm/sev.c @@ -3837,11 +3837,26 @@ static int snp_begin_psc(struct vcpu_svm *svm, stru= ct psc_buffer *psc) BUG(); } =20 -static int __sev_snp_update_protected_guest_state(struct kvm_vcpu *vcpu) +/* + * Invoked as part of svm_vcpu_reset() processing of an init event. + */ +void sev_snp_init_protected_guest_state(struct kvm_vcpu *vcpu) { struct vcpu_svm *svm =3D to_svm(vcpu); + struct kvm_memory_slot *slot; + struct page *page; + kvm_pfn_t pfn; + gfn_t gfn; =20 - WARN_ON(!mutex_is_locked(&svm->sev_es.snp_vmsa_mutex)); + if (!sev_snp_guest(vcpu->kvm)) + return; + + guard(mutex)(&svm->sev_es.snp_vmsa_mutex); + + if (!svm->sev_es.snp_ap_waiting_for_reset) + return; + + svm->sev_es.snp_ap_waiting_for_reset =3D false; =20 /* Mark the vCPU as offline and not runnable */ vcpu->arch.pv.pv_unhalted =3D false; @@ -3856,78 +3871,47 @@ static int __sev_snp_update_protected_guest_state(s= truct kvm_vcpu *vcpu) */ vmcb_mark_all_dirty(svm->vmcb); =20 - if (VALID_PAGE(svm->sev_es.snp_vmsa_gpa)) { - gfn_t gfn =3D gpa_to_gfn(svm->sev_es.snp_vmsa_gpa); - struct kvm_memory_slot *slot; - struct page *page; - kvm_pfn_t pfn; - - slot =3D gfn_to_memslot(vcpu->kvm, gfn); - if (!slot) - return -EINVAL; - - /* - * The new VMSA will be private memory guest memory, so - * retrieve the PFN from the gmem backend. - */ - if (kvm_gmem_get_pfn(vcpu->kvm, slot, gfn, &pfn, &page, NULL)) - return -EINVAL; - - /* - * From this point forward, the VMSA will always be a - * guest-mapped page rather than the initial one allocated - * by KVM in svm->sev_es.vmsa. In theory, svm->sev_es.vmsa - * could be free'd and cleaned up here, but that involves - * cleanups like wbinvd_on_all_cpus() which would ideally - * be handled during teardown rather than guest boot. - * Deferring that also allows the existing logic for SEV-ES - * VMSAs to be re-used with minimal SNP-specific changes. - */ - svm->sev_es.snp_has_guest_vmsa =3D true; - - /* Use the new VMSA */ - svm->vmcb->control.vmsa_pa =3D pfn_to_hpa(pfn); - - /* Mark the vCPU as runnable */ - kvm_set_mp_state(vcpu, KVM_MP_STATE_RUNNABLE); - - svm->sev_es.snp_vmsa_gpa =3D INVALID_PAGE; - - /* - * gmem pages aren't currently migratable, but if this ever - * changes then care should be taken to ensure - * svm->sev_es.vmsa is pinned through some other means. - */ - kvm_release_page_clean(page); - } - - return 0; -} - -/* - * Invoked as part of svm_vcpu_reset() processing of an init event. - */ -void sev_snp_init_protected_guest_state(struct kvm_vcpu *vcpu) -{ - struct vcpu_svm *svm =3D to_svm(vcpu); - int ret; - - if (!sev_snp_guest(vcpu->kvm)) + if (!VALID_PAGE(svm->sev_es.snp_vmsa_gpa)) return; =20 - mutex_lock(&svm->sev_es.snp_vmsa_mutex); + gfn =3D gpa_to_gfn(svm->sev_es.snp_vmsa_gpa); =20 - if (!svm->sev_es.snp_ap_waiting_for_reset) - goto unlock; - - svm->sev_es.snp_ap_waiting_for_reset =3D false; + slot =3D gfn_to_memslot(vcpu->kvm, gfn); + if (!slot) + return; =20 - ret =3D __sev_snp_update_protected_guest_state(vcpu); - if (ret) - vcpu_unimpl(vcpu, "snp: AP state update on init failed\n"); + /* + * The new VMSA will be private memory guest memory, so retrieve the + * PFN from the gmem backend. + */ + if (kvm_gmem_get_pfn(vcpu->kvm, slot, gfn, &pfn, &page, NULL)) + return; =20 -unlock: - mutex_unlock(&svm->sev_es.snp_vmsa_mutex); + /* + * From this point forward, the VMSA will always be a guest-mapped page + * rather than the initial one allocated by KVM in svm->sev_es.vmsa. In + * theory, svm->sev_es.vmsa could be free'd and cleaned up here, but + * that involves cleanups like wbinvd_on_all_cpus() which would ideally + * be handled during teardown rather than guest boot. Deferring that + * also allows the existing logic for SEV-ES VMSAs to be re-used with + * minimal SNP-specific changes. + */ + svm->sev_es.snp_has_guest_vmsa =3D true; + + /* Use the new VMSA */ + svm->vmcb->control.vmsa_pa =3D pfn_to_hpa(pfn); + + /* Mark the vCPU as runnable */ + kvm_set_mp_state(vcpu, KVM_MP_STATE_RUNNABLE); + + svm->sev_es.snp_vmsa_gpa =3D INVALID_PAGE; + + /* + * gmem pages aren't currently migratable, but if this ever changes + * then care should be taken to ensure svm->sev_es.vmsa is pinned + * through some other means. + */ + kvm_release_page_clean(page); } =20 static int sev_snp_ap_creation(struct vcpu_svm *svm) --=20 2.48.1.711.g2feabab25a-goog From nobody Fri Dec 19 06:21:03 2025 Received: from mail-pj1-f73.google.com (mail-pj1-f73.google.com [209.85.216.73]) (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 4674C22F176 for ; Thu, 27 Feb 2025 01:26:01 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=209.85.216.73 ARC-Seal: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1740619562; cv=none; b=ANOPeD8ib/snpCarZIaCk4Fn2slOp4790+xKwye4lNxvOnIo1QocmKAjtfYMzE97dZL63LMPBmnlBWmB9T32fvcrN88HM1DXDw9PIg2NRoQLv1PNMs8BZ0WmJOiEJ7U28Eh7NrzX+AJ5JkbPbumOe4TI1R/Yc+W7o6/Mm9ElZK4= ARC-Message-Signature: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1740619562; c=relaxed/simple; bh=k1zCPxyx7QffMCA40qqfLOdgRpM8zvCQvs8fM/N6VGQ=; h=Date:In-Reply-To:Mime-Version:References:Message-ID:Subject:From: To:Cc:Content-Type; b=IErKIGOzQT2UGMqdtkImZhGXQYn+QmML/5bElyt5J2NAA9xIpXIqFEGTOiGSqeD7oc6FSJ0u7NVHASi/ZkWIkT/3Zv7lyMkQR2L+ZTQYGq0wFpkKo7nU/TNhnpjOVsXEcTDL4o7q/7u0v3+4EcYwhZVaJ6GNPsyRTiUBnFihHY8= 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=JNWPJcos; arc=none smtp.client-ip=209.85.216.73 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="JNWPJcos" Received: by mail-pj1-f73.google.com with SMTP id 98e67ed59e1d1-2fe86c01f5cso943397a91.1 for ; Wed, 26 Feb 2025 17:26:01 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20230601; t=1740619560; x=1741224360; darn=vger.kernel.org; h=cc:to:from:subject:message-id:references:mime-version:in-reply-to :date:reply-to:from:to:cc:subject:date:message-id:reply-to; bh=hRttPNtyo2FhaDhgSxaXYjlTdMIPvE2NOxByRas6vdI=; b=JNWPJcosQmjHrS3bwJUXhl9nRHazhDBSpnB/J8iNdn7Tb80tGrhBQ4X/d99AEQ11PU +I2XVTZNBeBhvAz9Cbg3HADPlNNcsdkMbnlNJ0/WgpROQxS/AA7tlzGfeNNxocv/xWXG O3mZKCKES8qsqPrS6WniO8PzJ1tAabqE9/2ps4aM5Nm/6TBOrV8mNG1kD9emkk/lN0bz zRtEoV+Aj+5ulOZlMs7lZG5TtHNTeX3qd8/YbiFmiL0nGV7CNEbMo4aalDJQseAVGQ38 9ut+f8kQUrVLO4WdRwPpwC0vjtS8+uwL/CHQKOlcMl8j467WBNKwOVJ4qTesBGFHmR34 TELA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1740619560; x=1741224360; h=cc:to:from:subject:message-id:references:mime-version:in-reply-to :date:reply-to:x-gm-message-state:from:to:cc:subject:date:message-id :reply-to; bh=hRttPNtyo2FhaDhgSxaXYjlTdMIPvE2NOxByRas6vdI=; b=gcKvIzI5YmZSraFcSUbs/WAOlm/5rroHswQvydjgvIa87RkG7/JWsFrgG90PXnXQAf +w0d1Z9WtFjjblyQeEmq/LTdH0nRNB0CdNIzridme+F6dAPsed+xMWBBhazHMKLLsFub R71xYZgDNX3D4gr4p3vwxYGKBBJT7EA88CqNolZ5aMdA/zx6GEPiVs884hPKcGTH4X28 UkUrLrP6VRPa5+OOr4SHM8BOJBghu3G3sr8Ta1icM8UXgTwy64htKimm7Uy1LSFLBJg0 v8dGsoCZifhZT6wkmGIxqp/seymMOMfNXzQh/d76dXkY8tN4yftB9i6h4BgPBeFfTZTx Y/zA== X-Forwarded-Encrypted: i=1; AJvYcCWrd/jVx0RZIVa45RJkxsEyEjAH4KExS1l/C8/PAyhn81hkY1fERQ94J0jfWLb43CGUsO1n6qpNYWb1M7I=@vger.kernel.org X-Gm-Message-State: AOJu0YwZzjgYYjrx60vkh189O2wVnc7gu1USEdkM2s2hIKW7kqjbTS1V qbKYfx0MlITgeFsPcD1YhIKPDyBAM2lqbYJyXfqDibTStuUabDnJhoItDef56yYTErVwylRUmWh A7A== X-Google-Smtp-Source: AGHT+IG8HbiE4dqqw9uPDJvINPCaXcP21RIIbdqv90GTh7egSO6SkFb9wzrb+echyxtbBa5rvPfSgawyvUM= X-Received: from pfbfa11.prod.google.com ([2002:a05:6a00:2d0b:b0:730:7e2d:df66]) (user=seanjc job=prod-delivery.src-stubby-dispatcher) by 2002:a05:6a20:4310:b0:1ee:d92d:f6f3 with SMTP id adf61e73a8af0-1f0fc998e0fmr15792313637.37.1740619560644; Wed, 26 Feb 2025 17:26:00 -0800 (PST) Reply-To: Sean Christopherson Date: Wed, 26 Feb 2025 17:25:41 -0800 In-Reply-To: <20250227012541.3234589-1-seanjc@google.com> Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: Mime-Version: 1.0 References: <20250227012541.3234589-1-seanjc@google.com> X-Mailer: git-send-email 2.48.1.711.g2feabab25a-goog Message-ID: <20250227012541.3234589-11-seanjc@google.com> Subject: [PATCH v2 10/10] KVM: SVM: Invalidate "next" SNP VMSA GPA even on failure From: Sean Christopherson To: Sean Christopherson , Paolo Bonzini Cc: kvm@vger.kernel.org, linux-kernel@vger.kernel.org, Naveen N Rao , Kim Phillips , Tom Lendacky , Alexey Kardashevskiy , Pankaj Gupta Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="utf-8" When processing an SNP AP Creation event, invalidate the "next" VMSA GPA even if acquiring the page/pfn for the new VMSA fails. In practice, the next GPA will never be used regardless of whether or not its invalidated, as the entire flow is guarded by snp_ap_waiting_for_reset, and said guard and snp_vmsa_gpa are always written as a pair. But that's really hard to see in the code. Reviewed-by: Tom Lendacky Signed-off-by: Sean Christopherson --- arch/x86/kvm/svm/sev.c | 3 +-- 1 file changed, 1 insertion(+), 2 deletions(-) diff --git a/arch/x86/kvm/svm/sev.c b/arch/x86/kvm/svm/sev.c index 3f85bd1cac37..de153a19fa6c 100644 --- a/arch/x86/kvm/svm/sev.c +++ b/arch/x86/kvm/svm/sev.c @@ -3875,6 +3875,7 @@ void sev_snp_init_protected_guest_state(struct kvm_vc= pu *vcpu) return; =20 gfn =3D gpa_to_gfn(svm->sev_es.snp_vmsa_gpa); + svm->sev_es.snp_vmsa_gpa =3D INVALID_PAGE; =20 slot =3D gfn_to_memslot(vcpu->kvm, gfn); if (!slot) @@ -3904,8 +3905,6 @@ void sev_snp_init_protected_guest_state(struct kvm_vc= pu *vcpu) /* Mark the vCPU as runnable */ kvm_set_mp_state(vcpu, KVM_MP_STATE_RUNNABLE); =20 - svm->sev_es.snp_vmsa_gpa =3D INVALID_PAGE; - /* * gmem pages aren't currently migratable, but if this ever changes * then care should be taken to ensure svm->sev_es.vmsa is pinned --=20 2.48.1.711.g2feabab25a-goog