From patchwork Wed Feb 19 01:26:56 2025 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: Sean Christopherson X-Patchwork-Id: 13981403 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 9EE9882D91 for ; Wed, 19 Feb 2025 01:27:10 +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=1739928432; cv=none; b=lcIvjDCMWzTb3fA8iqQLvAyFu5XK+txYu7wi6+BDYpD5SC35t7npd4Z5PHxd/7u7sD2ROreFRj2UHjAblmindMFauFilJzZ2P3U+zlxYXmlkc6Vn4BqkR5t2qncBVBsh8Pn+FH5e0Slq2IngZUSxN5U2OSE/6aYt8F7KofDi/Jg= 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.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="LAMabYtP" Received: by mail-pj1-f73.google.com with SMTP id 98e67ed59e1d1-2fc1eadf5a8so11868634a91.3 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=YD0SILRYA2gClS5drtNzw8X3xKCnehD3EvfzXKLtSoRsrLR4olaPbh1OPN6FJhCFlh uRvStP/DruJvYp+OmZKNSeTUD7x0tiJumwcBipp8jCIY3YhxMWrNHsGVCMKYmuzDb6hd ZcyipoVkaushBwgY8N0GlZraYy+t7ZX263wl13bba1wCOfediEkJKqstv/tyK8wD81uw k0Y/aysApkdYZ9SiENEj3aULJ0xYnkzdatPtvUo66mNAgZyQv3TlPHHVTBpHp7s9tiLM HuXke9JmImjRXz0o/KgLjwHFIZI1Y9Q+q4OjUozyrDkxHPDXksU3WiC3bmjtkFG6wcJD ibZw== X-Gm-Message-State: AOJu0YzHRCWGI4Rw6vTAQspPZ5LYmP1BdNWhGmdSHaTNF6dY4Nxxi6xD hxvTZ7xlicnr1BhYhx3GJHGJpKQR2HI00Wg/LE6SbOVt8rI9TiZnaQ5JcMjEJzt6tfQXx4syMKe xvg== 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: kvm@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 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 --- 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) void sev_es_prepare_switch_to_guest(struct vcpu_svm *svm, struct sev_es_save_area *hostsa) { + struct kvm *kvm = 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 = native_get_debugreg(0); hostsa->dr1 = native_get_debugreg(1); hostsa->dr2 = native_get_debugreg(2); From patchwork Wed Feb 19 01:26:57 2025 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: Sean Christopherson X-Patchwork-Id: 13981404 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 54C7914B08C 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-2fc1e7efe00so10884715a91.2 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=Ez5E7y/lsYWq5veCjZWRoIQAd7vYd+EBLRPcNjWVg2xa1rdzwLfr1fu2tWwmly3os+ nUBDbWS6mJ/k/m6+yPLtAGa430nDTrE4h3o3VQzuXQTBfrDvqrWmcJQYVHgj5qvObt9F pcHP9EYjb12RlBozgJnioM/toPyc8O9TpadmvSsFIb6W3XChlDti1aLVZDMc3dSsbUTz aJfTlOZcjYo3sLgWofHkegAHpb/6l/3J74ZSIvQz8kubeB/0wUvs0k1hHvqEq+VhvG9s QfZuf9g316Htm75jQTuxPSAk939hM23XeM9CIvoDOy0kJFQIJPxLHwCJxpAw8S+JLELG kybw== X-Gm-Message-State: AOJu0Ywvnbu2dYdWssHyFCeOaN21Iqkh4fdsN9OyS0hKQatjp8n5YlrB 5l9gb7DAiUoNLKebw5563M6oTsZYwRLgJtHTOQU4qRR4jV3ETRa54eNKwXja5eH1V+Y/7Dr8qjq Dng== 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: kvm@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 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 --- 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 = native_get_debugreg(0); - hostsa->dr1 = native_get_debugreg(1); - hostsa->dr2 = native_get_debugreg(2); - hostsa->dr3 = native_get_debugreg(3); hostsa->dr0_addr_mask = amd_get_dr_addr_mask(0); hostsa->dr1_addr_mask = amd_get_dr_addr_mask(1); hostsa->dr2_addr_mask = amd_get_dr_addr_mask(2); From patchwork Wed Feb 19 01:26:58 2025 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: Sean Christopherson X-Patchwork-Id: 13981405 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 F364C16A959 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-2fbff6426f5so12384739a91.3 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=aj1YFRJ1iw946U9tblK29HaPWiUi91D/b6HE+c6mJKFgfsvAL0X7wmlX91b+EhQOK+ QSotcaomg5OvdqtjSGSzfjyo61TNJwSUrrtsnY/qn6EwZAkaeJ8e0AFrQt2jNTifY95A Xq5bXWBcW7MQ8hWNhw2k3vaj44PKER9c+Bms8zNudUUh/fENcRKt3kcLSOLsQKktjolM 5+W3o083vv+8vrY8g9SSs17VHlBEZ4H0oriPtqhAOPTOq+nm61qvsxmyzZ4GSJ2hfwXu GeJNaeID18sYwfnqZ//tGQqEHiXbfG0mPvadlBZixVBL7ZIu8gnBy8ADq9/q260i0jEH kkhQ== X-Gm-Message-State: AOJu0YwwyfJ24zUy2PuTIDVbgQ1s614VKjSj5OEG12NwEG2t7e5oGPCt PDa+nhnVtfUovERES9LnU5Q9p7upmM5QUDUC/n7OMvIzlHjBe6HSOUeO8Cp08Ga7tNes5WMO3w/ UUw== 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: kvm@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 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 = NULL; } -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 = per_cpu_ptr(&svm_data, cpu); - unsigned int asid = sev_get_asid(svm->vcpu.kvm); + struct kvm *kvm = svm->vcpu.kvm; + unsigned int asid = 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; + } /* Assign the asid allocated with this SEV guest */ svm->asid = asid; @@ -3468,11 +3479,12 @@ void pre_sev_run(struct vcpu_svm *svm, int cpu) */ if (sd->sev_vmcbs[asid] == svm->vmcb && svm->vcpu.arch.last_vmentry_cpu == cpu) - return; + return 0; sd->sev_vmcbs[asid] = svm->vmcb; svm->vmcb->control.tlb_ctl = TLB_CONTROL_FLUSH_ASID; vmcb_mark_dirty(svm->vmcb, VMCB_ASID); + return 0; } #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, fastpath_t exit_fastpath) return svm_invoke_exit_handler(vcpu, exit_code); } -static void pre_svm_run(struct kvm_vcpu *vcpu) +static int pre_svm_run(struct kvm_vcpu *vcpu) { struct svm_cpu_data *sd = per_cpu_ptr(&svm_data, vcpu->cpu); struct vcpu_svm *svm = 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 != sd->asid_generation) new_asid(svm, sd); + + return 0; } 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); - pre_svm_run(vcpu); + if (pre_svm_run(vcpu)) + return EXIT_FASTPATH_EXIT_USERSPACE; sync_lapic_to_cr8(vcpu); 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 *vcpu); /* sev.c */ -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, int in); From patchwork Wed Feb 19 01:26:59 2025 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: Sean Christopherson X-Patchwork-Id: 13981406 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 8A799189902 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-220ee2e7746so94943595ad.2 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=C++7pu/h/OM6C1Z9yrbNtxL6ZXEtDfOsS1Qf7KJMiUaf/TO+3+FxkjIfwQx0+QrAVF HYL1pQ3qe82+58ToREP7uRiI0R+zM/HVQibsy9XluDvbUeLwP8W/al7+25l9Ad8R8c2+ BWKA9u5pgsTsKiPlRtBcNx0/V0APajrzZX+lqSUC8Ooo6Q3I1SfpAuAW9bZTq0im5dhj hmwh6EY8sgLBeROE8Nxx3Gxs641P7jSE/0Heh1CstMRPU+QFszulGb0KdQjArBp4EPf5 wWwGqXzCLuZDOtedi5HmZkzP85f6yk5aCQ405VWqPI2QggXCKzV2qSuGZnX/4IcyDOkU DFrA== X-Gm-Message-State: AOJu0YzUPwhHizTtwmvmJQfI5E/rPk8wMA1w4klgnMQo8TcO2fTjPiBr D5NIo+zT7Aqqz3PuMbfIomfxrA7QYperU7yS/QHrEbgRdGj90FoFQKSlJEczh1LC3BnQY4XXDEj miw== 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: kvm@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 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 --- 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) /* * 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 = true; mutex_lock(&target_svm->sev_es.snp_vmsa_mutex); - target_svm->sev_es.snp_vmsa_gpa = INVALID_PAGE; - target_svm->sev_es.snp_ap_waiting_for_reset = 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 = svm->vmcb->control.exit_info_2; break; case SVM_VMGEXIT_AP_DESTROY: + target_svm->sev_es.snp_vmsa_gpa = INVALID_PAGE; break; default: vcpu_unimpl(vcpu, "vmgexit: invalid AP creation request [%#x] from guest\n", request); ret = -EINVAL; - break; + goto out; } -out: + target_svm->sev_es.snp_ap_waiting_for_reset = true; + if (kick) { kvm_make_request(KVM_REQ_UPDATE_PROTECTED_GUEST_STATE, target_vcpu); kvm_vcpu_kick(target_vcpu); } +out: mutex_unlock(&target_svm->sev_es.snp_vmsa_mutex); return ret; From patchwork Wed Feb 19 01:27:00 2025 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: Sean Christopherson X-Patchwork-Id: 13981407 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 24057192580 for ; Wed, 19 Feb 2025 01:27:16 +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=1739928438; cv=none; b=AOavi6hwiQAkVRnUvWhvuuGYjyYi0js57sU3uaiJhl/4sOGJRRgUTyt6Cz88zPqI2eiRLaFi5q4mI1z8IhKLAqRdVLdr/6SN+p/kD0TphdllHBToq+8UwGk4IAt2BJ0YBNf+tOoJ5c6aRCv5TyxFGZQx0dDD9OjLT2KYCFj8cJI= 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.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="u9jl//jl" Received: by mail-pj1-f73.google.com with SMTP id 98e67ed59e1d1-2fc4dc34291so6417241a91.3 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=m7ChGIvspqlfNBdG75dLK/A4PQlnw0XxNFwCAlfd16J4DH9Pz5hhN75BmfSiIS51pB 0RicQFPoRqjt0NrUHY19//aSZtagH3ITyapMFVX/nN3FQ9piPav6t0uXfm2cgONXqfnc guVdBsU1PLVbTCl1/ShBbIB/o+WRnwFX6dM+n0BA7XRF9pb+EebH/yicQf5227cSwJ+2 KsrVkH7q4JN65HLJu4L8knAyBMfGI9WwlESBH8P5ZA6WzteV7p7rZqTMQe4GbtcIoGYF e8oW6pe/U/3SNEmk6hjg5mD7NDgfJ23jNVSKpAZQ7az3GhGd6UxQsr/cAU3jsdiwfvPh gnDw== X-Gm-Message-State: AOJu0YwXUuV0HUeNtmEJbI+1KKPr/Sg/szlVa+uGtQcotPigJPHLJPOL KXvMc4Ov7myilS8q56Zt/tVAfzNQdiUn33vm4hBNQxHdImPKLALPL8KtLlkEecwdIML6k7Owfc8 /Cw== 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: kvm@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 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 => AP_CREATE fallthrough. Fixes: e366f92ea99e ("KVM: SEV: Support SEV-SNP AP Creation NAE event") Signed-off-by: Sean Christopherson --- 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_vcpu *vcpu) static int sev_snp_ap_creation(struct vcpu_svm *svm) { + struct kvm_sev_info *sev = to_kvm_sev_info(svm->vcpu.kvm); struct kvm_vcpu *vcpu = &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) mutex_lock(&target_svm->sev_es.snp_vmsa_mutex); - /* Interrupt injection mode shouldn't change for AP creation */ - if (request < SVM_VMGEXIT_AP_DESTROY) { - u64 sev_features; - - sev_features = vcpu->arch.regs[VCPU_REGS_RAX]; - sev_features ^= 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 = -EINVAL; - goto out; - } - } - switch (request) { case SVM_VMGEXIT_AP_CREATE_ON_INIT: kick = false; fallthrough; case SVM_VMGEXIT_AP_CREATE: + if (vcpu->arch.regs[VCPU_REGS_RAX] != sev->vmsa_features) { + vcpu_unimpl(vcpu, "vmgexit: mismatched AP sev_features [%#lx] != [%#llx] from guest\n", + vcpu->arch.regs[VCPU_REGS_RAX], sev->vmsa_features); + ret = -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); From patchwork Wed Feb 19 01:27:01 2025 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: Sean Christopherson X-Patchwork-Id: 13981408 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 F3DF319F103 for ; Wed, 19 Feb 2025 01:27:18 +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=1739928440; cv=none; b=HRFpjQZ+35HBvaeyeCThcdqbLHS0bAK652hIDg9U3xuOu5eiK52QljdFqB18bU95zr3JNP/UsQC62oaJW6ekUyAViQWYuwYzMbx4oqtyUSEJJc2AKdqZy0ZAiBpNzO6DpXKZhS/gi7Di67w2p8qRvtmHsAHICTrwND+hANFkykk= 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.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="WBc9F342" Received: by mail-pl1-f202.google.com with SMTP id d9443c01a7336-220f87a2800so137812585ad.0 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=DC2EJMf3Jttx9S6Febq/j7thVmc6einawjJ+t+o455NtRCDgwakDBk9z0lhDGeKDjt l9c8x/UGFQSRjUivLhc4mfRK6zohO6sE/hvL3Ma9GcjP8MJMMBjbbW5kyEm5PlOBAq9D KOVW/wcKb7vzNneYVVprpcW9GUYinfSlAeQRtX7XRjE+heAeCpeqnCQyou+i/I/qdfHR 3FCKuOiK6HSgqQlEnmLfRsdu6upaggzdw9P/h+rvIg5Ryh6j7GpBHSiXCHBlUtnBvRf1 rAAzL1prP5k0zH230IkeXMihzmZ8o7qh3QjOrx4fGLM0d+Cie3eBA9laqy91o12p1F/h 0klg== X-Gm-Message-State: AOJu0YygHbILn2wrStXR62cifHC55YtfOAA5ZqlL2ahrTfySHJvDSbr+ YM5c67w5pkSY+/v7sa0Rffa52clgXyzvQ4CAp6ZF3FHKESljM1H4ZfJTidOpmLmrKk87STjE3IY Dlg== 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: kvm@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 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 --- 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; request = lower_32_bits(svm->vmcb->control.exit_info_1); @@ -3958,18 +3957,10 @@ static int sev_snp_ap_creation(struct vcpu_svm *svm) target_svm = to_svm(target_vcpu); - /* - * The target vCPU is valid, so the vCPU will be kicked unless the - * request is for CREATE_ON_INIT. - */ - kick = true; - mutex_lock(&target_svm->sev_es.snp_vmsa_mutex); switch (request) { case SVM_VMGEXIT_AP_CREATE_ON_INIT: - kick = false; - fallthrough; case SVM_VMGEXIT_AP_CREATE: if (vcpu->arch.regs[VCPU_REGS_RAX] != sev->vmsa_features) { vcpu_unimpl(vcpu, "vmgexit: mismatched AP sev_features [%#lx] != [%#llx] from guest\n", @@ -4014,7 +4005,11 @@ static int sev_snp_ap_creation(struct vcpu_svm *svm) target_svm->sev_es.snp_ap_waiting_for_reset = true; - if (kick) { + /* + * Unless Creation is deferred until INIT, signal the vCPU to update + * its state. + */ + if (request != SVM_VMGEXIT_AP_CREATE_ON_INIT) { kvm_make_request(KVM_REQ_UPDATE_PROTECTED_GUEST_STATE, target_vcpu); kvm_vcpu_kick(target_vcpu); } From patchwork Wed Feb 19 01:27:02 2025 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: Sean Christopherson X-Patchwork-Id: 13981409 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 C81F71A8F9E for ; Wed, 19 Feb 2025 01:27:20 +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=1739928442; cv=none; b=Ldbh0y65m5XZf7RJ9z6Hyv/BtEURKNXguQVdt02y8JnlDBtHIQUBVSW4uYKEuTs/UpeLEnQyrVb8gNppOYnXl1MIDpeMARoMgg7RabNpTADP2JurpoC5LTHDeoV4QMhAnn3/LFYbqBirWYeirACFWDfdkOwp02b6q+aCLyobbxI= 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.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="aEyyk16+" Received: by mail-pl1-f202.google.com with SMTP id d9443c01a7336-220ee2e7746so94945835ad.2 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=dCEG9y3Cqp3xNPMQxRM5kQkplzQwZMWY8simmxv1CHIC9hK+87LIWPO32x0ZSljQs7 Dztfi5DLE47XRh+ZGR57G7oT3VFq4y0z7QW6c3QMof8IV8Qb493XGyuH597/eCVloZV8 NInTgYFykoFSCM/u+k8jfA2pylR7TVCCStctardFWNHv91hMJXQ6H6FKzJJNUTgAJrin kBgMKf1Z/LpqPnOH4/Q7GTvVnlZv62QVsDnJNtHLng3Ejg2M0TKHqqyo3aCQC/0ziLp4 H0RXjlBUT45kMNFQQwzlSmvb1zXjDQSoeeRT4xR4Gdr967JQL+bN3SJzVUSO+hFDleHg /uxQ== X-Gm-Message-State: AOJu0YzjcNcV6QeykVcGpqtff8aV64HVT5qksu4AgyDpZMuiZbanWwJF XTlv22yIYyQ3JDXx6qBD0Vl+PikgetE6gG74OTgp/8qnez0TSxIY/9yxGXEeeoeQwLxMZ5IIiDk RsA== 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: kvm@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 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 --- 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; request = lower_32_bits(svm->vmcb->control.exit_info_1); apic_id = 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; } - ret = 0; - target_svm = to_svm(target_vcpu); - mutex_lock(&target_svm->sev_es.snp_vmsa_mutex); + guard(mutex)(&target_svm->sev_es.snp_vmsa_mutex); 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] != sev->vmsa_features) { vcpu_unimpl(vcpu, "vmgexit: mismatched AP sev_features [%#lx] != [%#llx] from guest\n", vcpu->arch.regs[VCPU_REGS_RAX], sev->vmsa_features); - ret = -EINVAL; - goto out; + return -EINVAL; } 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 = -EINVAL; - goto out; + return -EINVAL; } /* @@ -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 = -EINVAL; - goto out; + return -EINVAL; } target_svm->sev_es.snp_vmsa_gpa = 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 = -EINVAL; - goto out; + return -EINVAL; } target_svm->sev_es.snp_ap_waiting_for_reset = true; @@ -4014,10 +4007,7 @@ static int sev_snp_ap_creation(struct vcpu_svm *svm) kvm_vcpu_kick(target_vcpu); } -out: - mutex_unlock(&target_svm->sev_es.snp_vmsa_mutex); - - return ret; + return 0; } static int snp_handle_guest_req(struct vcpu_svm *svm, gpa_t req_gpa, gpa_t resp_gpa) From patchwork Wed Feb 19 01:27:03 2025 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: Sean Christopherson X-Patchwork-Id: 13981410 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 4A65B19F47E 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-2fc1a4c150bso11995381a91.2 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=gbEj0MtRviVu4yxstqFdZ5ybGcVHtZdet6Ryqoau+3+XpSXvVoeUZ2wHyYUEofQRxF 6wl+pME/wuZ5j4TCACSVo09+2IZh20T6uTVUXTOYv7+axpE4I2/vHtDhIekPgM7+Lj+l 3HCHDMVnD8XLWFcbt3r11oIS1rz5Rod16OIus7t3G8BXjhRWxJnSn+TFdVY9aKlNdgNs TRDtLI+FcPQTL+4PVQ8NybkLqo3hGmom6Gqfpb5ajnH3badsiiEsYVrQ41/wbTPbx6aa 1k5IPAujGzeTNPRYJPlfS/g8LxN7AYkQDVjbqHGObb26NrVY9ea5oCM4B0v6HQqDkDHC wYIw== X-Gm-Message-State: AOJu0Yz8jgFyKD6StI5XPaPFVeNA0hoCrs+SM0Ex/SFb2pygSdKWHSys 6fsbCAQvRBFJd6TDA1woCZ30RSg/m96a7JxBC6gno2Rn8wWtVc19kGZ9tF7yWvBx8BbCgR6mkPZ njQ== 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: kvm@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 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 --- 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(struct kvm_vcpu *vcpu) /* Clear use of the VMSA */ svm->vmcb->control.vmsa_pa = INVALID_PAGE; + /* + * 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 = 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(struct kvm_vcpu *vcpu) kvm_release_page_clean(page); } - /* - * 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; } From patchwork Wed Feb 19 01:27:04 2025 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: Sean Christopherson X-Patchwork-Id: 13981411 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 D8F301AF0DC 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-2fbfa786a1aso19115614a91.3 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=YJoqcKcTu5WQdxHbwjZgdOMIYUbbdqLLGi3C0cQfr6umDmZ27ia7o0IMhGOddR5h7h uiPvyAehGBTg2cnWWxq6bNXbVtM16eIpBObm9qBoUubc3/RRfoPvBCqHixbPhhflD2n6 7CH7QCCVIdYjNPkPXOK585kuRifNs2ppa/giYlnRQECViclMmN16lvT2LOTOFu+gwSvj fVFOzPi0o44jMqcb00wFMo+Y3s+Yau5q1cxWTAHfjvB5fRJzyRCfgu7i8rS3U3CAdgRj 6/ViNU76O5hQELlPQAQX/jFlGflDA7cW14a3jODsB1ykHYZSSuD9EVvaWd0WhhfXbK0p 7NIA== X-Gm-Message-State: AOJu0Yy+DcxTMAA2QsmUWUsxSBjrJvSdR3GjoAoQcCEcPjT0WqZ9IQ27 aUF+jLJucZOF615Ccr6k3ydSny6181TSl77Z4L2/da8Rv3914I6iBe0+s6MKLZwFypVjUx3BGGW e3A== 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: kvm@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 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 --- 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, struct psc_buffer *psc) BUG(); } -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 = to_svm(vcpu); + struct kvm_memory_slot *slot; + struct page *page; + kvm_pfn_t pfn; + gfn_t gfn; - 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 = false; /* Mark the vCPU as offline and not runnable */ vcpu->arch.pv.pv_unhalted = false; @@ -3858,78 +3873,47 @@ static int __sev_snp_update_protected_guest_state(struct kvm_vcpu *vcpu) */ vmcb_mark_all_dirty(svm->vmcb); - if (VALID_PAGE(svm->sev_es.snp_vmsa_gpa)) { - gfn_t gfn = gpa_to_gfn(svm->sev_es.snp_vmsa_gpa); - struct kvm_memory_slot *slot; - struct page *page; - kvm_pfn_t pfn; - - slot = 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 = true; - - /* Use the new VMSA */ - svm->vmcb->control.vmsa_pa = pfn_to_hpa(pfn); - - /* Mark the vCPU as runnable */ - kvm_set_mp_state(vcpu, KVM_MP_STATE_RUNNABLE); - - svm->sev_es.snp_vmsa_gpa = 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 = to_svm(vcpu); - int ret; - - if (!sev_snp_guest(vcpu->kvm)) + if (!VALID_PAGE(svm->sev_es.snp_vmsa_gpa)) return; - mutex_lock(&svm->sev_es.snp_vmsa_mutex); + gfn = gpa_to_gfn(svm->sev_es.snp_vmsa_gpa); - if (!svm->sev_es.snp_ap_waiting_for_reset) - goto unlock; - - svm->sev_es.snp_ap_waiting_for_reset = false; + slot = gfn_to_memslot(vcpu->kvm, gfn); + if (!slot) + return; - ret = __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; -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 = true; + + /* Use the new VMSA */ + svm->vmcb->control.vmsa_pa = pfn_to_hpa(pfn); + + /* Mark the vCPU as runnable */ + kvm_set_mp_state(vcpu, KVM_MP_STATE_RUNNABLE); + + svm->sev_es.snp_vmsa_gpa = 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); } static int sev_snp_ap_creation(struct vcpu_svm *svm) From patchwork Wed Feb 19 01:27:05 2025 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: Sean Christopherson X-Patchwork-Id: 13981412 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 BCB561B4247 for ; Wed, 19 Feb 2025 01:27:25 +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=1739928447; cv=none; b=bBuoecdaEcxNAxcZ1CCsO8eqpmC7cI25t1QWysYNm/RHyuVr6wc8jqD7ihT6NfkmM7tmWH0ALGUP5753YpRFfCTWbkNwfkbltzE6KhCwaLrsn8xcbFoKue1oPAgJoRFl0nIMwA6eZXAKZuLKa+cNrW9JlF1mArrYluATc+aQQVI= 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.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="n5D1tx5s" Received: by mail-pl1-f201.google.com with SMTP id d9443c01a7336-220d1c24b25so128009415ad.0 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=PnxaAWfYhPgg395UhNcvG4b8+fwbTRRp0Qne9HXtxDOYe7+KmSGalhzG8J0ndtXiAR HXtJTbWSDUK3jX4K9leOwH1e6WYBG10hY6tKtfZlPkybtXSPTG1vD0kRjcqmJrQMuMXC F/Fs2wFiFAwdQF8qjP9lTEkoUFEp1XXUpGxAmu6vCev+T6B2XOIH5lhBHx/YkuTuYvgC 6Pp/pQQXzCZBnH8VIu0OXDpKLddH1e6mI26YKDXRnkyNw2H1bq1LtpeFT7mmjoZ3DGp6 2G0u2tL5Mamz79i3SP//GThdHO9rINTC4bJeP8ETAZQXLLGuEuZ4fhgu/XLdP6IG6tev bVmA== X-Gm-Message-State: AOJu0Yz2isDzzsm33/oEmEK8oqwKYoAt6MX4ZRlnrCVX/uFrwwyO7FxL GwhvjRlLzvZn/cztdBrmX3TUYP3d+QoUg0ZYmjfuw/Mlb9+SZEsS9c9RUMo2qrLUe8QjFio5ZeK ONQ== 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: kvm@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 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 --- 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_vcpu *vcpu) return; gfn = gpa_to_gfn(svm->sev_es.snp_vmsa_gpa); + svm->sev_es.snp_vmsa_gpa = INVALID_PAGE; slot = gfn_to_memslot(vcpu->kvm, gfn); if (!slot) @@ -3906,8 +3907,6 @@ void sev_snp_init_protected_guest_state(struct kvm_vcpu *vcpu) /* Mark the vCPU as runnable */ kvm_set_mp_state(vcpu, KVM_MP_STATE_RUNNABLE); - svm->sev_es.snp_vmsa_gpa = 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