From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from smtp.kernel.org (aws-us-west-2-korg-mail-1.web.codeaurora.org [10.30.226.201]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id 34E651FCFF3; Tue, 8 Apr 2025 12:31:25 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=10.30.226.201 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1744115485; cv=none; b=E7pKXVoJM5LnmcP7iKvpromcsIFkBOrZJtSySU03HlMY16uexYqCB76SV3H79zvKo7nE5diQJwLlwh7LQBnEnAw5oYLOsUa58bEPlaobk9619qMr1sYirW87p+ps5s0ZcD8miTAkVB9FsIEGsipOsu1WrxNnPohEKmcRSzZgLRg= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1744115485; c=relaxed/simple; bh=Bja0JJF075JqHfxKo41rPGZpyNiiHYECMNO8BSUIKw4=; h=From:To:Cc:Subject:Date:Message-ID:In-Reply-To:References: MIME-Version; b=HmU5Y2XegB4ayl9Wb4EQCymTtsVTLlZ9GugW1nHdi0szJnUAP5eNS3/4lonU0dMMOgose8sgBW/hj5q9D0MQ3ff24L7rEGmQ7jrwXaGTxI+1cOO32jZzilkDUsx/hyhva2dPvM/csthu0QY0se8C6LwCvFvKQZrhlXuOBAr8YTo= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dkim=pass (1024-bit key) header.d=linuxfoundation.org header.i=@linuxfoundation.org header.b=YTRJQUyj; arc=none smtp.client-ip=10.30.226.201 Authentication-Results: smtp.subspace.kernel.org; dkim=pass (1024-bit key) header.d=linuxfoundation.org header.i=@linuxfoundation.org header.b="YTRJQUyj" Received: by smtp.kernel.org (Postfix) with ESMTPSA id B6C84C4CEE5; Tue, 8 Apr 2025 12:31:24 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=linuxfoundation.org; s=korg; t=1744115485; bh=Bja0JJF075JqHfxKo41rPGZpyNiiHYECMNO8BSUIKw4=; h=From:To:Cc:Subject:Date:In-Reply-To:References:From; b=YTRJQUyjJhp0u5mausXr4Uvm0EJCQ9XtSDJfbG9yiyIQdDqnhFhOyV8Th4Gr4NDqs ZxpmgN/ZMPCh3hsuVnuUAkXa3gnvUVfYNvgkw3um5GCOZns+oUPOBDceSGrJawLyJp HgvJygQwbHPZuSkOQDz9PziiJWR4VXhGqOYlJIzg= From: Greg Kroah-Hartman To: stable@vger.kernel.org Cc: Greg Kroah-Hartman , patches@lists.linux.dev, Tom Lendacky , Pankaj Gupta , Sean Christopherson Subject: [PATCH 6.13 465/499] KVM: SVM: Dont change target vCPU state on AP Creation VMGEXIT error Date: Tue, 8 Apr 2025 12:51:17 +0200 Message-ID: <20250408104902.836686332@linuxfoundation.org> X-Mailer: git-send-email 2.49.0 In-Reply-To: <20250408104851.256868745@linuxfoundation.org> References: <20250408104851.256868745@linuxfoundation.org> User-Agent: quilt/0.68 X-stable: review X-Patchwork-Hint: ignore Precedence: bulk X-Mailing-List: stable@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 Content-Transfer-Encoding: 8bit 6.13-stable review patch. If anyone has any objections, please let me know. ------------------ From: Sean Christopherson commit d26638bfcdfc5c8c4e085dc3f5976a0443abab3c upstream. If KVM rejects an AP Creation event, leave the target vCPU state as-is. Nothing in the GHCB suggests the hypervisor is *allowed* to muck with vCPU state on failure, let alone required to do so. Furthermore, kicking only in the !ON_INIT case leads to divergent behavior, and even the "kick" case is non-deterministic. E.g. if an ON_INIT request fails, the guest can successfully retry if the fixed AP Creation request is made prior to sending INIT. And if a !ON_INIT fails, the guest can successfully retry if the fixed AP Creation request is handled before the target vCPU processes KVM's KVM_REQ_UPDATE_PROTECTED_GUEST_STATE. Fixes: e366f92ea99e ("KVM: SEV: Support SEV-SNP AP Creation NAE event") Cc: stable@vger.kernel.org Reviewed-by: Tom Lendacky Reviewed-by: Pankaj Gupta Link: https://lore.kernel.org/r/20250227012541.3234589-5-seanjc@google.com Signed-off-by: Sean Christopherson Signed-off-by: Greg Kroah-Hartman --- arch/x86/kvm/svm/sev.c | 13 ++++++------- 1 file changed, 6 insertions(+), 7 deletions(-) --- a/arch/x86/kvm/svm/sev.c +++ b/arch/x86/kvm/svm/sev.c @@ -3945,16 +3945,12 @@ static int sev_snp_ap_creation(struct vc /* * 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; @@ -4000,20 +3996,23 @@ static int sev_snp_ap_creation(struct vc 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;