From patchwork Thu Feb 27 01:25:32 2025 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: Sean Christopherson X-Patchwork-Id: 13993475 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 47599145B0B for ; Thu, 27 Feb 2025 01:25:46 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=209.85.216.74 ARC-Seal: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1740619547; cv=none; b=S3Xo/Yu3d3MsQ5PWrGWz7oShD3Q/Kw3Dv97jR/oUAvzDAxe2UYi4dUGHI5RbWQKB6VHpBRhq93E5eqFIdA9AhHdDLYIfnY1ADrUjyanBWnEgwOgibGq6l7i8xiSMQEfxEvU7hc6RZOQ7ZPikj85Jc+5o9Lwa9F8weHtrUzowrVQ= ARC-Message-Signature: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1740619547; c=relaxed/simple; bh=kEAizSXrh46aeFhOp+VD1iskoyu83eS9VfMafXdoPyw=; h=Date:In-Reply-To:Mime-Version:References:Message-ID:Subject:From: To:Cc:Content-Type; b=pc/Bdz+UV9R24NB9J7s/3sIa8KslXtaC6/5jivFmRz/gJfG5G21qqiMRdcXnZ1XarwRwUbKIyZA2KGZtkiKqbzQQQUZ3+TmUZMcDvPRv9rSWiS3c2choSz4qf9kdrSeurdunM1AuVGzWzwTEUjOEWaH7xT4Ua++DiRFSg745JVU= ARC-Authentication-Results: i=1; smtp.subspace.kernel.org; dmarc=pass (p=reject dis=none) header.from=google.com; spf=pass smtp.mailfrom=flex--seanjc.bounces.google.com; dkim=pass (2048-bit key) header.d=google.com header.i=@google.com header.b=YlIK2f0e; arc=none smtp.client-ip=209.85.216.74 Authentication-Results: smtp.subspace.kernel.org; dmarc=pass (p=reject dis=none) header.from=google.com Authentication-Results: smtp.subspace.kernel.org; spf=pass smtp.mailfrom=flex--seanjc.bounces.google.com Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=google.com header.i=@google.com header.b="YlIK2f0e" Received: by mail-pj1-f74.google.com with SMTP id 98e67ed59e1d1-2fbff6426f5so924408a91.3 for ; Wed, 26 Feb 2025 17:25:46 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20230601; t=1740619545; x=1741224345; darn=vger.kernel.org; h=cc:to:from:subject:message-id:references:mime-version:in-reply-to :date:reply-to:from:to:cc:subject:date:message-id:reply-to; bh=WBxe6FmXCGOPrPFuVLhffc7/ElAQfUF91a/RZlH0SFI=; b=YlIK2f0ep01e3unET3wZ9cspamj371E0ovB/7pMWFyYyzcsx2b0dvYfYJg2J2/qVz4 rcWLly3sQsO7/7Tm4yzQ+cDOmHrq1DwYFBpm75y03thRTCWzQiKDsKuIDjF4yuUkKql8 A4jonxLdsvuTzuS+LUOzrJHhlaiKyG42XgwBzxjhSyuEj93lcv2lL2CketCFh3ET+4Ec u1ABhrE8qXWbFY2CJr3ju0HqyIOpREVCo0O56Cjua4kz4G9HA1BUckagflQfJxnn1Tl/ 2tf6z+1rRW3NxqBhyjf8EK94T08RlEpoxH2apQLWn9pb9qE9mrGWnk4Zw+6DMaCaMme0 tFcw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1740619545; x=1741224345; h=cc:to:from:subject:message-id:references:mime-version:in-reply-to :date:reply-to:x-gm-message-state:from:to:cc:subject:date:message-id :reply-to; bh=WBxe6FmXCGOPrPFuVLhffc7/ElAQfUF91a/RZlH0SFI=; b=kM+ipXDp9RrarK+ZnogHVrxLuUxiyR+wi3WAGMOXWAidGjPAkP//IdFcsirXsRBktQ mbEKTa5lVnwDG4rNf/i+VIayxKtpvYChMY2bfgMV2z+qoj/l07Wd9kmxqGZC5HulyjFJ 0wFwxmCMUxsJYvhXlDvbU5kwpx/u4DC0JdwuHHmWr/Vdl9SvBKoo8c28/B+UfkE2Oen4 GgdKBkJOHJZ+vF/g1kq0p/jG3ddIBTNB6ygllMBaPbKBhr17kmG3vci2X68z4abDKQJI goNfTcwKCeBZgHxkOTOR8zMsE6sZdCCPJGsMfzy4Joe0sHB69l4Q/+5KkatKPYcYKhEL G3+Q== X-Gm-Message-State: AOJu0YxPdcs/enkLjCdeQroBAMUCBHr2YnZtkBz5i89FBGZH5J1GnU5T VP3+TZvyyY6hMLGR71TQ/etTBu/ZHVgs8lN+r6XgZRzaa/w34SzKeXHWzboTnoqaSBBfCfnNHc+ DOg== X-Google-Smtp-Source: AGHT+IFLLB2ah5LUDPH7+jBTjfbaA9q03uHcgdVTCPpDNBjOdpdUzsxjWAd40Su+shcjHt/50lC87iRJyZ0= X-Received: from pjb3.prod.google.com ([2002:a17:90b:2f03:b0:2fa:a101:743]) (user=seanjc job=prod-delivery.src-stubby-dispatcher) by 2002:a17:90b:4ecf:b0:2ee:f19b:86e5 with SMTP id 98e67ed59e1d1-2fe68ada443mr17254991a91.14.1740619545636; Wed, 26 Feb 2025 17:25:45 -0800 (PST) Reply-To: Sean Christopherson Date: Wed, 26 Feb 2025 17:25:32 -0800 In-Reply-To: <20250227012541.3234589-1-seanjc@google.com> Precedence: bulk X-Mailing-List: kvm@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: Mime-Version: 1.0 References: <20250227012541.3234589-1-seanjc@google.com> X-Mailer: git-send-email 2.48.1.711.g2feabab25a-goog Message-ID: <20250227012541.3234589-2-seanjc@google.com> Subject: [PATCH v2 01/10] KVM: SVM: Save host DR masks on CPUs with DebugSwap From: Sean Christopherson To: Sean Christopherson , Paolo Bonzini Cc: kvm@vger.kernel.org, linux-kernel@vger.kernel.org, Naveen N Rao , Kim Phillips , Tom Lendacky , Alexey Kardashevskiy , Pankaj Gupta When running SEV-SNP guests on a CPU that supports DebugSwap, always save the host's DR0..DR3 mask MSR values irrespective of whether or not DebugSwap is enabled, to ensure the host values aren't clobbered by the CPU. And for now, also save DR0..DR3, even though doing so isn't necessary (see below). SVM_VMGEXIT_AP_CREATE is deeply flawed in that it allows the *guest* to create a VMSA with guest-controlled SEV_FEATURES. A well behaved guest can inform the hypervisor, i.e. KVM, of its "requested" features, but on CPUs without ALLOWED_SEV_FEATURES support, nothing prevents the guest from lying about which SEV features are being enabled (or not!). If a misbehaving guest enables DebugSwap in a secondary vCPU's VMSA, the CPU will load the DR0..DR3 mask MSRs on #VMEXIT, i.e. will clobber the MSRs with '0' if KVM doesn't save its desired value. Note, DR0..DR3 themselves are "ok", as DR7 is reset on #VMEXIT, and KVM restores all DRs in common x86 code as needed via hw_breakpoint_restore(). I.e. there is no risk of host DR0..DR3 being clobbered (when it matters). However, there is a flaw in the opposite direction; because the guest can lie about enabling DebugSwap, i.e. can *disable* DebugSwap without KVM's knowledge, KVM must not rely on the CPU to restore DRs. Defer fixing that wart, as it's more of a documentation issue than a bug in the code. Note, KVM added support for DebugSwap on commit d1f85fbe836e ("KVM: SEV: Enable data breakpoints in SEV-ES"), but that is not an appropriate Fixes, as the underlying flaw exists in hardware, not in KVM. I.e. all kernels that support SEV-SNP need to be patched, not just kernels with KVM's full support for DebugSwap (ignoring that DebugSwap support landed first). Opportunistically fix an incorrect statement in the comment; on CPUs without DebugSwap, the CPU does NOT save or load debug registers, i.e. Fixes: e366f92ea99e ("KVM: SEV: Support SEV-SNP AP Creation NAE event") Cc: stable@vger.kernel.org Cc: Naveen N Rao Cc: Kim Phillips Cc: Tom Lendacky Cc: Alexey Kardashevskiy Reviewed-by: Tom Lendacky Signed-off-by: Sean Christopherson --- arch/x86/kvm/svm/sev.c | 13 ++++++++++--- 1 file changed, 10 insertions(+), 3 deletions(-) diff --git a/arch/x86/kvm/svm/sev.c b/arch/x86/kvm/svm/sev.c index 74525651770a..5c3d8618b722 100644 --- a/arch/x86/kvm/svm/sev.c +++ b/arch/x86/kvm/svm/sev.c @@ -4568,6 +4568,8 @@ void sev_es_vcpu_reset(struct vcpu_svm *svm) 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: @@ -4591,10 +4593,15 @@ 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). + * the CPU (Type-B). If DebugSwap is disabled/unsupported, the CPU does + * not save or load debug registers. Sadly, on CPUs without + * ALLOWED_SEV_FEATURES, KVM can't prevent SNP guests from enabling + * DebugSwap on secondary vCPUs without KVM's knowledge via "AP Create". + * Save all registers if DebugSwap is supported to prevent host state + * from being clobbered by a misbehaving guest. */ - if (sev_vcpu_has_debug_swap(svm)) { + if (sev_vcpu_has_debug_swap(svm) || + (sev_snp_guest(kvm) && cpu_feature_enabled(X86_FEATURE_DEBUG_SWAP))) { hostsa->dr0 = native_get_debugreg(0); hostsa->dr1 = native_get_debugreg(1); hostsa->dr2 = native_get_debugreg(2); From patchwork Thu Feb 27 01:25:33 2025 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: Sean Christopherson X-Patchwork-Id: 13993476 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 227BD1527B1 for ; Thu, 27 Feb 2025 01:25:47 +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=1740619549; cv=none; b=hSugto6QRiNMVlaj9fBuccVt6wKV09rVqPsmVgk+AE9VlSynDKrTm4zMCEZS1ONwHCzMscW1T+lOZMgktiG7MpyVAvYKaNPOGgtPrSYwEiv2WGimP0zfVhi1qq9fZv1jEDC0BV8RRNLlrAH64BUvxMYGzy/Fzq7x/EBOyHhPm58= ARC-Message-Signature: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1740619549; c=relaxed/simple; bh=o7YIiPy0L+iXjiHb8AA0Ly3jDIFWOKKVvokPylQxXQ4=; h=Date:In-Reply-To:Mime-Version:References:Message-ID:Subject:From: To:Cc:Content-Type; b=Pu01s77A4S8g4gVzf8eVhk6gNrKuse2ctNHruE9c8hqsVJetE71GZC+e2qZz1fSqkXqznDnDaq0DqajMbC/D+vs18tDdB9S7otKmp2lYHdLn5J9JAYdV3yo77MSegmQrSiuqLAgNYB2ffenkf2GqgK7MSRR+hFCyYge2ZEry7Ec= ARC-Authentication-Results: i=1; smtp.subspace.kernel.org; dmarc=pass (p=reject dis=none) header.from=google.com; spf=pass smtp.mailfrom=flex--seanjc.bounces.google.com; dkim=pass (2048-bit key) header.d=google.com header.i=@google.com header.b=D92oqqMI; arc=none smtp.client-ip=209.85.216.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="D92oqqMI" Received: by mail-pj1-f73.google.com with SMTP id 98e67ed59e1d1-2fe98fad333so964588a91.2 for ; Wed, 26 Feb 2025 17:25:47 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20230601; t=1740619547; x=1741224347; darn=vger.kernel.org; h=cc:to:from:subject:message-id:references:mime-version:in-reply-to :date:reply-to:from:to:cc:subject:date:message-id:reply-to; bh=I3z60PyMclA7mj8jFqKxMTzcWzViARYic6y8atlWZws=; b=D92oqqMIOjvjUd1mjlw2/j5gXRKo5E3FR0dHWT8wLnlZiXt69oHzJJha9yUkJ+efCA 9Wp3H4ty3lXx60YYGo283UjmHQYowWaGOd9cvu56WHczy2wzLnJ4MIherDlrGCpGWbVd rZovOCEmVfdHJnEQ6iX5fWwzraO5a5IXcGR6VKFhbLhsrc9IPuHrAdgWL/2Osh5HwFeA cpppusL3QZ6NA/Qi0uDQw4pELsbT9o5pOQJ8vItFnI3rp6wp06EgKj0N9ruDg2ov9MAt fGg9+wnet6sF7ah+3LM6QhV8MYD/LlbOiqnBpspZ4s+thPU3J4UNgvD4hxPDu7H/7mYZ owuA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1740619547; x=1741224347; h=cc:to:from:subject:message-id:references:mime-version:in-reply-to :date:reply-to:x-gm-message-state:from:to:cc:subject:date:message-id :reply-to; bh=I3z60PyMclA7mj8jFqKxMTzcWzViARYic6y8atlWZws=; b=wd4ZRLMiRaUSbG1z7462m60a8AJfWC2pW3VzZnopQZOcryPlTo7r8XVDw/ofA3KfJB XU41/B1bE6B/4iYXADNCmf/Un+vpAwLlSliZI/1GtL1lq4GQG/5g4xRjYsDf7Ua4aO6Z /OwYhKZeXLhzsN5r8WmqYPpTHUbVbQArroVz8KuCXC9cST6vpbqeZddQHkqGESH4yTgm FLLUczTe47liFVgjvmUri5qHervz0UiGdwqk5Zx5zEX8i9fpGdQlvPopfY7775s9aCZh v1UZ3yCTE9ekEG/HGuBQn4vdzgo2yc8c8trPTURLnYpcoROzfY0T9YDcMVK6Vdwsowzf dWZw== X-Gm-Message-State: AOJu0YzToUwm4agEm7oynaexOao/zjFLj5iDry5DFvbUEZI5bYy2U26M 177q7UrxQENnTQgwPF21A/Qo2xVf6tDmY9tzNXFaIQ5Q+PeqzyL4g0gX9Olszb4huqTb+2CjSWG jWQ== X-Google-Smtp-Source: AGHT+IHge2PUPDhQVHWderK3qNVut5fMR2npsRs1k9qIMwEd1T0TG6+5b5xVL5Lj7czmJ3HyOQZWBoz5m3s= X-Received: from pjbst5.prod.google.com ([2002:a17:90b:1fc5:b0:2fa:210c:d068]) (user=seanjc job=prod-delivery.src-stubby-dispatcher) by 2002:a17:90b:17cd:b0:2f9:c139:b61f with SMTP id 98e67ed59e1d1-2fce78a3812mr43989600a91.14.1740619547337; Wed, 26 Feb 2025 17:25:47 -0800 (PST) Reply-To: Sean Christopherson Date: Wed, 26 Feb 2025 17:25:33 -0800 In-Reply-To: <20250227012541.3234589-1-seanjc@google.com> Precedence: bulk X-Mailing-List: kvm@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: Mime-Version: 1.0 References: <20250227012541.3234589-1-seanjc@google.com> X-Mailer: git-send-email 2.48.1.711.g2feabab25a-goog Message-ID: <20250227012541.3234589-3-seanjc@google.com> Subject: [PATCH v2 02/10] KVM: SVM: Don't rely on DebugSwap to restore host DR0..DR3 From: Sean Christopherson To: Sean Christopherson , Paolo Bonzini Cc: kvm@vger.kernel.org, linux-kernel@vger.kernel.org, Naveen N Rao , Kim Phillips , Tom Lendacky , Alexey Kardashevskiy , Pankaj Gupta Never rely on the CPU to restore/load host DR0..DR3 values, even if the CPU supports DebugSwap, as there are no guarantees that SNP guests will actually enable DebugSwap on APs. E.g. if KVM were to rely on the CPU to load DR0..DR3 and skipped them during hw_breakpoint_restore(), KVM would run with clobbered-to-zero DRs if an SNP guest created APs without DebugSwap enabled. Update the comment to explain the dangers, and hopefully prevent breaking KVM in the future. Reviewed-by: Tom Lendacky Signed-off-by: Sean Christopherson --- arch/x86/kvm/svm/sev.c | 21 ++++++++++++--------- 1 file changed, 12 insertions(+), 9 deletions(-) diff --git a/arch/x86/kvm/svm/sev.c b/arch/x86/kvm/svm/sev.c index 5c3d8618b722..719cd48330f1 100644 --- a/arch/x86/kvm/svm/sev.c +++ b/arch/x86/kvm/svm/sev.c @@ -4594,18 +4594,21 @@ void sev_es_prepare_switch_to_guest(struct vcpu_svm *svm, struct sev_es_save_are /* * If DebugSwap is enabled, debug registers are loaded but NOT saved by * the CPU (Type-B). If DebugSwap is disabled/unsupported, the CPU does - * not save or load debug registers. Sadly, on CPUs without - * ALLOWED_SEV_FEATURES, KVM can't prevent SNP guests from enabling - * DebugSwap on secondary vCPUs without KVM's knowledge via "AP Create". - * Save all registers if DebugSwap is supported to prevent host state - * from being clobbered by a misbehaving guest. + * not save or load debug registers. Sadly, KVM can't prevent SNP + * guests from lying about DebugSwap on secondary vCPUs, i.e. the + * SEV_FEATURES provided at "AP Create" isn't guaranteed to match what + * the guest has actually enabled (or not!) in the VMSA. + * + * If DebugSwap is *possible*, save the masks so that they're restored + * if the guest enables DebugSwap. But for the DRs themselves, do NOT + * rely on the CPU to restore the host values; KVM will restore them as + * needed in common code, via hw_breakpoint_restore(). Note, KVM does + * NOT support virtualizing Breakpoint Extensions, i.e. the mask MSRs + * don't need to be restored per se, KVM just needs to ensure they are + * loaded with the correct values *if* the CPU writes the MSRs. */ if (sev_vcpu_has_debug_swap(svm) || (sev_snp_guest(kvm) && cpu_feature_enabled(X86_FEATURE_DEBUG_SWAP))) { - hostsa->dr0 = 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 Thu Feb 27 01:25:34 2025 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: Sean Christopherson X-Patchwork-Id: 13993477 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 E00E415E5C2 for ; Thu, 27 Feb 2025 01:25:49 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=209.85.214.202 ARC-Seal: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1740619551; cv=none; b=jHsH2OtcTYPIF93yK6A1ZPdAtsscRd7lrpKWnbqhcJFsybHei+/tCX5GhJuNer1mZ6pbqX8rIaSsOhXsFjDno0vJpxkKhjA8qWJeBrCUBUZQjElnDrWq1J0PLnXFTnewP1e+kTKNq90l7oSQP84cSI9NmJm37KJ5YUkSmB9994c= ARC-Message-Signature: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1740619551; c=relaxed/simple; bh=Bd2jcIIVus5KKhQQxvEgLThZpvhnEnb0Zp6oqmiDeNc=; h=Date:In-Reply-To:Mime-Version:References:Message-ID:Subject:From: To:Cc:Content-Type; b=NZ9tEiR4j+UbI5qp9a8z9pEORBygkQElcz4Mv//45ly2bKHES1yZt4ToaMe7lE3mWtqUgQliNcnjIdLgWugy0e1FB5hn2m3jXBxNz9C+oSXS89sP3QunDLcSfOJTPvbuRiviQqWVnAr7EO++OAZ4xq4EHCBTMRZka5/x27Me5Do= ARC-Authentication-Results: i=1; smtp.subspace.kernel.org; dmarc=pass (p=reject dis=none) header.from=google.com; spf=pass smtp.mailfrom=flex--seanjc.bounces.google.com; dkim=pass (2048-bit key) header.d=google.com header.i=@google.com header.b=sX+ytRaW; arc=none smtp.client-ip=209.85.214.202 Authentication-Results: smtp.subspace.kernel.org; dmarc=pass (p=reject dis=none) header.from=google.com Authentication-Results: smtp.subspace.kernel.org; spf=pass smtp.mailfrom=flex--seanjc.bounces.google.com Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=google.com header.i=@google.com header.b="sX+ytRaW" Received: by mail-pl1-f202.google.com with SMTP id d9443c01a7336-22350e4b7baso4602925ad.3 for ; Wed, 26 Feb 2025 17:25:49 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20230601; t=1740619549; x=1741224349; darn=vger.kernel.org; h=cc:to:from:subject:message-id:references:mime-version:in-reply-to :date:reply-to:from:to:cc:subject:date:message-id:reply-to; bh=SpiV/7IGUVGhPtuzMA7ncb1Ov7eVPXJdzTw8o7Y+oeM=; b=sX+ytRaWgmh8rx/g4QSbKm4lQHPMSzGHtVbJ1Wy1V6TnQmybyQVt3YbiYQhlmKEX0Z 2RvmjqrzNyGl1bsd5mzPU7rwEeFVPEPS8T41yUQ1RZrVmKtT+iOFxaGPqrpUCbNNm7n+ LZISBDJVVeYa4d5Bpr+qs0+IJgciD7wVX1EAyacNOYGjZGLsTHQ8VW8+BpMigcz9pZ9y j3pSFDXvf66VcAD0827ALYTduV2zO3kFm83FcgeJJviRyb4klyIM6g4WXvrr0f1n3/jP 23kpn4GtmZBTYmm3Td5KnZHXpuR2HgwP2Km/tOfevX4u6ymLvrFBl5P+GSywf7IcofXT f+tQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1740619549; x=1741224349; h=cc:to:from:subject:message-id:references:mime-version:in-reply-to :date:reply-to:x-gm-message-state:from:to:cc:subject:date:message-id :reply-to; bh=SpiV/7IGUVGhPtuzMA7ncb1Ov7eVPXJdzTw8o7Y+oeM=; b=Ov4pMlLOWuls4B2kN8/vvthZIHZc5fCNjEHNutbnlkUbRxu106VDVLfaGI9o4LB6B+ 6sa8+9n1GiK/dHuEqx829ZpMBIKsqKlEnOr7o9T7/JTGGaPyzon+RtvkqY1INPnkvlwy rh3kOfpVUukrSDW0LFjrLsW423SIdKrpBS3WR8mXqThaed4P++S0dWLGRYCKp7nNInKf jkTISDJ6LwGHZTSmOUKvtQHUh/JocPtjVf/M8X2KgG7BfPxdLIB8Uay2NUdGTqVUkQW6 S46STNDY6jE+wrcnSxarIAyf5+E3bMe2FmzZHHLfv2MXTl0VcgkBznIV7ybm+JhDeacD nYQg== X-Gm-Message-State: AOJu0Ywaxzw4xS2Df7fXde2OFd4Y8q00olyKgo4ACr5c2f/0pP3NM/RB 7JXXKzr6CIl2ZC6Zf1gzkhjBMAuRBiGOGSXpu9Atjs4wUnKNuH6IivRasYz03TOTJAlfEGSHKA1 VFw== X-Google-Smtp-Source: AGHT+IEBhn1N/oyrrmPhXLjz3V/jBJme9qVZVIFVvFpCt+5P1PKn2MbmobZJwvu3dN1sDK4eJAez625G97g= X-Received: from pfcg22.prod.google.com ([2002:a05:6a00:23d6:b0:730:880d:7ed5]) (user=seanjc job=prod-delivery.src-stubby-dispatcher) by 2002:a05:6a00:1310:b0:730:9567:c3d5 with SMTP id d2e1a72fcca58-7347909fee5mr15105470b3a.4.1740619549128; Wed, 26 Feb 2025 17:25:49 -0800 (PST) Reply-To: Sean Christopherson Date: Wed, 26 Feb 2025 17:25:34 -0800 In-Reply-To: <20250227012541.3234589-1-seanjc@google.com> Precedence: bulk X-Mailing-List: kvm@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: Mime-Version: 1.0 References: <20250227012541.3234589-1-seanjc@google.com> X-Mailer: git-send-email 2.48.1.711.g2feabab25a-goog Message-ID: <20250227012541.3234589-4-seanjc@google.com> Subject: [PATCH v2 03/10] KVM: SVM: Refuse to attempt VRMUN if an SEV-ES+ guest has an invalid VMSA From: Sean Christopherson To: Sean Christopherson , Paolo Bonzini Cc: kvm@vger.kernel.org, linux-kernel@vger.kernel.org, Naveen N Rao , Kim Phillips , Tom Lendacky , Alexey Kardashevskiy , Pankaj Gupta Explicitly reject KVM_RUN with KVM_EXIT_FAIL_ENTRY if userspace "coerces" KVM into running an SEV-ES+ guest with an invalid VMSA, e.g. by modifying a vCPU's mp_state to be RUNNABLE after an SNP vCPU has undergone a Destroy event. On Destroy or failed Create, KVM marks the vCPU HALTED so that *KVM* doesn't run the vCPU, but nothing prevents a misbehaving VMM from manually making the vCPU RUNNABLE via KVM_SET_MP_STATE. Attempting VMRUN with an invalid VMSA should be harmless, but knowingly executing VMRUN with bad control state is at best dodgy. Fixes: e366f92ea99e ("KVM: SEV: Support SEV-SNP AP Creation NAE event") Signed-off-by: Sean Christopherson Reviewed-by: Tom Lendacky Reviewed-by: Pankaj Gupta --- arch/x86/kvm/svm/sev.c | 16 +++++++++++++--- arch/x86/kvm/svm/svm.c | 11 +++++++++-- arch/x86/kvm/svm/svm.h | 2 +- 3 files changed, 23 insertions(+), 6 deletions(-) diff --git a/arch/x86/kvm/svm/sev.c b/arch/x86/kvm/svm/sev.c index 719cd48330f1..218738a360ba 100644 --- a/arch/x86/kvm/svm/sev.c +++ b/arch/x86/kvm/svm/sev.c @@ -3452,10 +3452,19 @@ void sev_es_unmap_ghcb(struct vcpu_svm *svm) svm->sev_es.ghcb = 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); + + /* + * Reject KVM_RUN if userspace attempts to run the vCPU with an invalid + * VMSA, e.g. if userspace forces the vCPU to be RUNNABLE after an SNP + * AP Destroy event. + */ + if (sev_es_guest(kvm) && !VALID_PAGE(svm->vmcb->control.vmsa_pa)) + return -EINVAL; /* Assign the asid allocated with this SEV guest */ svm->asid = asid; @@ -3468,11 +3477,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..f72bcf2e590e 100644 --- a/arch/x86/kvm/svm/svm.c +++ b/arch/x86/kvm/svm/svm.c @@ -3587,7 +3587,7 @@ static int svm_handle_exit(struct kvm_vcpu *vcpu, 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,12 @@ 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)) { + vcpu->run->exit_reason = KVM_EXIT_FAIL_ENTRY; + vcpu->run->fail_entry.hardware_entry_failure_reason = SVM_EXIT_ERR; + vcpu->run->fail_entry.cpu = vcpu->cpu; + 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 Thu Feb 27 01:25:35 2025 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: Sean Christopherson X-Patchwork-Id: 13993478 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 94F5117A2FF for ; Thu, 27 Feb 2025 01:25:51 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=209.85.216.74 ARC-Seal: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1740619553; cv=none; b=ks0Upgtt+WAe/XxOSGu5vOuRdfiap+MPWmtEjlX+zlrMkwFxyew6dR5G78FGL7Ox+u0ku4QVrolSmZSO6LUJPFVQv1xdctuayerEYS5grHIXqziyax/gNNLisPSUbMaJt2PBetLA2cwffwvyhid242qXi254/zVxaWZwKZ6RTBU= ARC-Message-Signature: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1740619553; c=relaxed/simple; bh=Ewaz9FSthSc+aO9YPlgCWiZASwxM0Q3IHNbCrYZLtjE=; h=Date:In-Reply-To:Mime-Version:References:Message-ID:Subject:From: To:Cc:Content-Type; b=V7hDWO4bReyqgUtkmjxNTuP17TAquam5OagLpL4mzCfA9iB/n7yOBG0ri9+sIKKa/7J2s6L7QUYu6lGMgVkxp8LtAwh4woiKdxpCQ0IeDB/+qFanq33OkKqk+1aJyN0+kBkKGJ2X/tEuQ6brLO7IwHjgpYY5MI1f7fA7c3LOu6A= ARC-Authentication-Results: i=1; smtp.subspace.kernel.org; dmarc=pass (p=reject dis=none) header.from=google.com; spf=pass smtp.mailfrom=flex--seanjc.bounces.google.com; dkim=pass (2048-bit key) header.d=google.com header.i=@google.com header.b=ImvSxEue; arc=none smtp.client-ip=209.85.216.74 Authentication-Results: smtp.subspace.kernel.org; dmarc=pass (p=reject dis=none) header.from=google.com Authentication-Results: smtp.subspace.kernel.org; spf=pass smtp.mailfrom=flex--seanjc.bounces.google.com Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=google.com header.i=@google.com header.b="ImvSxEue" Received: by mail-pj1-f74.google.com with SMTP id 98e67ed59e1d1-2fc3e239675so1430387a91.0 for ; Wed, 26 Feb 2025 17:25:51 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20230601; t=1740619551; x=1741224351; darn=vger.kernel.org; h=cc:to:from:subject:message-id:references:mime-version:in-reply-to :date:reply-to:from:to:cc:subject:date:message-id:reply-to; bh=sGOwbvJmfkCQ/c7rRacZC8cGcdWEXYUj8tUGbmEnuuE=; b=ImvSxEueIAH4AOmrXFYV2IcuZtNnCapc0pNkrVWrOiqXXZtDcPrkyDfcVYIWWTRrAS uPARJMNA2kUev5LdmFd/mnNkb3JLTFON1kGj2gTceIkPduV8JuQ6lQqTNZZNuiDW3N4V U9Z8Zohb63sxYcvniUoj0PdqH+aOrgr0y4u0H1fyOoSFHAWce9X09N27ov8We47D4mP5 2f8udvpxvvuF3DNtq1cE/AAJHMe00N0rudyXnuQlxReudj7duckLRdZkONPKFGBlDbRx 9SUau9LHho3HrBtUWmaWYcU2Y1x55qBa66FC33jW97Tul0bkf98VQksi205GvsXTIYRG 8+JA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1740619551; x=1741224351; h=cc:to:from:subject:message-id:references:mime-version:in-reply-to :date:reply-to:x-gm-message-state:from:to:cc:subject:date:message-id :reply-to; bh=sGOwbvJmfkCQ/c7rRacZC8cGcdWEXYUj8tUGbmEnuuE=; b=Rtdjg1v62EgWIjlf5G27a4NAbygaogR9pyJVnFdquXORxazWWf9iYg7SSyuAbDuk/d h0Q/oKVJxZ92eC9z8zEcmniw+B+HJIKsl29jJ0wj5lZB+2fA2EC319uiCfu/9xQyhH+6 cVNT7TeBjRuZClwxCTmzrXf7PV2P81xN2n3Ai5+NYcIsVcgx0TCH1n3bMZ2POxDAYV4n v8Lqhyn3V4daEyWSfpeIBVc3/n1Vo5+VdrKMvdg+d3uNRiae4AUkr/OXj++jvZtupGtE 0U2IQSVodhrCDcqFiJhFCnoYhHz4C8/XM/PXpciYOXYQQsXftBOtcAPtOLUKg4iEVdfr c8YQ== X-Gm-Message-State: AOJu0YyfrCQXQWRnUP8Yo2OoNprteOwkH0WYHm7A+Byqp5mDG4pySx33 HJeedX9wym3p04qNrV1+5mR8MFJJxNrOFaNMWpPzePMYkNx8c3gnIgBSFE8woRJ+rIKTm1j8NV/ c7Q== X-Google-Smtp-Source: AGHT+IFyryo7Y/u0uoVmOAJ5RVcaLpqcG1z9HpmL8i/TdRHGqTe/axQ2uqXYM/vYbUj6f5PszfDahrT6N+s= X-Received: from pjtu16.prod.google.com ([2002:a17:90a:c890:b0:2ee:3128:390f]) (user=seanjc job=prod-delivery.src-stubby-dispatcher) by 2002:a17:90b:3c84:b0:2fc:c262:ef4b with SMTP id 98e67ed59e1d1-2fce86cf0e0mr42713073a91.18.1740619550877; Wed, 26 Feb 2025 17:25:50 -0800 (PST) Reply-To: Sean Christopherson Date: Wed, 26 Feb 2025 17:25:35 -0800 In-Reply-To: <20250227012541.3234589-1-seanjc@google.com> Precedence: bulk X-Mailing-List: kvm@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: Mime-Version: 1.0 References: <20250227012541.3234589-1-seanjc@google.com> X-Mailer: git-send-email 2.48.1.711.g2feabab25a-goog Message-ID: <20250227012541.3234589-5-seanjc@google.com> Subject: [PATCH v2 04/10] KVM: SVM: Don't change target vCPU state on AP Creation VMGEXIT error From: Sean Christopherson To: Sean Christopherson , Paolo Bonzini Cc: kvm@vger.kernel.org, linux-kernel@vger.kernel.org, Naveen N Rao , Kim Phillips , Tom Lendacky , Alexey Kardashevskiy , Pankaj Gupta If KVM rejects an AP Creation event, leave the target vCPU state as-is. Nothing in the GHCB suggests the hypervisor is *allowed* to muck with vCPU state on failure, let alone required to do so. Furthermore, kicking only in the !ON_INIT case leads to divergent behavior, and even the "kick" case is non-deterministic. E.g. if an ON_INIT request fails, the guest can successfully retry if the fixed AP Creation request is made prior to sending INIT. And if a !ON_INIT fails, the guest can successfully retry if the fixed AP Creation request is handled before the target vCPU processes KVM's KVM_REQ_UPDATE_PROTECTED_GUEST_STATE. Fixes: e366f92ea99e ("KVM: SEV: Support SEV-SNP AP Creation NAE event") Cc: stable@vger.kernel.org Reviewed-by: Tom Lendacky Signed-off-by: Sean Christopherson Reviewed-by: Pankaj Gupta --- arch/x86/kvm/svm/sev.c | 13 ++++++------- 1 file changed, 6 insertions(+), 7 deletions(-) diff --git a/arch/x86/kvm/svm/sev.c b/arch/x86/kvm/svm/sev.c index 218738a360ba..9aad0dae3a80 100644 --- a/arch/x86/kvm/svm/sev.c +++ b/arch/x86/kvm/svm/sev.c @@ -3957,16 +3957,12 @@ static int sev_snp_ap_creation(struct vcpu_svm *svm) /* * 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; @@ -4012,20 +4008,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 Thu Feb 27 01:25:36 2025 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: Sean Christopherson X-Patchwork-Id: 13993479 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 02D011BEF8C for ; Thu, 27 Feb 2025 01:25:52 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=209.85.216.73 ARC-Seal: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1740619555; cv=none; b=pX+7LRY8wYE/XxcXX5Ue7wjHMXRzdFQ1bCqJXLEeFmmBgYwKigsp0dxs39neu3F4ItPpz6B2FwUdQRCTavGRYpeLnkK2QOYiX/bHXdETjUyHffL3z3Tw4cNPjELjeIpJNofnG9VHNHWZaq0W1vt8t94+h+uWSQ71elIwKeC3vxs= ARC-Message-Signature: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1740619555; c=relaxed/simple; bh=8wNkxswFWdGH1HQRrKpFkvy/1TsnRMIlEykX12vyE8U=; h=Date:In-Reply-To:Mime-Version:References:Message-ID:Subject:From: To:Cc:Content-Type; b=dc2EBP4kEreHgPD6MJOLYNnK3HS8pLjy3+QX7IRvjn08f9Zlg/8ZUGTJPrEeIpZ88/iHIxbOKMGYdzZ6nasxGj8MRZ6eifKF3zGdRodGijk6bE9O1NMw7TphUXnC22A0tojvpPJ0b2ZN1vFNvmG5Ww+s1wb7ro1F+NnLt9Xzhfs= ARC-Authentication-Results: i=1; smtp.subspace.kernel.org; dmarc=pass (p=reject dis=none) header.from=google.com; spf=pass smtp.mailfrom=flex--seanjc.bounces.google.com; dkim=pass (2048-bit key) header.d=google.com header.i=@google.com header.b=25Zw1OxU; arc=none smtp.client-ip=209.85.216.73 Authentication-Results: smtp.subspace.kernel.org; dmarc=pass (p=reject dis=none) header.from=google.com Authentication-Results: smtp.subspace.kernel.org; spf=pass smtp.mailfrom=flex--seanjc.bounces.google.com Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=google.com header.i=@google.com header.b="25Zw1OxU" Received: by mail-pj1-f73.google.com with SMTP id 98e67ed59e1d1-2fea8e4a655so11412a91.0 for ; Wed, 26 Feb 2025 17:25:52 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20230601; t=1740619552; x=1741224352; darn=vger.kernel.org; h=cc:to:from:subject:message-id:references:mime-version:in-reply-to :date:reply-to:from:to:cc:subject:date:message-id:reply-to; bh=/9g8YvMgE4u3p57YSBM8Zk/O02fgzICd+Y1XSuEDMWk=; b=25Zw1OxU+5yPGgv5C+BWcIzSDzSiQgS9yLR8C9b+G/Ga9PQFfUfhQNrrKJcQ/UNCHG CWWCiZgWydKcKq1W7hXeRaJNQRchuKJCCHC7icKZjjZ5leQJhsHgpZOvmmWblFWzAxF6 C3FsPysw+Ih/M1/A/LQrzdUbl8AsdLqw4T9G3aYvuAFIVvSISixTX0Gy1Is25aCJsNLh OJsvJ9ud0W8dE918JCOAD4KmBSnBY9EGN2TysHGfFpyQqcE4RoBF2ROJzwXwsNA37Okp YQbgsLPVIi2NvFNPNBi59xjUlLcEw2NOxJcKgUMrgExmsz96xOxj+TKc6ZFY9Zs3+yIG C3dA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1740619552; x=1741224352; h=cc:to:from:subject:message-id:references:mime-version:in-reply-to :date:reply-to:x-gm-message-state:from:to:cc:subject:date:message-id :reply-to; bh=/9g8YvMgE4u3p57YSBM8Zk/O02fgzICd+Y1XSuEDMWk=; b=daWjXA2N0Mhuh3KFXNQNwXdvUYbeNBDTGSxosCJGtzX79MhrRDyyp5XToWhijgjmD4 N32M17IqBQmTkUdYqkcm3xbO9Yc02g3+KLMRnvRrqnCN5wYzD+OyyQtpePyGmn/rKHnq j/qjJ13wcGeFhlDFirtq2lOnyGjlT2wYbqvQsp/LlujWfjEVHmP8MLlS7N4X6HDmdrGK jL5Z2+Ja9Afa0RsxbNToPwyeBVtCrQDoDblxmpTlSU+wEE4/vOHVVYmkeTuNoA264CdE l4rbLS0vAum6Oc7gEsPMSCay2dW5eFd5GjFggFkSBIjwzZ9zOTIXHSwAcCWSGjc9Xehz UBPQ== X-Gm-Message-State: AOJu0Yw9wGG2MJu9XK3RhPMYyE13yYL1Md6jextELNq2qydgLcRcXP8f CHHvOZeEZ0THvo6ODLEjc7OFVKwTiNUSxgZx7FGa6jkuriDx/bMYKVFy5NXkWBVKi32DMD3Kskr kuw== X-Google-Smtp-Source: AGHT+IF65rUIuTMqRgVl+qHoagCMc0Oa679N7rInTQJ8+VGZg85VOD9YW+b2TmMSzy1ThwGbMVoYpUEMUg8= X-Received: from pjbse7.prod.google.com ([2002:a17:90b:5187:b0:2ee:4a90:3d06]) (user=seanjc job=prod-delivery.src-stubby-dispatcher) by 2002:a17:90b:2248:b0:2fa:2124:8782 with SMTP id 98e67ed59e1d1-2fe7e39f185mr8673035a91.25.1740619552385; Wed, 26 Feb 2025 17:25:52 -0800 (PST) Reply-To: Sean Christopherson Date: Wed, 26 Feb 2025 17:25:36 -0800 In-Reply-To: <20250227012541.3234589-1-seanjc@google.com> Precedence: bulk X-Mailing-List: kvm@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: Mime-Version: 1.0 References: <20250227012541.3234589-1-seanjc@google.com> X-Mailer: git-send-email 2.48.1.711.g2feabab25a-goog Message-ID: <20250227012541.3234589-6-seanjc@google.com> Subject: [PATCH v2 05/10] KVM: SVM: Require AP's "requested" SEV_FEATURES to match KVM's view From: Sean Christopherson To: Sean Christopherson , Paolo Bonzini Cc: kvm@vger.kernel.org, linux-kernel@vger.kernel.org, Naveen N Rao , Kim Phillips , Tom Lendacky , Alexey Kardashevskiy , Pankaj Gupta When handling an "AP Create" event, return an error if the "requested" SEV features for the vCPU don't exactly match KVM's view of the VM-scoped features. There is no known use case for heterogeneous SEV features across vCPUs, and while KVM can't actually enforce an exact match since the value in RAX isn't guaranteed to match what the guest shoved into the VMSA, KVM can at least avoid knowingly letting the guest run in an unsupported state. E.g. if a VM is created with DebugSwap disabled, KVM will intercept #DBs and DRs for all vCPUs, even if an AP is "created" with DebugSwap enabled in its VMSA. Note, the GHCB spec only "requires" that "AP use the same interrupt injection mechanism as the BSP", but given the disaster that is DebugSwap and SEV_FEATURES in general, it's safe to say that AMD didn't consider all possible complications with mismatching features between the BSP and APs. Opportunistically fold the check into the relevant request flavors; the "request < AP_DESTROY" check is just a bizarre way of implementing the AP_CREATE_ON_INIT => AP_CREATE fallthrough. Fixes: e366f92ea99e ("KVM: SEV: Support SEV-SNP AP Creation NAE event") Reviewed-by: Tom Lendacky Signed-off-by: Sean Christopherson Reviewed-by: Pankaj Gupta --- arch/x86/kvm/svm/sev.c | 23 ++++++++--------------- 1 file changed, 8 insertions(+), 15 deletions(-) diff --git a/arch/x86/kvm/svm/sev.c b/arch/x86/kvm/svm/sev.c index 9aad0dae3a80..bad5834ec143 100644 --- a/arch/x86/kvm/svm/sev.c +++ b/arch/x86/kvm/svm/sev.c @@ -3932,6 +3932,7 @@ void sev_snp_init_protected_guest_state(struct kvm_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; @@ -3963,26 +3964,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 Thu Feb 27 01:25:37 2025 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: Sean Christopherson X-Patchwork-Id: 13993480 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 7D64C1C701B for ; Thu, 27 Feb 2025 01:25:54 +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=1740619555; cv=none; b=UR27HXQivjvxCyuZoQ+k6qTOCZIYl9vkm+qHHISeNoDEk1+ASNfxeZo1BTOUnEiNOHJoFqHZtfYfLesLLVImM2HjPpvXgdPF++7lWKkK/pNzU2Tw6CMj72RRVMF1rk1obYfmJ1BJA+x9q9Pj4NE35BrL8w2VUFBul0QqAqML+MI= ARC-Message-Signature: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1740619555; c=relaxed/simple; bh=dDR1QpQVcSQvKqFE0KvEiZ7AYWgfuYaS5/Kd55ia8vU=; h=Date:In-Reply-To:Mime-Version:References:Message-ID:Subject:From: To:Cc:Content-Type; b=jq541uysl0qHad4pH37Ul9gNR8iipIkCOzgKh+g46nkWkdRdrxyYzk5iyVl79RZD4VaoFLnFkRnG4sv247kWymL5Ga/zgYvFn4MScJsHRFV11TjvnbJKKpgGyDY6/6i0MCBQdA48ip9phAn78db0xj7H4eyn5duCKaEMvWYTLp8= ARC-Authentication-Results: i=1; smtp.subspace.kernel.org; dmarc=pass (p=reject dis=none) header.from=google.com; spf=pass smtp.mailfrom=flex--seanjc.bounces.google.com; dkim=pass (2048-bit key) header.d=google.com header.i=@google.com header.b=CN7O9/qy; arc=none smtp.client-ip=209.85.214.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="CN7O9/qy" Received: by mail-pl1-f201.google.com with SMTP id d9443c01a7336-22119b07d52so5064965ad.1 for ; Wed, 26 Feb 2025 17:25:54 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20230601; t=1740619554; x=1741224354; darn=vger.kernel.org; h=cc:to:from:subject:message-id:references:mime-version:in-reply-to :date:reply-to:from:to:cc:subject:date:message-id:reply-to; bh=HpoG9IAubpCDT+wLYzi42QtAGv2cg0ICoGBus9dCqMw=; b=CN7O9/qysEZ8W+P+Y8JduIxwXS2sDL4Me2lMWiDi7LESsP5BCCnccbncUpeSJTYcpi AAmcjnGBP/RZG2mCGZUXAJli5V2K0JjJxClbE8h7gN+Mv2UwF8Ol0Kmr40EDP8blk3ox VQBJvLq2wetwBcfB/3E6FhMIZ89PmZv4ZQ517KqAdNQC+jy+iGDrBE/QR9XsobDFT7rg jR+uqqx/hhkgPUPwN6ORVzSwixoEFVPiX5rq7x1agydCpHnnfzaBtEgptafHe5yDhA16 8jevoINcvTB1L/WI5jekykFJU0LKVhHWqYiP2uPiZUaE3iLcZkcdJqqWYdOUSQG8mdoc IU2A== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1740619554; x=1741224354; h=cc:to:from:subject:message-id:references:mime-version:in-reply-to :date:reply-to:x-gm-message-state:from:to:cc:subject:date:message-id :reply-to; bh=HpoG9IAubpCDT+wLYzi42QtAGv2cg0ICoGBus9dCqMw=; b=oP961juFGyYEgikp9G5wOgYKlRzeem+5WExi/MfQ4U0WNdP0GRkJ2yBAQmT0lainSO /tgNd8wvfGII2G58n+YKOyOEwQOkHr1TUWgu0Oz9E/hPH8qTzOLWYfxnYOWZzScL1ljL NW4HsgFWiT+/p0Xx6dLRA4GOV2Lys2HPEP9Bo8Gasfeo+n6r8lXK/4+6GEXcp17RKHVu uj5Vj8wwmPG+wR0BZykRdNeeNi7opIw0C4VowX+AlsMcu55fxfeow0yKtdP/Vc1KkNH9 /2JCsum/D4QlkaJm9EVvtN8mW07m84L/7wPLFbfS+4sfLipFND+7z+xJzwdVrfq/CaUK RPdw== X-Gm-Message-State: AOJu0Yypq9ycaFHDYSuca6WBczGyZ56iNcfQyaFZhjlmuqcfqNe7lPY7 Ns1XzQdaRLgILi27YsNDPJcgTeaG0alUhqxzdR6kvUsp/yHtQ7vhoBVpNKQLUT525VBvTR2wdIO OqA== X-Google-Smtp-Source: AGHT+IGescKmvLpkcPFFde/D5wUCncfjV68Ld5mkBOALQrlPwQFVWlWLOcBp8zNKxty+sQjM+lwnvjXZb/A= X-Received: from pjbsw3.prod.google.com ([2002:a17:90b:2c83:b0:2fa:15aa:4d2b]) (user=seanjc job=prod-delivery.src-stubby-dispatcher) by 2002:a17:903:22c7:b0:220:cd7f:cde8 with SMTP id d9443c01a7336-22307b5b218mr150692835ad.29.1740619553863; Wed, 26 Feb 2025 17:25:53 -0800 (PST) Reply-To: Sean Christopherson Date: Wed, 26 Feb 2025 17:25:37 -0800 In-Reply-To: <20250227012541.3234589-1-seanjc@google.com> Precedence: bulk X-Mailing-List: kvm@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: Mime-Version: 1.0 References: <20250227012541.3234589-1-seanjc@google.com> X-Mailer: git-send-email 2.48.1.711.g2feabab25a-goog Message-ID: <20250227012541.3234589-7-seanjc@google.com> Subject: [PATCH v2 06/10] KVM: SVM: Simplify request+kick logic in SNP AP Creation handling From: Sean Christopherson To: Sean Christopherson , Paolo Bonzini Cc: kvm@vger.kernel.org, linux-kernel@vger.kernel.org, Naveen N Rao , Kim Phillips , Tom Lendacky , Alexey Kardashevskiy , Pankaj Gupta Drop the local "kick" variable and the unnecessary "fallthrough" logic from sev_snp_ap_creation(), and simply pivot on the request when deciding whether or not to immediate force a state update on the target vCPU. No functional change intended. Reviewed-by: Pankaj Gupta Reviewed-by: Tom Lendacky Signed-off-by: Sean Christopherson --- arch/x86/kvm/svm/sev.c | 15 +++++---------- 1 file changed, 5 insertions(+), 10 deletions(-) diff --git a/arch/x86/kvm/svm/sev.c b/arch/x86/kvm/svm/sev.c index bad5834ec143..ccac840ee7be 100644 --- a/arch/x86/kvm/svm/sev.c +++ b/arch/x86/kvm/svm/sev.c @@ -3938,7 +3938,6 @@ static int sev_snp_ap_creation(struct vcpu_svm *svm) struct vcpu_svm *target_svm; unsigned int request; unsigned int apic_id; - bool kick; int ret; request = lower_32_bits(svm->vmcb->control.exit_info_1); @@ -3956,18 +3955,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", @@ -4012,7 +4003,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 Thu Feb 27 01:25:38 2025 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: Sean Christopherson X-Patchwork-Id: 13993481 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 DD4501CDFCC for ; Thu, 27 Feb 2025 01:25:55 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=209.85.216.74 ARC-Seal: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1740619557; cv=none; b=twNGsODgofmpr6VgM+QjwQYBJirj6SCahzTDiSLHiTB1pToF1xdup//Z/rGpZDVafc23Ee6YwIKSjg3B+w79eusuJijSp6LG4+e8YtXKF0GzOryG1FdA77Hl1sufdla12BleoT3rdblDFKVpQH4uXpPBR8EQjQ5RIGUSXCVTTJY= ARC-Message-Signature: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1740619557; c=relaxed/simple; bh=ihlJ9tzG+mbom6E97CofCJ2twZFC8ydoAcNMa4ieq/g=; h=Date:In-Reply-To:Mime-Version:References:Message-ID:Subject:From: To:Cc:Content-Type; b=abIY4/97pBztDFqtum86EIa2ypF1oqJl/wtntQRVTWjprge7/bJhmHZUI/6xSjPXMbjC/PTG91AAE+anKI14gzcsTRJBRS59icjJPLst02wBB8gUlx1Zr7U4gy5R3eXgNaxx74o11I5jCxwrJl8e1QsyoVfZzEWmjLI/C1fgoMQ= ARC-Authentication-Results: i=1; smtp.subspace.kernel.org; dmarc=pass (p=reject dis=none) header.from=google.com; spf=pass smtp.mailfrom=flex--seanjc.bounces.google.com; dkim=pass (2048-bit key) header.d=google.com header.i=@google.com header.b=1y5yYQbJ; arc=none smtp.client-ip=209.85.216.74 Authentication-Results: smtp.subspace.kernel.org; dmarc=pass (p=reject dis=none) header.from=google.com Authentication-Results: smtp.subspace.kernel.org; spf=pass smtp.mailfrom=flex--seanjc.bounces.google.com Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=google.com header.i=@google.com header.b="1y5yYQbJ" Received: by mail-pj1-f74.google.com with SMTP id 98e67ed59e1d1-2fe8de1297eso925486a91.0 for ; Wed, 26 Feb 2025 17:25:55 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20230601; t=1740619555; x=1741224355; darn=vger.kernel.org; h=cc:to:from:subject:message-id:references:mime-version:in-reply-to :date:reply-to:from:to:cc:subject:date:message-id:reply-to; bh=BEh4czcyv0mwjR2KnuYAlHnHA3zyOkXJCuOnzE1/d90=; b=1y5yYQbJIZe7LrJamcdgKbiKDM1gPax2kmBZlGbVuISqYPUr5DzcJmczf/VOsqMyXw n9QpFnxmkNF0Of3cxcFb0HU3BsLjmLDtPU/f28oqXLHYiQqiA5TuLx9gu8QxWblXNlEm QZSTAIv7bgc+n/Dwj7JtTmPV205sNYqGFOechCs1o/VU1IUFb0VBFogmfHGehx64n/QO OkgV5ot0orbQ6rylpCwLHshubY5j557zgamF/iaFGlSkWVKq3uq0EKhjROU3lT+YYBnA /oWlEwsxvDiTgDvn8EvubnbDYwHfvK49layanvqeRslra155l4y1Rob6kgyhuuI4nYO0 Rwgw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1740619555; x=1741224355; h=cc:to:from:subject:message-id:references:mime-version:in-reply-to :date:reply-to:x-gm-message-state:from:to:cc:subject:date:message-id :reply-to; bh=BEh4czcyv0mwjR2KnuYAlHnHA3zyOkXJCuOnzE1/d90=; b=WbIulFX4S0Oj3tu2PjaMKEOD7iEgMogBMn8PZ72IsPLSN5gFHtBXLsctJOpoehWbET Jvj6Inn68JTrffg3A6dKrLgcc46bD7FsAd5WW+rPtd2ZbFJ3iFC/i6/NGr4Xs/oseQU/ kf/TY/GslkwUFr1k2tXAgcMvEcBqGCqPSd3QlTQJHEb0m8pCLLHl6rlLq/jckDfe1fRX JktjPcWt5k7k/3FHPP7NiKEoTqH/EwPlQMDD6HlPzFI8SQPYPEcvDRYVveasafqaXgoS fwk01fAy843rx60GhVZRDg2u4XKku5iVQRaIyTDnDJleioP4p39ERc5fz3uNnQhMTEH1 TUCA== X-Gm-Message-State: AOJu0YwJ1o3pPXzjOPJnINlRTp1T15tZlc9q7PQf17mf+rAcmEjVj2u7 PPocyDnpCcPMtjk7MpgTRzC08AdB7qZcak16xVCpg+DxuY8M5MtF5Z1gyUjsSepLFxWizjlzbTB /ZA== X-Google-Smtp-Source: AGHT+IExjvD2wlKO1qXHAmeJHBp9Socb/v6Efvhq9YmZiRdyzuZ7b7PT/K+5yF4GkgpWs3T5dFKOYmAE6Qs= X-Received: from pjbtd3.prod.google.com ([2002:a17:90b:5443:b0:2ef:d283:5089]) (user=seanjc job=prod-delivery.src-stubby-dispatcher) by 2002:a17:90b:38d2:b0:2f6:e47c:1750 with SMTP id 98e67ed59e1d1-2fea12f2a2amr2349083a91.13.1740619555492; Wed, 26 Feb 2025 17:25:55 -0800 (PST) Reply-To: Sean Christopherson Date: Wed, 26 Feb 2025 17:25:38 -0800 In-Reply-To: <20250227012541.3234589-1-seanjc@google.com> Precedence: bulk X-Mailing-List: kvm@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: Mime-Version: 1.0 References: <20250227012541.3234589-1-seanjc@google.com> X-Mailer: git-send-email 2.48.1.711.g2feabab25a-goog Message-ID: <20250227012541.3234589-8-seanjc@google.com> Subject: [PATCH v2 07/10] KVM: SVM: Use guard(mutex) to simplify SNP AP Creation error handling From: Sean Christopherson To: Sean Christopherson , Paolo Bonzini Cc: kvm@vger.kernel.org, linux-kernel@vger.kernel.org, Naveen N Rao , Kim Phillips , Tom Lendacky , Alexey Kardashevskiy , Pankaj Gupta Use guard(mutex) in sev_snp_ap_creation() and modify the error paths to return directly instead of jumping to a common exit point. No functional change intended. Reviewed-by: Tom Lendacky Signed-off-by: Sean Christopherson Reviewed-by: Pankaj Gupta --- arch/x86/kvm/svm/sev.c | 22 ++++++---------------- 1 file changed, 6 insertions(+), 16 deletions(-) diff --git a/arch/x86/kvm/svm/sev.c b/arch/x86/kvm/svm/sev.c index ccac840ee7be..dd9511a2254b 100644 --- a/arch/x86/kvm/svm/sev.c +++ b/arch/x86/kvm/svm/sev.c @@ -3938,7 +3938,6 @@ static int sev_snp_ap_creation(struct vcpu_svm *svm) struct vcpu_svm *target_svm; unsigned int request; unsigned int apic_id; - int ret; request = lower_32_bits(svm->vmcb->control.exit_info_1); apic_id = upper_32_bits(svm->vmcb->control.exit_info_1); @@ -3951,11 +3950,9 @@ static int sev_snp_ap_creation(struct vcpu_svm *svm) return -EINVAL; } - 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: @@ -3963,15 +3960,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; } /* @@ -3985,8 +3980,7 @@ static int sev_snp_ap_creation(struct vcpu_svm *svm) vcpu_unimpl(vcpu, "vmgexit: AP VMSA address [%llx] from guest is unsafe as it is 2M aligned\n", svm->vmcb->control.exit_info_2); - ret = -EINVAL; - goto out; + return -EINVAL; } target_svm->sev_es.snp_vmsa_gpa = svm->vmcb->control.exit_info_2; @@ -3997,8 +3991,7 @@ static int sev_snp_ap_creation(struct vcpu_svm *svm) default: vcpu_unimpl(vcpu, "vmgexit: invalid AP creation request [%#x] from guest\n", request); - ret = -EINVAL; - goto out; + return -EINVAL; } target_svm->sev_es.snp_ap_waiting_for_reset = true; @@ -4012,10 +4005,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 Thu Feb 27 01:25:39 2025 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: Sean Christopherson X-Patchwork-Id: 13993482 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 CE1D622DF81 for ; Thu, 27 Feb 2025 01:25:57 +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=1740619559; cv=none; b=OqugKevDbZW0ceONdR8OaAn4H2W4gJ8K5wgN2sXelVBoQjSa+iYGCEfX2l8o/63DPocgTRZ4I1fYCwhiaDDO6ttlFuiPHRC82oYhPJH94y3l/pMq70plBlq87f72M09jC8HQy2kei14rg4fJ/Kfqf5IWZyB6xNmjAhBAGNlGr1o= ARC-Message-Signature: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1740619559; c=relaxed/simple; bh=3rMdxdgx2qWe5YUgeEwNff8fTKobVmh249Xk/BEEAbw=; h=Date:In-Reply-To:Mime-Version:References:Message-ID:Subject:From: To:Cc:Content-Type; b=V/p3CGKVvUxTeBhEh7hcYNaA+rNI2d7l3fiwgLj4OapHPMAz+1E4nd2oBnKK7ffLdoX7kB3RIqKDqO+h6g5B5zZrMyKs9Yeb5tWTw+YSPd1O7m+gYLWShodEAJFQXZGPFzvNVWsj4cBMfckIjB2HCU9O3OP/ovMSSZT0Kb0gYQg= ARC-Authentication-Results: i=1; smtp.subspace.kernel.org; dmarc=pass (p=reject dis=none) header.from=google.com; spf=pass smtp.mailfrom=flex--seanjc.bounces.google.com; dkim=pass (2048-bit key) header.d=google.com header.i=@google.com header.b=27shFyFa; arc=none smtp.client-ip=209.85.214.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="27shFyFa" Received: by mail-pl1-f202.google.com with SMTP id d9443c01a7336-2234c09241fso10834255ad.2 for ; Wed, 26 Feb 2025 17:25:57 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20230601; t=1740619557; x=1741224357; darn=vger.kernel.org; h=cc:to:from:subject:message-id:references:mime-version:in-reply-to :date:reply-to:from:to:cc:subject:date:message-id:reply-to; bh=lmdAwPEyCZdB0cvoeTHRqa3iDsz832lsztWM5iTizzQ=; b=27shFyFa7us91YMSdCLNQFswgRfPh3a60qe4ZSGaUmrTexGUEHhGJq9E7wpAcy0A3X CWumEerMK5luUsBakwMWHBMPujn4G1dFkx47+CO8YM0keftCapeTcH5BfeQyEwLg54Qs RvsF1mAC1xFrU5YNtOTkRoNDTVbc9bx81Xc123nvzwvAwzuikUqBgWYNMrRF8muYqE3e d67MMFx4zJkbTmibnG40wwRlPYEqM6smB5aaaIJctBJon8vS9qAcfiSA+esPa9ULN+86 f4GdKWzXV4aTA7YH7PvIP0xLgaUmWiJnVjV9coFVdA5WfUajXLBPa0LD1rZbk8k8e1VM YpLw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1740619557; x=1741224357; h=cc:to:from:subject:message-id:references:mime-version:in-reply-to :date:reply-to:x-gm-message-state:from:to:cc:subject:date:message-id :reply-to; bh=lmdAwPEyCZdB0cvoeTHRqa3iDsz832lsztWM5iTizzQ=; b=D2DDmkpNMgtAGrfQFxX0pNG2ggBluldydhXM/KT2KuCwSuLMIVsVehPm/z/0U8K5k2 b+vyHvLgDks3j1ezEiGQsQW2EtSOr9cp4/ScpU92sSW1TLFiatQSEs4da/+xi5wC1fub SSYYyrbXGLMb4Kkjz3+Hm7uvpeuqBTCOhoSjEeHsyEyyyjbc/KwIAqxbopXY78kzqKeR 35Ev9vd//xzA6bXSHADwnVE7c/DWu+wwpv2omUBJCXhRb7ErtgNHwx6efEgZx0qj3mL+ t66dQpRDlS6iFxcEjVFIkd8Fzr/OR2ObzCtklCLA5/CXJmf9/afPs2pHjdLvltxNXJkx hwyA== X-Gm-Message-State: AOJu0YxrEtmaz+TTdz0qwr9A6PwThK0fTKBbtvXgaCc2Xi8SVnMv9Mdo wlzbMwpgF1qbUMM6x0s8ZChowzwoi9lvDuQcFhWpn1Up6mO97ep4DYm/AIah9txi4y+dAt/CpGT ZYA== X-Google-Smtp-Source: AGHT+IGyW+IanDv2gn10X8mgRJgrQ6dxChAv+7NcHxpQspV9qJhboJEE29I20MwBycuSfUIjaysnSToTWm4= X-Received: from pfbik10.prod.google.com ([2002:a05:6a00:8d0a:b0:730:4672:64ac]) (user=seanjc job=prod-delivery.src-stubby-dispatcher) by 2002:a05:6a00:1709:b0:732:2967:400 with SMTP id d2e1a72fcca58-7347910977emr15073690b3a.12.1740619557217; Wed, 26 Feb 2025 17:25:57 -0800 (PST) Reply-To: Sean Christopherson Date: Wed, 26 Feb 2025 17:25:39 -0800 In-Reply-To: <20250227012541.3234589-1-seanjc@google.com> Precedence: bulk X-Mailing-List: kvm@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: Mime-Version: 1.0 References: <20250227012541.3234589-1-seanjc@google.com> X-Mailer: git-send-email 2.48.1.711.g2feabab25a-goog Message-ID: <20250227012541.3234589-9-seanjc@google.com> Subject: [PATCH v2 08/10] KVM: SVM: Mark VMCB dirty before processing incoming snp_vmsa_gpa From: Sean Christopherson To: Sean Christopherson , Paolo Bonzini Cc: kvm@vger.kernel.org, linux-kernel@vger.kernel.org, Naveen N Rao , Kim Phillips , Tom Lendacky , Alexey Kardashevskiy , Pankaj Gupta Mark the VMCB dirty, i.e. zero control.clean, prior to handling the new VMSA. Nothing in the VALID_PAGE() case touches control.clean, and isolating the VALID_PAGE() code will allow simplifying the overall logic. Note, the VMCB probably doesn't need to be marked dirty when the VMSA is invalid, as KVM will disallow running the vCPU in such a state. But it also doesn't hurt anything. Reviewed-by: Tom Lendacky Signed-off-by: Sean Christopherson --- arch/x86/kvm/svm/sev.c | 12 ++++++------ 1 file changed, 6 insertions(+), 6 deletions(-) diff --git a/arch/x86/kvm/svm/sev.c b/arch/x86/kvm/svm/sev.c index dd9511a2254b..c74cc64ceb81 100644 --- a/arch/x86/kvm/svm/sev.c +++ b/arch/x86/kvm/svm/sev.c @@ -3850,6 +3850,12 @@ static int __sev_snp_update_protected_guest_state(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; @@ -3895,12 +3901,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 Thu Feb 27 01:25:40 2025 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: Sean Christopherson X-Patchwork-Id: 13993483 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 6649F22E3E1 for ; Thu, 27 Feb 2025 01:25:59 +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=1740619560; cv=none; b=ppGbuaoXpknNlUZcEHEoDYx1MfM8pVRnsLLGOTUTrQK49zqEx+Eg2bQm7DBp+s3F1RR4A8fB55l8fHoqUDPrJhpXGZnXVQx9Gc3j99R1WBaiPrV/OvRhhPe1QzuPz5XGPrvb7cgyELXGUy4v4h7R+vxMWg/jLvhYzDXoDftX4KE= ARC-Message-Signature: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1740619560; c=relaxed/simple; bh=SlIP7vUVEAl3Nff6A3KsmF5s6lnEtycCZy5mDlywOrM=; h=Date:In-Reply-To:Mime-Version:References:Message-ID:Subject:From: To:Cc:Content-Type; b=iPgpd1QWTlACwMJ1Hwwy3lFkrvDcn1e7UhcWNh+ZQTKeYzkAJYFAMMs6bqXRsOIsdVE+zU60jEy5i+0AaeNbVEw9Wg/ZXCAoc6HMMkPnfPJvwCATWpL2vpmp0sa0qBCb/ueoO7PDzlLr8IWMfTo2K6P/FFGhTbuvB0i7xeYW/LI= ARC-Authentication-Results: i=1; smtp.subspace.kernel.org; dmarc=pass (p=reject dis=none) header.from=google.com; spf=pass smtp.mailfrom=flex--seanjc.bounces.google.com; dkim=pass (2048-bit key) header.d=google.com header.i=@google.com header.b=gISGwIj3; arc=none smtp.client-ip=209.85.216.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="gISGwIj3" Received: by mail-pj1-f74.google.com with SMTP id 98e67ed59e1d1-2fe8fdfdd94so1007509a91.0 for ; Wed, 26 Feb 2025 17:25:59 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20230601; t=1740619559; x=1741224359; darn=vger.kernel.org; h=cc:to:from:subject:message-id:references:mime-version:in-reply-to :date:reply-to:from:to:cc:subject:date:message-id:reply-to; bh=IOWwEu0l/k3HhYntL/yg0gERPToOEmSlz8zTPMBWJgM=; b=gISGwIj3vhxdRYYF83elUi4DoTM6Y4ggEZPZtUJhMf4xfHehe3LNKkSQtpWVhpBBF4 0N/86YkqRAaoW/xtpjwAhVDro6pDvS8WGJ+ubOAbeciuhkTBFtTqIyuHcH6S+CfsmbC4 ahO1TJSJ+Aw2WHtsCijR4R5m7PlQI8WNIIrfrSIKjfhfuq40jypKHVSPwz5VHNIWG8s1 jpBIKMx1YrO97yQrxZwRcDRT2suMMfJ5xxRlxPZ5T6i8TLmH2BBXqx4tAvSgN38arWf/ ZdM9kJMEM77TBdtkjFNJXPpkozBAMYYAlrPBUV7rm3GGX6uEAftRyO6sx8O5veYVTgdg 1U2Q== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1740619559; x=1741224359; h=cc:to:from:subject:message-id:references:mime-version:in-reply-to :date:reply-to:x-gm-message-state:from:to:cc:subject:date:message-id :reply-to; bh=IOWwEu0l/k3HhYntL/yg0gERPToOEmSlz8zTPMBWJgM=; b=cUvScjfXXXZ9bQBpbKS+CCJNGTu8uJ1ywH6aWc9PnGPvR+S/Bwbv8pYYepvSyySCmu JdRcBDql8VfP1K9nTc9rsiTPl9oFZ4bDOZ781S1whC+aMW892S6hN4vkBRDeR8AW94xk vinQwPahv4s4IoKYUUpIlXx+3ilbwbPTnEqbHOQOhiAfMipPK99z7nPknYdlr4gQ9XYI 173mBHgzSzXjD7ia2u5/mYLfo0qC+usxydYTna5xCe3C8CW1lTe67GAVDLx/gH2nQWpp X9qP6gBxjEoYA/gNVuW8oAkDxEBHCzVspKUPuVV7L3Oo6pnZcdY90JLYF2h17RQi0116 XlAw== X-Gm-Message-State: AOJu0YxWcs+XrjhY/vX06KugTi8OUaKHjToUbpwMcXb/NAPsYeaIgQje DCoM4l+nGYg4skzff3NqTaJ4c8MvOVYCWYvmj5D01yqCClQWmPD8A7C/b5VXDAbJpguqMrW/3wD Dmw== X-Google-Smtp-Source: AGHT+IGFu8FDn0du2s+v5ekzGMy8fn8oWBPrPcbohW0kjuPN3LZYNucs2Vyp5314eaCBsaigs6BDRwkMzfU= X-Received: from pja5.prod.google.com ([2002:a17:90b:5485:b0:2fa:1fac:2695]) (user=seanjc job=prod-delivery.src-stubby-dispatcher) by 2002:a17:90b:2502:b0:2fe:9783:afd3 with SMTP id 98e67ed59e1d1-2fe9783b117mr3818666a91.2.1740619558983; Wed, 26 Feb 2025 17:25:58 -0800 (PST) Reply-To: Sean Christopherson Date: Wed, 26 Feb 2025 17:25:40 -0800 In-Reply-To: <20250227012541.3234589-1-seanjc@google.com> Precedence: bulk X-Mailing-List: kvm@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: Mime-Version: 1.0 References: <20250227012541.3234589-1-seanjc@google.com> X-Mailer: git-send-email 2.48.1.711.g2feabab25a-goog Message-ID: <20250227012541.3234589-10-seanjc@google.com> Subject: [PATCH v2 09/10] KVM: SVM: Use guard(mutex) to simplify SNP vCPU state updates From: Sean Christopherson To: Sean Christopherson , Paolo Bonzini Cc: kvm@vger.kernel.org, linux-kernel@vger.kernel.org, Naveen N Rao , Kim Phillips , Tom Lendacky , Alexey Kardashevskiy , Pankaj Gupta Use guard(mutex) in sev_snp_init_protected_guest_state() and pull in its lock-protected inner helper. Without an unlock trampoline (and even with one), there is no real need for an inner helper. Eliminating the helper also avoids having to fixup the open coded "lockdep" WARN_ON(). Opportunistically drop the error message if KVM can't obtain the pfn for the new target VMSA. The error message provides zero information that can't be gleaned from the fact that the vCPU is stuck. Reviewed-by: Tom Lendacky Signed-off-by: Sean Christopherson --- arch/x86/kvm/svm/sev.c | 122 ++++++++++++++++++----------------------- 1 file changed, 53 insertions(+), 69 deletions(-) diff --git a/arch/x86/kvm/svm/sev.c b/arch/x86/kvm/svm/sev.c index c74cc64ceb81..3f85bd1cac37 100644 --- a/arch/x86/kvm/svm/sev.c +++ b/arch/x86/kvm/svm/sev.c @@ -3837,11 +3837,26 @@ static int snp_begin_psc(struct vcpu_svm *svm, 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; @@ -3856,78 +3871,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 Thu Feb 27 01:25:41 2025 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: Sean Christopherson X-Patchwork-Id: 13993484 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 6A1FB22F38E for ; Thu, 27 Feb 2025 01:26:01 +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=1740619562; cv=none; b=O2FXJSAVzjSYfKDb+H6rbd62JiBGCmGzzIfVnT4md0yhkJxxDWESsmXJq1xwWP7eh4R5F1vwYrfCbIo92HjS+BbcmUddVqNb1toIPAwkvmfE9sjeFasEcY4X0oU7O7wagI0gEM7M9u/iOLnkPwfFMv2pqTrqzAX5PCrjg6fXSMY= ARC-Message-Signature: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1740619562; c=relaxed/simple; bh=k1zCPxyx7QffMCA40qqfLOdgRpM8zvCQvs8fM/N6VGQ=; h=Date:In-Reply-To:Mime-Version:References:Message-ID:Subject:From: To:Cc:Content-Type; b=IErKIGOzQT2UGMqdtkImZhGXQYn+QmML/5bElyt5J2NAA9xIpXIqFEGTOiGSqeD7oc6FSJ0u7NVHASi/ZkWIkT/3Zv7lyMkQR2L+ZTQYGq0wFpkKo7nU/TNhnpjOVsXEcTDL4o7q/7u0v3+4EcYwhZVaJ6GNPsyRTiUBnFihHY8= ARC-Authentication-Results: i=1; smtp.subspace.kernel.org; dmarc=pass (p=reject dis=none) header.from=google.com; spf=pass smtp.mailfrom=flex--seanjc.bounces.google.com; dkim=pass (2048-bit key) header.d=google.com header.i=@google.com header.b=D7P1QwZY; 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="D7P1QwZY" Received: by mail-pj1-f74.google.com with SMTP id 98e67ed59e1d1-2fe86c01f5cso943400a91.1 for ; Wed, 26 Feb 2025 17:26:01 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20230601; t=1740619561; x=1741224361; darn=vger.kernel.org; h=cc:to:from:subject:message-id:references:mime-version:in-reply-to :date:reply-to:from:to:cc:subject:date:message-id:reply-to; bh=hRttPNtyo2FhaDhgSxaXYjlTdMIPvE2NOxByRas6vdI=; b=D7P1QwZYcj6gVWhWAM6yplvh3rCPt1r3fDyautquYJ3arM3qXWHf/H9HRvO3IiDrEJ V1WDxILmSnHIOZw1BheuHelMl04pgSYFG7szAcZDIYirzjWvfrdU2K1Bpf750ZQ+8Tbv qBm3poVPnxlvBVsAv4lB0QU3FNbeOPVi90oPbaqzZ467FJm3C81dZqGQuYgrTt0I8SGQ NSF2wC3PD2B7+/bESG8SHZMiF3qD3pcJZM09dYhF6TBz70prT53wBOL9kASPPAuVNE4b dDYSNM247CmtrCF8opYpMpQZRPy9uzzaqGqpKlgx6Ucsjov6SWw3aGnuw3WAolYI1jzS nx7w== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1740619561; x=1741224361; h=cc:to:from:subject:message-id:references:mime-version:in-reply-to :date:reply-to:x-gm-message-state:from:to:cc:subject:date:message-id :reply-to; bh=hRttPNtyo2FhaDhgSxaXYjlTdMIPvE2NOxByRas6vdI=; b=a4s9ehVWymieflRAO2JtNjlGq5VRp6ZOQmWi1tDzb87GCZlYQs12vnz/WfoC5OPHRX w2MnnzqqNz9tMB7iQAgT1rgKk+YyEXW9siRlQvky+GIiNIN0gjj22S2Z1iF6c/YZXfpl HVd0ZE1RUCvQFbPw+p8dzEHh74roP71TpNBVii7R6bRhHWO68rBYJQdM+iXuwxDxbX2L +dGC8jCLel4Y3we1XcDxUTwtDdkqDkZWfoZseaWUVGjp4IH07gfT3KXJ49yjlGllKvxZ xe/Kb18oJ1asIgKvnC+NGi6/0yczVL1bk1J68MJyi5maGxWGGAd8LyGMVEpX0daUOAWZ 33gg== X-Gm-Message-State: AOJu0Yz76Vl1JRn0i/I27NnT6lD6S0HUKCoH0O3OkRNdT2FzOPe58Mmo ZfpMflKZKq1nLR76VDcYCEOKJEJa6BDScmOG4zuZFdrGWntOXyzT1JgqaLFBVm/cxFW0QsekCjg J9A== X-Google-Smtp-Source: AGHT+IG8HbiE4dqqw9uPDJvINPCaXcP21RIIbdqv90GTh7egSO6SkFb9wzrb+echyxtbBa5rvPfSgawyvUM= X-Received: from pfbfa11.prod.google.com ([2002:a05:6a00:2d0b:b0:730:7e2d:df66]) (user=seanjc job=prod-delivery.src-stubby-dispatcher) by 2002:a05:6a20:4310:b0:1ee:d92d:f6f3 with SMTP id adf61e73a8af0-1f0fc998e0fmr15792313637.37.1740619560644; Wed, 26 Feb 2025 17:26:00 -0800 (PST) Reply-To: Sean Christopherson Date: Wed, 26 Feb 2025 17:25:41 -0800 In-Reply-To: <20250227012541.3234589-1-seanjc@google.com> Precedence: bulk X-Mailing-List: kvm@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: Mime-Version: 1.0 References: <20250227012541.3234589-1-seanjc@google.com> X-Mailer: git-send-email 2.48.1.711.g2feabab25a-goog Message-ID: <20250227012541.3234589-11-seanjc@google.com> Subject: [PATCH v2 10/10] KVM: SVM: Invalidate "next" SNP VMSA GPA even on failure From: Sean Christopherson To: Sean Christopherson , Paolo Bonzini Cc: kvm@vger.kernel.org, linux-kernel@vger.kernel.org, Naveen N Rao , Kim Phillips , Tom Lendacky , Alexey Kardashevskiy , Pankaj Gupta When processing an SNP AP Creation event, invalidate the "next" VMSA GPA even if acquiring the page/pfn for the new VMSA fails. In practice, the next GPA will never be used regardless of whether or not its invalidated, as the entire flow is guarded by snp_ap_waiting_for_reset, and said guard and snp_vmsa_gpa are always written as a pair. But that's really hard to see in the code. Reviewed-by: Tom Lendacky Signed-off-by: Sean Christopherson --- arch/x86/kvm/svm/sev.c | 3 +-- 1 file changed, 1 insertion(+), 2 deletions(-) diff --git a/arch/x86/kvm/svm/sev.c b/arch/x86/kvm/svm/sev.c index 3f85bd1cac37..de153a19fa6c 100644 --- a/arch/x86/kvm/svm/sev.c +++ b/arch/x86/kvm/svm/sev.c @@ -3875,6 +3875,7 @@ void sev_snp_init_protected_guest_state(struct kvm_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) @@ -3904,8 +3905,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