From nobody Fri Dec 19 06:18:35 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 9A44C8248C for ; Wed, 19 Feb 2025 01:27:10 +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=1739928432; cv=none; b=mZ100m05ZX8L2WwGGlJjEEM48j2efD2VqbPLM/GKneUCfppSzuQcnj5nYBAWHbCBwTnAwQE+0pbwU9w+gcRaEW+eiE0nQCaCY+fmXp+YepIVWUbIT3136cFDKnHn5ca9sb8u6FKIaWeIdoiQw1sPSUqVt2Y9Y+1jC3XzPNk65cM= ARC-Message-Signature: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1739928432; c=relaxed/simple; bh=EOmp5p/eXKNkVg6WXQ/ZlC/uLiLJjAeM5pCz0GJMfmA=; h=Date:In-Reply-To:Mime-Version:References:Message-ID:Subject:From: To:Cc:Content-Type; b=LTvGFWa9P6NBLIRXmfShMw5WMurPyHlv5pQMn2k8Pa5ASaoM1AFhIqC2s4oq+c5pyslygMVZw6/MxHqpf3K10WutPdJkg0I/KRcysiL3AvRDTDVlYuzijFk8ZA5cc7JS5Ucson2M7p7NEDud2c0olRkX/4meKYO3bR4t9TD9JMc= 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=LAMabYtP; 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="LAMabYtP" Received: by mail-pj1-f74.google.com with SMTP id 98e67ed59e1d1-2f2a9f056a8so13055409a91.2 for ; Tue, 18 Feb 2025 17:27:10 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20230601; t=1739928430; x=1740533230; 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=VRgNhxb7FgTdN0Mx3pfakPm2/CieOGAIFcirrQsik3U=; b=LAMabYtPCc7buvrQyht+021WfVhihvJKw/xxWP71WlddBZfzQ/BtfYUaF9EEp3UeIq VblNMNeVWhOhJJhF9+05Y1PJuPhp2e0/5Ch3kuFK696IN6TqTntRFZWVLKC0ieMnB9hJ t1rKiZyzzXN4O+f+s1kNyhnexDNFCyUOyu3j82wdsNSmt6X2IaLX9oEYDK6m5KeKhg0U vmRlufkcBCYODreHuoJyZ4h6GgxZ4qHgOQsLNBsrZXsf61ZBK/Xn8nVp+h+dIULMUL8l NiAy3C/ywYnfzSXvo5g7+BPZqTFlfhDfuAuyF+z52gyarwgtQFnqJwgQnLZO4tHvFpcn LGvQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1739928430; x=1740533230; 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=VRgNhxb7FgTdN0Mx3pfakPm2/CieOGAIFcirrQsik3U=; b=gtGjoMtwgA3cUOGSIn8ppWAp4gI33mfgAkdIEhuQbXaDKC3XAiFr+GjuGbxFjWA8hW CvKeORi4O32ZLdyDPK0ceNaDaW1Abpj3mJsF0UtGtio8b/yFOQH+Qk1iLKXOFQLHyqpz x3d5BsVUhapJwdFuJ4ffH5pJhFDmbjrxmBAHcmTwUN++nSKf0w+uDBWKMeW7KdVQzxYj dq/NqfDaP99P/F4DsX+ht4QvCNuhYA8PRDmlOfVWQCZlUTjlwg3no+LGTJiNZOqnsw26 d6YQ73Ch9BGCM8XS5sw6vq01/8rGKzoViXrF3V6olf0lEKBe+lv7JSL23ANzgywgXsWB W0OA== X-Forwarded-Encrypted: i=1; AJvYcCV22lJzU7TMHjHus+u4w0JOsG1jNPdCfQ6OY7NKbPENAYCmCwd80I51Owr1nGkRzT0whEwOnrUwxVXWIcQ=@vger.kernel.org X-Gm-Message-State: AOJu0YzJwzsRUH3lAOfaKVV69yOxtTB2efke30v9GNkVfdKt9WbsRxVE 8h8dLrB0/qTvTCGoSRSDCfQ487lD/SLxMvjycJkAZX1bXI5+N4C9PHxfqCmbz37vInKnmg5botB 5tg== X-Google-Smtp-Source: AGHT+IFSUmW3Pv37hBOcPGebWzOzBiwxgMgqtgIXN+HtyasCo2QrSGcjbna1nnb4kpL4ZFFfQj95yAFiK64= X-Received: from pjbsn5.prod.google.com ([2002:a17:90b:2e85:b0:2ee:53fe:d0fc]) (user=seanjc job=prod-delivery.src-stubby-dispatcher) by 2002:a17:90b:4b8c:b0:2ee:e18b:c1fa with SMTP id 98e67ed59e1d1-2fcb5a9a0c4mr2447828a91.28.1739928429817; Tue, 18 Feb 2025 17:27:09 -0800 (PST) Reply-To: Sean Christopherson Date: Tue, 18 Feb 2025 17:26:56 -0800 In-Reply-To: <20250219012705.1495231-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: <20250219012705.1495231-1-seanjc@google.com> X-Mailer: git-send-email 2.48.1.601.g30ceb7b040-goog Message-ID: <20250219012705.1495231-2-seanjc@google.com> Subject: [PATCH 01/10] KVM: SVM: Save host DR masks but NOT DRs 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 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. 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). 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 Signed-off-by: Sean Christopherson Reviewed-by: Tom Lendacky --- arch/x86/kvm/svm/sev.c | 11 +++++++++-- 1 file changed, 9 insertions(+), 2 deletions(-) diff --git a/arch/x86/kvm/svm/sev.c b/arch/x86/kvm/svm/sev.c index 74525651770a..e3606d072735 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: @@ -4592,9 +4594,14 @@ 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 both - * saves and loads debug registers (Type-A). + * saves and loads debug registers (Type-A). 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", + * and so KVM must save DRs if DebugSwap is supported to prevent DRs + * 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.601.g30ceb7b040-goog From nobody Fri Dec 19 06:18:35 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 54CC314B092 for ; Wed, 19 Feb 2025 01:27:12 +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=1739928433; cv=none; b=B8/CYK+cAYBagid49SsMhsO2j3oMjR09rfcKe4J5fQQ/vtKIIWmsfJ+717tsI5GCL791fmeBSUz9xvMoRvVucctBKvZAp0EAQ96hIJ7z6VXaN7rLor2fRzMXvv4aQ6eGI8mFtAcM4Jyr/xNrp8iHyjjZjv3l59L6dqPMqcbiRaY= ARC-Message-Signature: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1739928433; c=relaxed/simple; bh=J1nAFJt6r7Ajioiex0cydNgYgyWbIcK2APGZ3IXZAOQ=; h=Date:In-Reply-To:Mime-Version:References:Message-ID:Subject:From: To:Cc:Content-Type; b=A4HO+oahyauK79wiJ2DTmp4MIlL9Gs/tRrtZah4NAMGhly8mivF3BZDazo3Y+qcFTpSErl9W6Kr3OeDvmd1lvuluaBHsDGI55dBhsUoU8KcnlvhgSk7+j7Iv67e4NDeIwcjDmfctaAoAkmlRxQkq9p7XoTXhf3Zr3sycP4Gw+c8= 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=1AuCBU+Z; 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="1AuCBU+Z" Received: by mail-pj1-f74.google.com with SMTP id 98e67ed59e1d1-2fc17c3eeb5so11253994a91.1 for ; Tue, 18 Feb 2025 17:27:12 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20230601; t=1739928431; x=1740533231; 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=cvedP6xsz4gidjwnbxw7j1GxK5ZG/kcCzWXYJHFDTTk=; b=1AuCBU+ZoCGIElranhfzG7pPwN9N7KJOhmGn4yd5wzlAgz979cXFillJHbOdfnWt88 8yhTDT8fmQh5I66Fb2ir9bY2UidYE1n6fpPxI+o38Mg0DP5rvhFlyb98nXdUb8jILzHf keKDVS5yy4AB3gzXcI3+t8wzdJfBGBuS+hTpIizvl6FhSMarBMTDk2dpm+onnePrN4nS 1Gw9IxBAs1NzYw9zDq7wDjMyEotA3MPtasOt40tJ31/Kx7Ap409KNpOnkcNrU+W3ajFc 3+X96bO6QgN4OBdj4GSF+F3akpL/rhv5zYOSM9n6PXUO/wzz0tGvTgaULEj7IQCtkogB tTAw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1739928431; x=1740533231; 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=cvedP6xsz4gidjwnbxw7j1GxK5ZG/kcCzWXYJHFDTTk=; b=P2VJYsaYOqWNpVUkMVqK76NpAFdY2JEt/Ka49jrUvhr964shWIy+Yb204pCKc7k9b+ OupndLUh9BdCzJVaA4KDnv14CjbwHjfEFpJVtrwMomfKEaTBQ/kERPnITneTv5zPocRu 3QUWQiq6iKoxOELhfIWxzBpH8WI07mNfpiyAdzYe0BUf5UZSi6OLTSSNnWGzcvaz+Jof jmDNBNb9JeLF3j2XNXvv5AiLtOS4p2IJau8Grayi0BY+dFvMunBgjtuWA6ALWaHYLKbB b3ulyfk8+IAlLJegtHF8fT2JmlfHqNhpb6x1nNlsLQLdi4JB01fjJZQYQIzCfAY8Jmjt 80LA== X-Forwarded-Encrypted: i=1; AJvYcCV5IszV/YDBmQ5nbK/Gyr0F554Yv5xpLtMcEsEVwMUDpaXdA6WAVrzDyo+o+6Y61ttrb5HKQj3PNaSqudI=@vger.kernel.org X-Gm-Message-State: AOJu0YyNXAiWj4oRWdBA02xfzJHTRpsX7KXTtEar8dDif6e1VVvNfHIN 9d62NfDK3tbhmEkvATMkYHiBZExBdqVUfsZ46ADOEda58S3OvXsNRaEbmOsG3Ht7l7Tc+DpOOmG 9OA== X-Google-Smtp-Source: AGHT+IF2j6eaylYhREGn8frIKvQEbG2ipSn6kEWP+C6rQfqXJMdySmc8Mo7nKr7CRXlAX8q7sHTfLLzlpqA= X-Received: from pfun4.prod.google.com ([2002:a05:6a00:7c4:b0:732:6425:de9a]) (user=seanjc job=prod-delivery.src-stubby-dispatcher) by 2002:a05:6a00:1746:b0:732:535d:bb55 with SMTP id d2e1a72fcca58-732617757demr25124172b3a.4.1739928431594; Tue, 18 Feb 2025 17:27:11 -0800 (PST) Reply-To: Sean Christopherson Date: Tue, 18 Feb 2025 17:26:57 -0800 In-Reply-To: <20250219012705.1495231-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: <20250219012705.1495231-1-seanjc@google.com> X-Mailer: git-send-email 2.48.1.601.g30ceb7b040-goog Message-ID: <20250219012705.1495231-3-seanjc@google.com> Subject: [PATCH 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 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. Signed-off-by: Sean Christopherson Reviewed-by: Tom Lendacky --- 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 e3606d072735..6c6d45e13858 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 both - * saves and loads debug registers (Type-A). 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", - * and so KVM must save DRs if DebugSwap is supported to prevent DRs - * from being clobbered by a misbehaving guest. + * saves and loads debug registers (Type-A). 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.601.g30ceb7b040-goog From nobody Fri Dec 19 06:18:35 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 F36AF16BE3A for ; Wed, 19 Feb 2025 01:27:13 +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=1739928435; cv=none; b=tX36rLHRZEy5dEh/I3vhF47WgEQhyoEmnwEt4X7qAjgQAaatermsB+F8B4MSKURZkfmXzBFwR1dQxzio/XnvqDjRTUkL/gjwzri9YYbVwVeIBcVUfXM/y35k36C7yHo4vcohcwJ856ZxQ8w+KEz0GSz08h0XntfwCioxy6Fx4Ko= ARC-Message-Signature: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1739928435; c=relaxed/simple; bh=4OEAxR3s/43AnR+PMZMEbjBraLCzIO0pgoEeiAIRlxA=; h=Date:In-Reply-To:Mime-Version:References:Message-ID:Subject:From: To:Cc:Content-Type; b=NU7Dz9OO+KAnudFI6MqBR9NKPASUCVphth2AdxlNL86pfuoFH2txHz4zXmkJiNIoxaTZ/TDAMuKugR20GHRokVb+zLffF4jqBVp5LOK3stjFgQGz8rEXa0EVRruVtbWpnPd3Rt/nku7ZYk030Xs66rP/eIZnwQGNHayMdoxnVSQ= 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=2PHPU+A7; 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="2PHPU+A7" Received: by mail-pj1-f73.google.com with SMTP id 98e67ed59e1d1-2fc1a70935fso11496482a91.1 for ; Tue, 18 Feb 2025 17:27:13 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20230601; t=1739928433; x=1740533233; 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=iJszCJZKg8PtQ/Ae3yHsiUpwJbfr+WbepFVlWSrNVFQ=; b=2PHPU+A7OTyW6f2S/FBFXH+LNbW35p0du2527SFP1kalIrPg3kMYRsQ/ftfha4eaaS 0OsvR825o/YlJtxHqsY6+yynwMZuh+dD+zZXQlPdYNWedszlirFC0KlP0SmAqgxqDNYj YXy6JZAf6La0SDY5jXs6ybgXp2h31mVl/icoLKmX6cc/hgS0dIZYL2+MFJg+FoopNFVs N5ZX0VIcH8kC/fncerZMosudrWki0d8MEDoRUjJJzyOJWtlM2JcIMt/nhSDJjxCC4d18 +8jj1R8ABPWMFokJ7AoE32zWhG5bcJm0nmZ8O6hS8+T0ASDLQDVdv/06JttpTwJ9qXhg sY0w== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1739928433; x=1740533233; 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=iJszCJZKg8PtQ/Ae3yHsiUpwJbfr+WbepFVlWSrNVFQ=; b=xVXvIfPF6TfgJNzT9oNFdRiwqB0ooJK6dXSWBIasp+d8mNxOQ0aAI0g2h0tvQsGBKO zii3AL0TCwxHAAbfQpDYd23dsP4d0ohAOkdQaRwA/UIT+6cuIN10uMRfqQLE4b0HwgKn aJlnYdY5xkXrI8Pu7BM0eCqDHfuf/HbXu6cCD64ND3OZI/mwXuSNxAmJDq0B7GgH4907 +lz+oujFqqvYLpS4kzrjeRQCsZ1cY5+rsT+q834bmWcMVNnnpIDwPS+0E+UfMsPBXlYy w4xEPOT4Sa3Mu7KKwFGjnKmY42DJGjJpWMeoPRJbyNqfLqkmukmkycwWKUNiRgJtqqDM ddzw== X-Forwarded-Encrypted: i=1; AJvYcCXVK1SUMAJ33UMlOenKwtqRJ45a9jaBvOGmhN8Ylgfl8wk9BW+pGQlvvBQihXIyEASmFAtDvlWyFXA5oqs=@vger.kernel.org X-Gm-Message-State: AOJu0YyV9oX2v1MXtmRlJsYKumeGSiRn0+zcvI7pHTdrAArlWNxPf5GE w96yNC0/j/1wpjjQY1BKxXMxVCbnis8DxzO9KExtXm9SiXXtXPd3agt71SS41JAy3wSt0GH84Tv Obw== X-Google-Smtp-Source: AGHT+IHqxHNQUm/C6lVCMrwMQ8rlL2tdxOfbL2NQq3+nc7UKt3qAAgkQUvPBwgR+3sGE47UNfucABBsGQKA= X-Received: from pjj5.prod.google.com ([2002:a17:90b:5545:b0:2f7:ff61:48e7]) (user=seanjc job=prod-delivery.src-stubby-dispatcher) by 2002:a17:90b:3f06:b0:2ee:c91a:ad05 with SMTP id 98e67ed59e1d1-2fc40d14c84mr23967842a91.3.1739928433321; Tue, 18 Feb 2025 17:27:13 -0800 (PST) Reply-To: Sean Christopherson Date: Tue, 18 Feb 2025 17:26:58 -0800 In-Reply-To: <20250219012705.1495231-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: <20250219012705.1495231-1-seanjc@google.com> X-Mailer: git-send-email 2.48.1.601.g30ceb7b040-goog Message-ID: <20250219012705.1495231-4-seanjc@google.com> Subject: [PATCH 03/10] KVM: SVM: Terminate the VM if a SEV-ES+ guest is run with 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 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="utf-8" Terminate the VM if userspace attempts to run an SEV-SNP (or -ES) vCPU that has an invalid VMSA. With SNP's AP Create/Destroy hypercalls, it's possible for an SNP vCPU to end up with an invalid VMSA, e.g. through a deliberate Destroy or a failed Create event. 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. Fixes: e366f92ea99e ("KVM: SEV: Support SEV-SNP AP Creation NAE event") Cc: stable@vger.kernel.org Signed-off-by: Sean Christopherson --- arch/x86/kvm/svm/sev.c | 18 +++++++++++++++--- arch/x86/kvm/svm/svm.c | 7 +++++-- arch/x86/kvm/svm/svm.h | 2 +- 3 files changed, 21 insertions(+), 6 deletions(-) diff --git a/arch/x86/kvm/svm/sev.c b/arch/x86/kvm/svm/sev.c index 6c6d45e13858..e14a37dbc6ea 100644 --- a/arch/x86/kvm/svm/sev.c +++ b/arch/x86/kvm/svm/sev.c @@ -3452,10 +3452,21 @@ 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); + + /* + * Terminate the VM 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)) { + kvm_vm_dead(kvm); + return -EIO; + } =20 /* Assign the asid allocated with this SEV guest */ svm->asid =3D asid; @@ -3468,11 +3479,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..46e0b65a9fec 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,8 @@ 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)) + 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.601.g30ceb7b040-goog From nobody Fri Dec 19 06:18:35 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 8A747188938 for ; Wed, 19 Feb 2025 01:27:15 +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=1739928437; cv=none; b=O/8XhoOszcGkjQ70FaltmQD7+NQya9/Lc77ALRr4UwIcWehMKUiXv+jIMcnWeImdObFIWi+XgrEdt0NlvTxhH4JM5rNuropTw5VUXs4l9kcjypUujvaRQOUA7o/MoIBWWBaZp73vKI/5opOXr89uPow+ZcFAkDF8+3ImtaPGPsg= ARC-Message-Signature: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1739928437; c=relaxed/simple; bh=1uJkGwGwnraXe8zGYXAmtpbiv7YmImMEb/2dv74uGGA=; h=Date:In-Reply-To:Mime-Version:References:Message-ID:Subject:From: To:Cc:Content-Type; b=UoHeT+Km50rz2R82w8RpqyXcKAVc4oe2x0PMyo1YAN54x3N546idcPJnlbnLtihOAKWJSNWAdVwN/ajJinf/0z84BxPl8fz0gW6ywiApNzhnt0dnNz+q3RHLNFytDRYxSl6t+qL8sPWPHHjeDZ4ls+2d9HDCcUYC5LgUgw3ePrU= 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=VxM/Ofvv; 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="VxM/Ofvv" Received: by mail-pl1-f202.google.com with SMTP id d9443c01a7336-22101351b1dso77798815ad.3 for ; Tue, 18 Feb 2025 17:27:15 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20230601; t=1739928435; x=1740533235; 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=hUPfnDvapq0pxQUdNT93GvWgI0A9Rkgcd+wtudK6DPM=; b=VxM/Ofvvj1KSCj72kKG+3cJQ+TKjLfGW5NPIxPcD7N2G6MDKByTdWh+6kTIUQVRGWK uHrs6SktuMk96U57qioyvczKk7iiN6NFwEWWAiatpWa9OWeByUozQspG+/neGmkaclYq KRcI3ekToYpG0qjb5egoYJdnz1yLOMUgWMSlJQHELTPi4xwcalJZr8TWPcn627pGKm1D nnhUOWq0hiB4LVhoLkidRbjXk47JQh/fYlKhM1Lar2xQRys7i96BqrA6by1MIPTvBkmK MRNZEGrf1bs2Uan/pC+XI41O9HElaaqeMssP+PYUwPT1Y8cy4tbs0SzyDVDe/w/ThErR WdBw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1739928435; x=1740533235; 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=hUPfnDvapq0pxQUdNT93GvWgI0A9Rkgcd+wtudK6DPM=; b=cVxHC0+QeJjuVJ/5N8K7KlUhDycYsjJo5ltL6CMNF0MJHQXaGZjBGymcR5v/nVMAPG QNnUel0mmYYU57FILSj9VCtqYChnQWVfkzxC4UWmrc4hXRvptQA3lTWmnjLLxo5SHa+6 YRn1M2LmEGU+vHhgujPOgBZTKwBZxJaB2ScArACTCFHpIE7epz8SbEuNDE6w+QxAAYXM 40TT9vJ8NszwmLwzoX0jd5tK56WWD03zadVZQi2kLfltdrl7PGU0zVd00cKYAOfGOrmN MHHYEST7i/IaEuCQHHlzYh5YJ+dJkIHLZPL1H+mqgTJwwCZg+9EcdLi1YZcNHP59RMwU /tnA== X-Forwarded-Encrypted: i=1; AJvYcCV2tk3jUkzQwBCpIt6a+VyacUSx/Uwq/0Z8SlTlksnnuQsQldQ6m2vSpTMdvGkhTqcW6/H2ee+vfUh2BE0=@vger.kernel.org X-Gm-Message-State: AOJu0Yy4eIBZ4SHiqtfNpIEXnm2e7vTaxde1Wqj19D4ifbPo/sud2x53 MbjP/bsO415Wh7JIVznqgx4wKKPmmZtlZIPKNT/qa4TOf16MdfAWmswQj1XKJVqI5LvBzwfOBLU Tiw== X-Google-Smtp-Source: AGHT+IGUaZqmHLGvTqjTlq0pWgcuq9Yyr5LZzrmTiqligkFeuX7GjqON9gMPdFUYb6mGs2gDj48dSzgoiaQ= X-Received: from pgah14.prod.google.com ([2002:a05:6a02:4e8e:b0:ae2:57bc:f8c8]) (user=seanjc job=prod-delivery.src-stubby-dispatcher) by 2002:a05:6a20:c70b:b0:1ee:c6bf:7c49 with SMTP id adf61e73a8af0-1eed4e3f207mr2507708637.6.1739928434840; Tue, 18 Feb 2025 17:27:14 -0800 (PST) Reply-To: Sean Christopherson Date: Tue, 18 Feb 2025 17:26:59 -0800 In-Reply-To: <20250219012705.1495231-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: <20250219012705.1495231-1-seanjc@google.com> X-Mailer: git-send-email 2.48.1.601.g30ceb7b040-goog Message-ID: <20250219012705.1495231-5-seanjc@google.com> Subject: [PATCH 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 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 Signed-off-by: Sean Christopherson Reviewed-by: Tom Lendacky --- 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 e14a37dbc6ea..07125b2cf0a6 100644 --- a/arch/x86/kvm/svm/sev.c +++ b/arch/x86/kvm/svm/sev.c @@ -3959,16 +3959,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; @@ -4014,20 +4010,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.601.g30ceb7b040-goog From nobody Fri Dec 19 06:18:35 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 23AB716A959 for ; Wed, 19 Feb 2025 01:27:16 +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=1739928438; cv=none; b=ESk1CNu1/VArutJ30BFurRubHvh0qzs/XBDGa8Lt78WaGHa29CD+3g1psonhuahNbWhqmJrXG3rmV4wwljvPAWdLFG0dwJwbGuUZcw9XlRRFECHzuNbknC31CF2hIi7RtzUyGPH/0e3H7it2cuBa5wFesxRGtB1DPSNVZxwaI6Y= ARC-Message-Signature: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1739928438; c=relaxed/simple; bh=HS/OGyPieAUMN+o3iI2SoK4HV3gkuOhVEedxfxsJjPQ=; h=Date:In-Reply-To:Mime-Version:References:Message-ID:Subject:From: To:Cc:Content-Type; b=Lt1Pd0uPFeABS7NjhArS4ZxgaPGOwlQIHMC8fhvt17LUJhO6jwqL/gGXUyHQUz5/DrE4/7m0FUKenRJjDSsS1RLFevTOL0v+VtG/Zl3bZ3ENbivG1JNL1XmMiuUU/vvEAIgOFaI2F/r6YvoFzBhgr0n8AXYpSrirhk8wKovmGOU= 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=u9jl//jl; 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="u9jl//jl" Received: by mail-pj1-f74.google.com with SMTP id 98e67ed59e1d1-2fc45101191so6714213a91.1 for ; Tue, 18 Feb 2025 17:27:16 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20230601; t=1739928436; x=1740533236; 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=NOqNLm8zpj7r5p6cWzA7ewxdPggAPFsC3tCvVJWmq4Y=; b=u9jl//jlRAahR95FDOsHeizXwb1pgeMDafOZHlQQesOI1vN2zy6zUpZJT3fg48xV6f 6X9kAVv/1h51opTnnjfrP1HfAxMcv/qWRhkMZKym3qbOXdwKQdLFNELQiD9q9K7buEkc C1i0tf/pduKH0Zm61BbHU5vKHd3BkR9s3+NSkM9kdIxmZiJbFwFreV/B2lnYjpq8Jzts OTn8aUZ+FkHqo03b6PRfK7o2z4qcWaAvTj7uj/qYWc0r84TJ6GgDHD0YSa45Gei6ESUj 4v1Kg8QirG7L0bgyuidv3U6q0gi5jUa8Nb+O1yQamcMhQ2odZ6A4+fFeQR3oEIPaKPX3 i5YA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1739928436; x=1740533236; 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=NOqNLm8zpj7r5p6cWzA7ewxdPggAPFsC3tCvVJWmq4Y=; b=Vt6YyrC/kNcnSnWBe2JzuUyMzu0alJHQaN3RS8pDuqkkAuroLf4Y09OvGv8b9/thu0 TzU6wUSqSHmpCMt7WHUTgudZk84UcZ7UeaDrKO0+9H0iqXTzirD5gILsfTHTBGJqBpo/ H4m1Bx/5NK6HbR/ysnx3GK9MUjDOIFmgasBYMSkLo8psvE41FIVvTShqITVq0DN0Ca8o 0NupLk0Cewi3F1wdzhbyzBu86ahKRv8tYgRvLKHWCZVp5HnYr1Qzpo/XZIWJICKuPg4B 1AI3gTbJNkDO1BxRfRGscw7pVidXgipMruBO5hcsHGsl8stjRmwCBsfjbOrUnuEhtkrR q1aA== X-Forwarded-Encrypted: i=1; AJvYcCUEETKz+m38sKEugJcagRKJhdXkEgZkXnDWBcNmPxoO3ao2JW3vkysOxngSJNG4/pbQTXSRC2901bilpmw=@vger.kernel.org X-Gm-Message-State: AOJu0YxN4vJpACkSvdh7trpqBFJu0uFk9xTdMvf9Wt8ZZfhJ/V9EXoir i0e0rXWHGpbVWjft9GFU8NTOm6LbXSHwoK9uErBuVKf8zS09In/MjOJKOevn+NpifGSI3WBi+wd 9Lw== X-Google-Smtp-Source: AGHT+IGbOdETGV4/8dazx0YgIjrgRH1peDdIwCZwKiJ8gyxb6gn3o4TseTvRc52oNdBvm8Q95Zspls7KQ0E= X-Received: from pjbli12.prod.google.com ([2002:a17:90b:48cc:b0:2fc:c98:ea47]) (user=seanjc job=prod-delivery.src-stubby-dispatcher) by 2002:a17:90b:3f06:b0:2fc:3264:3667 with SMTP id 98e67ed59e1d1-2fc40d131bemr23974637a91.1.1739928436566; Tue, 18 Feb 2025 17:27:16 -0800 (PST) Reply-To: Sean Christopherson Date: Tue, 18 Feb 2025 17:27:00 -0800 In-Reply-To: <20250219012705.1495231-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: <20250219012705.1495231-1-seanjc@google.com> X-Mailer: git-send-email 2.48.1.601.g30ceb7b040-goog Message-ID: <20250219012705.1495231-6-seanjc@google.com> Subject: [PATCH 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 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. Oppurtunistically 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") Signed-off-by: Sean Christopherson Reviewed-by: Tom Lendacky --- 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 07125b2cf0a6..8425198c5204 100644 --- a/arch/x86/kvm/svm/sev.c +++ b/arch/x86/kvm/svm/sev.c @@ -3934,6 +3934,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; @@ -3965,26 +3966,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.601.g30ceb7b040-goog From nobody Fri Dec 19 06:18:35 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 1F65B19F49E for ; Wed, 19 Feb 2025 01:27:18 +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=1739928440; cv=none; b=QWPlLrM4Z/n8TRokQJ2KLWpf23awW0Q4LfQ2lOT+F2YGgZw4kXdooqQOiMoGbhapXQ3V2JYFumhqTqoYA0ELKHL/fO3s14p5+LSsA+Y5/DXFVffi5BopwRmbiaRYI7PrM1+9luQRnpLEnx/B+5lokdbStrkRTlNmorqqCRAzsEA= ARC-Message-Signature: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1739928440; c=relaxed/simple; bh=4qE5F9QWe3d5A9/GJCtcN7m+vBvm8zcYETmt15oXBYY=; h=Date:In-Reply-To:Mime-Version:References:Message-ID:Subject:From: To:Cc:Content-Type; b=GX29NFLECJSb2kSP3h8xgqN+zemiHpPaiVu0MfAVBA1+zS+ec4ohqy7FsazCnv5fltwIy6aYocp7XW+ELNF8qJLMlAYC6fQa4NnOqHGjYNeHteoGaoM/dTgQbyS1D8cBFqwSWCWm5dTHCcrhCr9HnEXexNVojFyLC3VnQB3zf6U= 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=WBc9F342; 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="WBc9F342" Received: by mail-pl1-f201.google.com with SMTP id d9443c01a7336-21f6cb3097bso168601825ad.3 for ; Tue, 18 Feb 2025 17:27:18 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20230601; t=1739928438; x=1740533238; 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=aOyRwh3cs/Bv/kD6e4Ko51Wq3Y7FnlmGeIcwci8wsgs=; b=WBc9F342lfYIevxHs0qS3XG/3NIcYsMWlUs+1k5TmQKlMv1sUQTFJiu2ZwM3o8Yskz CerjFuZyokoT25mP9qI+zavc6Q0VcbdA/erqmnVkMQo9NSn8rZi3P2buhFsO6EMgh0Fk jjyEE5r43ECdMINv11AeDbVRP2g0GzhmKtbbq8Ix+/1wcdOJUrGPJQIAwkyYM03eNQye e9gbAV2d9cPjSIAVHYJogZCOfZlIrbVZw97iNlS8WiYiC1dU2KY5Zb15xn0nmySYMjqX ICHl28jH2AxdjW/+jq4cf8AhBBMJn5zu4jV5fSh11dQGwuAC29uSxzeLECt7zcGpFZR/ p82Q== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1739928438; x=1740533238; 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=aOyRwh3cs/Bv/kD6e4Ko51Wq3Y7FnlmGeIcwci8wsgs=; b=xRYY4MCY5Ak3CQs80VdeYZyyYNtZq4AOOYeLTBW88QvKTZY2C3cE3Qb7M5KiGLoQ5d aN/mPG/bBGfDeTdMpkzt+08CwBn8TosIKnT3M4yKSzwWPvXYb7x/+O0cVVaDcNc/w50O FBFg5kXz+ijM5urKyU9Z2VmFGCFMTpRvkI+foVfVPtunJNa5s8a3EHpgGSWLTjZODpwc hygVlc0B+COiCFGshvlCAte0VCKeBEJDQ+l13toaBYstCC9bFFwORPAOtphxyG5TBZ3+ Y5z20Jq5md7gsw1FurB0ZsVH4lTLcSxa1MJFvVQl93rltRadtsNkaon4x89hdZCYtvcO FTPA== X-Forwarded-Encrypted: i=1; AJvYcCUk97j/6e1ktfxbqcC0KdRd9idCdf639DZzPUq/sI9Nl1uXoorSiwu0fFFkh2HjGJNI9Jp2TwKgs+YBLqQ=@vger.kernel.org X-Gm-Message-State: AOJu0YxTHHgrvPphB9O8FebqDpkAGRchlKXVuC9cnKzl28Wnit4BnBcL bSksGGvQKmaPSAVAFlJ4s6E0NPctG6/0ymcb6dYKe+p6lJcfrPTqT5t5mDIdCth7tHHYpF/kMZC aJw== X-Google-Smtp-Source: AGHT+IF+YqB2BsGnTBgkZ7aSO4/b+DJSSz7i3scaotfvDL8sIJxSg/XtkrgUinD2Rx2q79WIomlg2wu4Wbk= X-Received: from pgbfm14.prod.google.com ([2002:a05:6a02:498e:b0:ad5:4477:da5b]) (user=seanjc job=prod-delivery.src-stubby-dispatcher) by 2002:a05:6a21:6d9c:b0:1ee:d6ff:5abd with SMTP id adf61e73a8af0-1eed6ff5f5emr1048651637.14.1739928438279; Tue, 18 Feb 2025 17:27:18 -0800 (PST) Reply-To: Sean Christopherson Date: Tue, 18 Feb 2025 17:27:01 -0800 In-Reply-To: <20250219012705.1495231-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: <20250219012705.1495231-1-seanjc@google.com> X-Mailer: git-send-email 2.48.1.601.g30ceb7b040-goog Message-ID: <20250219012705.1495231-7-seanjc@google.com> Subject: [PATCH 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 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. Signed-off-by: Sean Christopherson Reviewed-by: Pankaj Gupta Reviewed-by: Tom Lendacky --- 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 8425198c5204..7f6c8fedb235 100644 --- a/arch/x86/kvm/svm/sev.c +++ b/arch/x86/kvm/svm/sev.c @@ -3940,7 +3940,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); @@ -3958,18 +3957,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", @@ -4014,7 +4005,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.601.g30ceb7b040-goog From nobody Fri Dec 19 06:18:35 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 CCC851A9B27 for ; Wed, 19 Feb 2025 01:27:20 +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=1739928442; cv=none; b=saeTOO76uqDglqIWnO9QqtT6A9nJx6jK4WJcLgkz3G/XLilKYWjYk29twm8uhbIci12hijWmDDayFS8tRlaIqn0x6IyG7GFWUeNnJrJRa27rwwGkhRC3GLcMSbnoysR9IZRJmncsmmyhjJR/u0Z8r3JyJakYsA25drIbL5fqfbQ= ARC-Message-Signature: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1739928442; c=relaxed/simple; bh=s1acMDP18PsE7/Eq2XXMzX6JJbDeaq52rCargDhMXVg=; h=Date:In-Reply-To:Mime-Version:References:Message-ID:Subject:From: To:Cc:Content-Type; b=dwCy1+gL72ib1fnYElRrlQ3Ve6ojwOpSB/gXR2/seE2OpJ8sDy2/S8BBHRU48h3DoGrp4Dzp8Y8TB0t23lpuiss8mdb8hgOcfx19+/g1r0LYkcdp5cea7SihcJaSTlSCyvT2ptUeqeHZNwefdftjm1a4kZ7ApJkh1bEteoXWGRw= 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=aEyyk16+; 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="aEyyk16+" Received: by mail-pl1-f201.google.com with SMTP id d9443c01a7336-220f0382404so95242675ad.1 for ; Tue, 18 Feb 2025 17:27:20 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20230601; t=1739928440; x=1740533240; 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=la9yfbVfV6p6xAkEmRZs2B8ThoXww+XPdL9PDAJx5b0=; b=aEyyk16+3xbp9mm0QlzWWdSZItvqIHQeyh/hI4HxnDJyFg4E6fTk5Cu+CAbhS93yd9 sQTB+HgP/2XBj9wJNvejT2P2JQ36Cs5yMrlYqw1iIxmf++lPC8oLiXvOMGrEL4DgHSNF J/vagjONBh327iGC8FBgTFCjsMJMd+jSvWYubZ9PfKX6tEXtA9NghXs/T9sAD1bgy2dr 2uPPDFTZI7tEm0EKpRmmUteuOoCDH6EGMAtFiiNoSFiKebCms+XKzve69rK/CftqGBpx mqSHQJBHQEcVHGB1XBdwEnFFFv6bmkCwSRQoaCd7sj0t7tvg2Odz6QPImdPwnPFQuRd0 E6AQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1739928440; x=1740533240; 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=la9yfbVfV6p6xAkEmRZs2B8ThoXww+XPdL9PDAJx5b0=; b=XotLiHgXKZ6bJ+TV0x23qTPyrfVyOj2x+BmsK5BfiP3X38pPn90u49oSGxUD0zQjiy Fk3jDgM/MRG1nIjd/cdVKBSbrdxchhpXsHuyayeUeHp43h/ilppN9PJU2lw1hLh+D47t e6+Kx602LR1if+Pluy2rFjFvQRdX6MLVQuXl/wJwAyuSwIsrRbpD5/+9CMmwqXIjPMZg 9ponYJxQMV7xYQ6SZb9MpuoszKvsJDIEtnH2ArWnF5/AvjySc6fjP1UhtppfJvwgtGM5 15CFN5vmfnkRnekG3QLosa5TaEK9aJXNVEszR4OVF5zIb3p8fNWYf2x8hnCB4BM/qFep I4pw== X-Forwarded-Encrypted: i=1; AJvYcCUJDByPgnsJGYwT7Q1cO5XsgrvJQ3xxTvRjTdDMbOyUb5/2gBaxkuNHsuk5rH41y9QBBaZP7FRwl6oCJcE=@vger.kernel.org X-Gm-Message-State: AOJu0YwhkJUburbhUyh83FyjNrAAfRG2joyQcdsZrvrtMbVBTB+HcceS ewzzgMz8tTSPCmTGFUkh/APWaHkBz7lEz4HuO2ElXCpPwpU9OtfQxc/Dg9AuHPASxrpk+u9d4yF +1w== X-Google-Smtp-Source: AGHT+IHkXB6WyKPBJKTh2FvvXDOK0Y0JhEwaJSEgphJr1aevmbiNAoPEzD1CfLmn3KRzQKfiDHHBVaTNaV0= X-Received: from pgar9.prod.google.com ([2002:a05:6a02:2e89:b0:ae1:b40f:fc2]) (user=seanjc job=prod-delivery.src-stubby-dispatcher) by 2002:a05:6a20:918f:b0:1e1:aef4:9ce8 with SMTP id adf61e73a8af0-1eed4ff47fbmr1819361637.28.1739928440119; Tue, 18 Feb 2025 17:27:20 -0800 (PST) Reply-To: Sean Christopherson Date: Tue, 18 Feb 2025 17:27:02 -0800 In-Reply-To: <20250219012705.1495231-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: <20250219012705.1495231-1-seanjc@google.com> X-Mailer: git-send-email 2.48.1.601.g30ceb7b040-goog Message-ID: <20250219012705.1495231-8-seanjc@google.com> Subject: [PATCH 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 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. Signed-off-by: Sean Christopherson Reviewed-by: Tom Lendacky --- 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 7f6c8fedb235..241cf7769508 100644 --- a/arch/x86/kvm/svm/sev.c +++ b/arch/x86/kvm/svm/sev.c @@ -3940,7 +3940,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); @@ -3953,11 +3952,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: @@ -3965,15 +3962,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 /* @@ -3987,8 +3982,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; @@ -3999,8 +3993,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; @@ -4014,10 +4007,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.601.g30ceb7b040-goog From nobody Fri Dec 19 06:18:35 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 608751ADC76 for ; Wed, 19 Feb 2025 01:27:22 +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=1739928443; cv=none; b=TTkP3MD3q+MaBMDqnohUdk7pa0YEzjbAVBjW3IDHtMah0yYczLDoVZDvCHzq1ympNMugV9C5A3BB4ft2D0HfaRMK8n9A0C562drcTZsLDr8P1o9GhcSEf+mzvlApOkSQ6l5CeGTl+hj/bBcqGdGthTk8breaUzbfr0RhHaspPd8= ARC-Message-Signature: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1739928443; c=relaxed/simple; bh=sMb0VSq16pUIdqNUADb0can/VKUpPGYhL6VZ2dH8dR8=; h=Date:In-Reply-To:Mime-Version:References:Message-ID:Subject:From: To:Cc:Content-Type; b=Iv8x8+nEeW2jkbL5wRYbwYuHDid1qsl+4jk+JA6jLY4sx3NV2QaSfq43NB5sDnjkOzVi1xrehL6g46ctozmc5pi5DadIzdxfW7QAsrFYNSGb89BlyEHcE7Xiwxg4wUnm7HOU9GK1zqhfcN1Y5o6asS2bLdjoJ/9ZmMM3AAEJybg= 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=qqw0y8b6; 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="qqw0y8b6" Received: by mail-pj1-f73.google.com with SMTP id 98e67ed59e1d1-2fc318bd470so9293563a91.0 for ; Tue, 18 Feb 2025 17:27:22 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20230601; t=1739928441; x=1740533241; 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=PwxgaI2CeQipiv6np04CuCnpFX89Ht2qe65kPiXCVz0=; b=qqw0y8b6lwKBJwbUF4N2o7w1wpxIfZf6vNgXte1dRUSvxqlb8VH2JZufjEUSNBSooD AybeM0xlAWnD3mE0/PI7q38ztWhaf7MyPMLXas2AlTDmC2RodTJhSI9zQdbdLpucTrWq fSJiIskAupFfvhCT4/brvTTHdh33DMLRubJQwQ3oJKSCoWG3mmd6kZsn87IJASsdhkuJ hfHTllk78gSfPoGAbsTu6StfNyQSIoevjB1NOpyUsm5fXEMQOPq+oNDoewSCuhA+BFrr D+A6x1dCmT14r+yz3HH+80NdQbhpsqGkjnHubyHRGFbJO2tfD+oUcsIN3hoAy2EIR1Wv WACw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1739928441; x=1740533241; 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=PwxgaI2CeQipiv6np04CuCnpFX89Ht2qe65kPiXCVz0=; b=UOzUsgf978qUU5xODY3oPInwsgZi72FifNh+B39eraMjSmPKWFWo31pJXLs+1MQmjN 5I9ueXLkEXE7Q6XOgz/A8gJ4AHRH+Kx04Mzcndb5VwIxtmA34PVfagfpuXTtDGPHZfPh 6OHvJdZkfeTdn7NxDnPiN2U0IGFm/ntX4Y/oYINPmPueROcY5VqSGFrp5AqF3/dE0VQN VIf+EUSv1ajfS0ViyVJngwfL59UglJq8WWPX5rXyHPuvyWmZJmReiWlf3FMFk2/YZRpZ VIeFO2qMGK8106i6dwyMbCGK27vMq2metJnuYVTumCx4w485Eh+rg+OaM+s9ZIrNLJVo Z45A== X-Forwarded-Encrypted: i=1; AJvYcCUxQ9pJjseb8c2t4r+ws+kYKnHYB/NpjIHuxBTTYm6KLb12nW5Q2qubFJs23h/qHu62JZ/s53TrflmD0Vk=@vger.kernel.org X-Gm-Message-State: AOJu0YzjWEMNfMqVBt4EQciujp04xnOEGaZzQL5QbkybUOQa1GPze55X 4AMsoJhecwHWIAVZmOl957I1qbkSnvSZ5eAKHqE8E3TONM/TOVyLZLrnMQYTMHTEoUMz3tFsXpA vKg== X-Google-Smtp-Source: AGHT+IHJis5ONtqIAO2VNOmFspIDyiasqqxQJYi+5qvapE2J88c06Fq0obIwe/jPXwcuN/eIyBJbDFgl/3c= X-Received: from pfbig24.prod.google.com ([2002:a05:6a00:8b98:b0:730:7c03:35e1]) (user=seanjc job=prod-delivery.src-stubby-dispatcher) by 2002:a05:6a00:18a4:b0:730:9446:4d75 with SMTP id d2e1a72fcca58-732618e4f34mr22523992b3a.17.1739928441624; Tue, 18 Feb 2025 17:27:21 -0800 (PST) Reply-To: Sean Christopherson Date: Tue, 18 Feb 2025 17:27:03 -0800 In-Reply-To: <20250219012705.1495231-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: <20250219012705.1495231-1-seanjc@google.com> X-Mailer: git-send-email 2.48.1.601.g30ceb7b040-goog Message-ID: <20250219012705.1495231-9-seanjc@google.com> Subject: [PATCH 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 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. Signed-off-by: Sean Christopherson Reviewed-by: Tom Lendacky --- 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 241cf7769508..3a531232c3a1 100644 --- a/arch/x86/kvm/svm/sev.c +++ b/arch/x86/kvm/svm/sev.c @@ -3852,6 +3852,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; @@ -3897,12 +3903,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.601.g30ceb7b040-goog From nobody Fri Dec 19 06:18:35 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 D8F821AF4E9 for ; Wed, 19 Feb 2025 01:27:23 +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=1739928445; cv=none; b=HrEUSu5C4pihQmqWwB48RaUlslD+HTaf9kHLO+ew08eKgXBsbBOAijcZzvFdMOx8W8gBfxnnfANhopXu02E5fglR9h553DLoEqboll2rZRTDsMECt5EkPQcji68ULLdesLoPQyM6183Tng7HN1fnsBWRbtmS6D1VLizVyBwkc7E= ARC-Message-Signature: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1739928445; c=relaxed/simple; bh=V3Cuy8lI8q4I7DcMzksfdRcqVIHVzLT7AUJQqU8p+y0=; h=Date:In-Reply-To:Mime-Version:References:Message-ID:Subject:From: To:Cc:Content-Type; b=ZZ4Sy3asUYq0XdyBgsyyeokGzn5Ju/RX55Y38iJD3H/45MORdmn9GcehoDI5UZFsZ5xGYWwFZuskZZkiY8JvBxaK6fAn3v9UtfXy3uzPyMkmKMaryIckm8BvdxC8oXQ6/wNmmN8ysXp7ZJrKCeYte7raBsq3h/51L21wkk5Xm6s= 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=NwwBUywx; 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="NwwBUywx" Received: by mail-pj1-f74.google.com with SMTP id 98e67ed59e1d1-2fc1e7efdffso17415493a91.0 for ; Tue, 18 Feb 2025 17:27:23 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20230601; t=1739928443; x=1740533243; 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=O2hAAvRs0bclRxNF/THX7o+qs2YRSldWACuN7DP0Igc=; b=NwwBUywxTs1Qw24EnojYA+XMDSQgXf+yQ+dqQE8NgJFJJIb88xwGmzUkwU4/Seqi7D y/Ucdwq4weSJc/MCE897z2oDksi57RPZyobA4yWg6u7MPCfC3RIM/ujWP+/qRZWONRyv 3aPiQF64kX5ZjA2H+tMIfHGoVhIdpTnxcFaMP4Mst0+SWeeTHUrZPAtwiQH67yudYShc +UWs3jOmZ3BYPHqbxjsTCfAZuXW741gxrGfzjR7h68UxaT+n0VMedciMOmDvgyxLk0w1 egfXTPEBs7ONQh5RM8kKlJMf3p8CPj2HZqBy7oz2aDoM0ZOLCOfbsHXth07ai9+T/cun L/xg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1739928443; x=1740533243; 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=O2hAAvRs0bclRxNF/THX7o+qs2YRSldWACuN7DP0Igc=; b=jdQQTYrQG+injlOaHvhSQb9vWSgFWtFtZpEnfWG47ip4GLwIebPtwumMM58pXQofaN 4M2pEK6+uAhKCEYqx+UcrFF8aH7MY+iy5oA+jMo+NLg5AiD++qEtk2a6TEE0ow+54U5r 61NQbRtSBUoKinic5tM7K3x50R9bc8VP2lrRA8VYSEjjXpQ0WDW4FkcUBKOh7ydRFMnk gXd2OcEATeCuf9znvoiv16Vu2bOGOANqc9tLOMDNzE0vsQ9qNJflb/DkImJ1FFwQL6I6 XFRKbZUmOq+02PLmxxkofVPnD57h5LYIW1UE85jd4bJybI1FsgnmdSRmLGaiA+3V4XyQ +v4g== X-Forwarded-Encrypted: i=1; AJvYcCXKeIIjVfbuq2uZhvQt/kE200DJGXCoUDnjOE91eEZyNQGPt8B4gRElQwP0hYiiPxLPPIE/joMBrBcICkY=@vger.kernel.org X-Gm-Message-State: AOJu0YygtJPPemMWl9MlYZIKhdNBaGQpND9043QYsTUwFR88rRg/4nxV BdJ9nEUFeoIgOyt/h/9jDJs359seQ80/5nI5SXSfvsxhVw+dMOZO+8A7VqUr3Rh6Xkds0cirOrN OzQ== X-Google-Smtp-Source: AGHT+IGu4IMnRtTe5JpUjyMMXjFyU78RL3gzj9/hwjwrFcEJ7OLX2ZwVfXeUKi5ybG86HCwh2Z09aVsgVKc= X-Received: from pjbst12.prod.google.com ([2002:a17:90b:1fcc:b0:2f8:49ad:406c]) (user=seanjc job=prod-delivery.src-stubby-dispatcher) by 2002:a17:90b:5110:b0:2f4:4003:f3ea with SMTP id 98e67ed59e1d1-2fc411505d8mr26779335a91.33.1739928443281; Tue, 18 Feb 2025 17:27:23 -0800 (PST) Reply-To: Sean Christopherson Date: Tue, 18 Feb 2025 17:27:04 -0800 In-Reply-To: <20250219012705.1495231-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: <20250219012705.1495231-1-seanjc@google.com> X-Mailer: git-send-email 2.48.1.601.g30ceb7b040-goog Message-ID: <20250219012705.1495231-10-seanjc@google.com> Subject: [PATCH 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 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. Signed-off-by: Sean Christopherson Reviewed-by: Tom Lendacky --- 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 3a531232c3a1..15c324b61b24 100644 --- a/arch/x86/kvm/svm/sev.c +++ b/arch/x86/kvm/svm/sev.c @@ -3839,11 +3839,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; @@ -3858,78 +3873,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.601.g30ceb7b040-goog From nobody Fri Dec 19 06:18:35 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 BAF6E1B4245 for ; Wed, 19 Feb 2025 01:27:25 +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=1739928447; cv=none; b=GIpwYJwYTo1g1b0rWhgdw75r+CBUBv/Z/3o6go2n4VlKqX5Pnpln6XYG0A5R+EQZf3+1ol/ZKowxI15sTMqVZySCujVLY1FVpx3YHb59k2SRwgGpfmrwGG+RwZtPdQKla+AJ8ydyEQcQiMy+zmcWZRC95+9Gm6DQlPqaLNEdqVA= ARC-Message-Signature: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1739928447; c=relaxed/simple; bh=8HNmILbOSwalR8zIxIIl3FnGV1i2PFV3f6IC6S2LJd0=; h=Date:In-Reply-To:Mime-Version:References:Message-ID:Subject:From: To:Cc:Content-Type; b=XQYYRz0/OVS03B9qWT/bcPkbG9RDWer3aTTlerbH1E4e05qNY1/W9dmIb+VXWUICVJ1h+2xGjwqCFwiku9IKXMTBMOBJilpeyPRqy4cz6s2NQBk//5IWBPH7gp7nqSScexxI/dw/xE4pdlmscrKAJFt/2nqnnbJkOzph/M9/ra0= 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=n5D1tx5s; 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="n5D1tx5s" Received: by mail-pl1-f202.google.com with SMTP id d9443c01a7336-22119b07d52so46797635ad.1 for ; Tue, 18 Feb 2025 17:27:25 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20230601; t=1739928445; x=1740533245; 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=B2fI7t6EYAl/h+pggEYQL1iQEGSfxTQzaS+eT4QW64Y=; b=n5D1tx5s4LyrpmeIBuF6EoQcIisvIdOywDWaTyOeJn/di3wsacPlBIafIsNnT5l1ev AN9UDwMwVzsKX21lTUwp+4KuNfe5N/tW+4haM1UdU9NFv4Zhy74LW+BSgnG3s8XtB0bG BwUgD3hueQbqVv4Mxj7IHzalNKA3RrN7s8z5MNKqf8sa9TcDzDtIfDgbQK1LfAVZsTol dVRlzHU8UndRqQhDL6h9NAh0/z+O9FD6JWWwwmF3K2/nB4eUSbJOksFxFuYlz3arFh9Z iGjKPRs+moW0Kq945PVvNK1VSzm3QZO+ydkXq/XBUhPzTefEOEVYh6dAYOqrQ5ZINn5M HnVQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1739928445; x=1740533245; 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=B2fI7t6EYAl/h+pggEYQL1iQEGSfxTQzaS+eT4QW64Y=; b=XQuphfGjwhbRs4CB1pnQDVj5u1uQFzWYzFaQnMkcoJ92eSj6B6L4ssuI5iBn7dfo5j 8gEQFzlJimtEup2dCU7N+kV8TR+pZIA386DMwbohEgZ20BwG/CVu1YGfdOB86dMh1BQf bc1QHOu9jXNQon2b+TIMelfS3nT3VnnRG9m/ZdKZLihiPXLa2kfe6fMO8UbYatw2ulyw 7D08jzSTpf8nXYeK/y9KQB4kN1zqg0Fl5c23g9onJMV/vTAjJNFG4M8X7tefBBO3MGNZ voJbkYidquc8eEhqB/1vM4GBUUzcDxgn/cc9p2BIXHljMUI+d6fg5Ug6oqbuEfX3Au/v Z3nw== X-Forwarded-Encrypted: i=1; AJvYcCVgr4Ha6QmvJJ/QjUTOEqjDJuWAnTiq8OJT/kvTqjgoLoyIXLG6VraMezXM2vrIzFWV0DuzFqYcBaw4UdM=@vger.kernel.org X-Gm-Message-State: AOJu0YzgaNmBpO6fCCzZCg8Q+JP9r1vz8XvqzziFm+3glTHfZM3a/TFI 7BcfFsQKvwPmsvAF4KJimt21jRjP8WgM7yS8abSj7GVz/iRBc+J89FMXwvlHRqllyDJU2J0KC9S g/w== X-Google-Smtp-Source: AGHT+IGQDxe+HD8d0dlDg/Exw7kmkBeU3b0w8uvLuKNdfY8ETtEedCLbMAFDAagya2O0dqtA5uEXA76atec= X-Received: from pjbrs15.prod.google.com ([2002:a17:90b:2b8f:b0:2f2:e97a:e77f]) (user=seanjc job=prod-delivery.src-stubby-dispatcher) by 2002:a17:903:3d0c:b0:21f:7964:e989 with SMTP id d9443c01a7336-221040d84ccmr247065355ad.52.1739928445031; Tue, 18 Feb 2025 17:27:25 -0800 (PST) Reply-To: Sean Christopherson Date: Tue, 18 Feb 2025 17:27:05 -0800 In-Reply-To: <20250219012705.1495231-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: <20250219012705.1495231-1-seanjc@google.com> X-Mailer: git-send-email 2.48.1.601.g30ceb7b040-goog Message-ID: <20250219012705.1495231-11-seanjc@google.com> Subject: [PATCH 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 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. Signed-off-by: Sean Christopherson Reviewed-by: Tom Lendacky --- 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 15c324b61b24..7345cac6f93a 100644 --- a/arch/x86/kvm/svm/sev.c +++ b/arch/x86/kvm/svm/sev.c @@ -3877,6 +3877,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) @@ -3906,8 +3907,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.601.g30ceb7b040-goog