From nobody Sun Feb 8 12:57:57 2026 Received: from us-smtp-delivery-124.mimecast.com (us-smtp-delivery-124.mimecast.com [170.10.129.124]) (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 2325A5A102 for ; Mon, 18 Mar 2024 22:10:08 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=170.10.129.124 ARC-Seal: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1710799810; cv=none; b=mLuG597vmkAeazts66n42coAFKdjl+N6VYqPVgRB+dGcxrLQl8KDj45lpthfxWW/Pe+VkmR2WElqWBfYCDdunBXgxQ+uVTHL0JwkkmnSdVAtiLQcLBKfsER6D5sSQDAiGvhnZZNNnvm5Xq2DChYCqKTBLAY7ljujh56Gmn6v9/s= ARC-Message-Signature: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1710799810; c=relaxed/simple; bh=pUDyVdDIhWF+AxxFzQPbcKbrYmlXF2FtVHpKnNJHuHA=; h=From:To:Cc:Subject:Date:Message-ID:In-Reply-To:References: MIME-Version:Content-Type; b=MHB/5fsgd2VFOP9CVVk87pkzOpic6vFMrFobcAusuZEY+mU3qevj9N1Xu+BU8ul6YVxYOoFLMWM9voWxKNNOByI9dhM+sQJ9dICOVcpdUthSsJYVtLfjImZVHZfhJbjRfiT16cfX+L+3elJumli8VwN5ITY5X5juYU7V9FUKmPI= ARC-Authentication-Results: i=1; smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=redhat.com; spf=pass smtp.mailfrom=redhat.com; dkim=pass (1024-bit key) header.d=redhat.com header.i=@redhat.com header.b=TJ+druJ4; arc=none smtp.client-ip=170.10.129.124 Authentication-Results: smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=redhat.com Authentication-Results: smtp.subspace.kernel.org; spf=pass smtp.mailfrom=redhat.com Authentication-Results: smtp.subspace.kernel.org; dkim=pass (1024-bit key) header.d=redhat.com header.i=@redhat.com header.b="TJ+druJ4" DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com; s=mimecast20190719; t=1710799808; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc:mime-version:mime-version:content-type:content-type: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references; bh=jIk57Yw9TtyXvEW7JA55T78f0IPlsLYi8PGmRhytf78=; b=TJ+druJ4T2bRtEBGJr6B2mGfJuWYB8ZEpdfoODMc8GJ1GGnG648inWL2xPdGsMKkqMfGjT BTwi4qxyOeNlVd8V5gsbvt9O8w8NzK7wWvty9UVxmX1EFLM16iEqrrzCYyvSOrDv0caX3r KFciJCAShsIf+DYlgIzcl+1/wQQ5u9Y= Received: from mimecast-mx02.redhat.com (mimecast-mx02.redhat.com [66.187.233.88]) by relay.mimecast.com with ESMTP with STARTTLS (version=TLSv1.3, cipher=TLS_AES_256_GCM_SHA384) id us-mta-609-3C53FmV2MF685amG0XGf_A-1; Mon, 18 Mar 2024 18:10:04 -0400 X-MC-Unique: 3C53FmV2MF685amG0XGf_A-1 Received: from smtp.corp.redhat.com (int-mx09.intmail.prod.int.rdu2.redhat.com [10.11.54.9]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (2048 bits) server-digest SHA256) (No client certificate requested) by mimecast-mx02.redhat.com (Postfix) with ESMTPS id C500C185A781; Mon, 18 Mar 2024 22:10:03 +0000 (UTC) Received: from virtlab701.virt.lab.eng.bos.redhat.com (virtlab701.virt.lab.eng.bos.redhat.com [10.19.152.228]) by smtp.corp.redhat.com (Postfix) with ESMTP id A31DD492BD6; Mon, 18 Mar 2024 22:10:03 +0000 (UTC) From: Paolo Bonzini To: linux-kernel@vger.kernel.org, kvm@vger.kernel.org Cc: seanjc@google.com, Tom Lendacky Subject: [PATCH 1/7] KVM: SVM: Set sev->asid in sev_asid_new() instead of overloading the return Date: Mon, 18 Mar 2024 18:09:56 -0400 Message-ID: <20240318221002.2712738-2-pbonzini@redhat.com> In-Reply-To: <20240318221002.2712738-1-pbonzini@redhat.com> References: <20240318221002.2712738-1-pbonzini@redhat.com> Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 Content-Transfer-Encoding: quoted-printable X-Scanned-By: MIMEDefang 3.4.1 on 10.11.54.9 Content-Type: text/plain; charset="utf-8" From: Sean Christopherson Explicitly set sev->asid in sev_asid_new() when a new ASID is successfully allocated, and return '0' to indicate success instead of overloading the return value to multiplex the ASID with error codes. There is exactly one caller of sev_asid_new(), and sev_asid_free() already consumes sev->asid, i.e. returning the ASID isn't necessary for flexibility, nor does it provide symmetry between related APIs. Reviewed-by: Tom Lendacky Link: https://lore.kernel.org/r/20240131235609.4161407-2-seanjc@google.com Signed-off-by: Sean Christopherson --- arch/x86/kvm/svm/sev.c | 10 +++++----- 1 file changed, 5 insertions(+), 5 deletions(-) diff --git a/arch/x86/kvm/svm/sev.c b/arch/x86/kvm/svm/sev.c index f760106c31f8..7c000088bca6 100644 --- a/arch/x86/kvm/svm/sev.c +++ b/arch/x86/kvm/svm/sev.c @@ -179,7 +179,8 @@ static int sev_asid_new(struct kvm_sev_info *sev) =20 mutex_unlock(&sev_bitmap_lock); =20 - return asid; + sev->asid =3D asid; + return 0; e_uncharge: sev_misc_cg_uncharge(sev); put_misc_cg(sev->misc_cg); @@ -246,7 +247,7 @@ static void sev_unbind_asid(struct kvm *kvm, unsigned i= nt handle) static int sev_guest_init(struct kvm *kvm, struct kvm_sev_cmd *argp) { struct kvm_sev_info *sev =3D &to_kvm_svm(kvm)->sev_info; - int asid, ret; + int ret; =20 if (kvm->created_vcpus) return -EINVAL; @@ -257,10 +258,9 @@ static int sev_guest_init(struct kvm *kvm, struct kvm_= sev_cmd *argp) =20 sev->active =3D true; sev->es_active =3D argp->id =3D=3D KVM_SEV_ES_INIT; - asid =3D sev_asid_new(sev); - if (asid < 0) + ret =3D sev_asid_new(sev); + if (ret) goto e_no_asid; - sev->asid =3D asid; =20 ret =3D sev_platform_init(&argp->error); if (ret) --=20 2.43.0 From nobody Sun Feb 8 12:57:57 2026 Received: from us-smtp-delivery-124.mimecast.com (us-smtp-delivery-124.mimecast.com [170.10.129.124]) (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 231F45A0FB for ; Mon, 18 Mar 2024 22:10:08 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=170.10.129.124 ARC-Seal: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1710799810; cv=none; b=YxhvBM+iwVfiuRmzAxRMUGpeMzD5lDJW7BDnQ6LXBcxz/BL5Zy7MbQzvXZwNlDzrLZXNxZSzBfa+40ZspXGoSHLNibGu6DOxjjCs/55IKC5n//hJHNFwTZHlOHbhzc74StrXXixTdsMRdYXty2ZcVweBdWqloRUojYT06Anjg8k= ARC-Message-Signature: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1710799810; c=relaxed/simple; bh=8OmIJ7TG5EgMLMe89eEfIqHHCE4J+CiAn1kyL9d3cRo=; h=From:To:Cc:Subject:Date:Message-ID:In-Reply-To:References: MIME-Version:Content-Type; b=uCm7WssNPqshc8iONwCeHfKH6tIot64CGI7+pUPiMUAvDv1d+qKR4HbupLc8BQxAe+ZcrM06TMbKtn+JvszWfCjbSkwa9Ovl2He0fH11ly48+bGPDA5gupvLmZF15SxTT9RyKBttxnua+LY8CpOn6Sef7d4470KCdd2tKioN5LM= ARC-Authentication-Results: i=1; smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=redhat.com; spf=pass smtp.mailfrom=redhat.com; dkim=pass (1024-bit key) header.d=redhat.com header.i=@redhat.com header.b=fuyHW1Cd; arc=none smtp.client-ip=170.10.129.124 Authentication-Results: smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=redhat.com Authentication-Results: smtp.subspace.kernel.org; spf=pass smtp.mailfrom=redhat.com Authentication-Results: smtp.subspace.kernel.org; dkim=pass (1024-bit key) header.d=redhat.com header.i=@redhat.com header.b="fuyHW1Cd" DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com; s=mimecast20190719; t=1710799808; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc:mime-version:mime-version:content-type:content-type: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references; bh=9aIqm5wZzKo1WTdEYKyjDcm8eFDA+KlO2RXyMnu6dq4=; b=fuyHW1CdV6lAXx7Ke/EcGZGT5nfenhSYrJm/1MGMDTo3ywzLQSwIovgzAs+mxdeQ6NF/zE dUdFneM1werEHwiV/0kruuvbuMO80csiSIm08WaYn8k3gE9KIBSwbtZq7B89UW4VtyxABR xn1J6LC8N+q+byFwQhI+J+nSmGHrges= Received: from mimecast-mx02.redhat.com (mimecast-mx02.redhat.com [66.187.233.88]) by relay.mimecast.com with ESMTP with STARTTLS (version=TLSv1.3, cipher=TLS_AES_256_GCM_SHA384) id us-mta-609-pHmGvFWAOfOLRzoj8U5bjA-1; Mon, 18 Mar 2024 18:10:04 -0400 X-MC-Unique: pHmGvFWAOfOLRzoj8U5bjA-1 Received: from smtp.corp.redhat.com (int-mx09.intmail.prod.int.rdu2.redhat.com [10.11.54.9]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (2048 bits) server-digest SHA256) (No client certificate requested) by mimecast-mx02.redhat.com (Postfix) with ESMTPS id EEBB58007A2; Mon, 18 Mar 2024 22:10:03 +0000 (UTC) Received: from virtlab701.virt.lab.eng.bos.redhat.com (virtlab701.virt.lab.eng.bos.redhat.com [10.19.152.228]) by smtp.corp.redhat.com (Postfix) with ESMTP id CDCFC492BC8; Mon, 18 Mar 2024 22:10:03 +0000 (UTC) From: Paolo Bonzini To: linux-kernel@vger.kernel.org, kvm@vger.kernel.org Cc: seanjc@google.com, Tom Lendacky Subject: [PATCH 2/7] KVM: SVM: Use unsigned integers when dealing with ASIDs Date: Mon, 18 Mar 2024 18:09:57 -0400 Message-ID: <20240318221002.2712738-3-pbonzini@redhat.com> In-Reply-To: <20240318221002.2712738-1-pbonzini@redhat.com> References: <20240318221002.2712738-1-pbonzini@redhat.com> Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 Content-Transfer-Encoding: quoted-printable X-Scanned-By: MIMEDefang 3.4.1 on 10.11.54.9 Content-Type: text/plain; charset="utf-8" From: Sean Christopherson Convert all local ASID variables and parameters throughout the SEV code from signed integers to unsigned integers. As ASIDs are fundamentally unsigned values, and the global min/max variables are appropriately unsigned integers, too. Functionally, this is a glorified nop as KVM guarantees min_sev_asid is non-zero, and no CPU supports -1u as the _only_ asid, i.e. the signed vs. unsigned goof won't cause problems in practice. Opportunistically use sev_get_asid() in sev_flush_encrypted_page() instead of open coding an equivalent. Reviewed-by: Tom Lendacky Link: https://lore.kernel.org/r/20240131235609.4161407-3-seanjc@google.com Signed-off-by: Sean Christopherson --- arch/x86/kvm/svm/sev.c | 18 ++++++++++-------- arch/x86/kvm/trace.h | 10 +++++----- 2 files changed, 15 insertions(+), 13 deletions(-) diff --git a/arch/x86/kvm/svm/sev.c b/arch/x86/kvm/svm/sev.c index 7c000088bca6..eeef43c795d8 100644 --- a/arch/x86/kvm/svm/sev.c +++ b/arch/x86/kvm/svm/sev.c @@ -84,9 +84,10 @@ struct enc_region { }; =20 /* Called with the sev_bitmap_lock held, or on shutdown */ -static int sev_flush_asids(int min_asid, int max_asid) +static int sev_flush_asids(unsigned int min_asid, unsigned int max_asid) { - int ret, asid, error =3D 0; + int ret, error =3D 0; + unsigned int asid; =20 /* Check if there are any ASIDs to reclaim before performing a flush */ asid =3D find_next_bit(sev_reclaim_asid_bitmap, nr_asids, min_asid); @@ -116,7 +117,7 @@ static inline bool is_mirroring_enc_context(struct kvm = *kvm) } =20 /* Must be called with the sev_bitmap_lock held */ -static bool __sev_recycle_asids(int min_asid, int max_asid) +static bool __sev_recycle_asids(unsigned int min_asid, unsigned int max_as= id) { if (sev_flush_asids(min_asid, max_asid)) return false; @@ -143,8 +144,9 @@ static void sev_misc_cg_uncharge(struct kvm_sev_info *s= ev) =20 static int sev_asid_new(struct kvm_sev_info *sev) { - int asid, min_asid, max_asid, ret; + unsigned int asid, min_asid, max_asid; bool retry =3D true; + int ret; =20 WARN_ON(sev->misc_cg); sev->misc_cg =3D get_current_misc_cg(); @@ -188,7 +190,7 @@ static int sev_asid_new(struct kvm_sev_info *sev) return ret; } =20 -static int sev_get_asid(struct kvm *kvm) +static unsigned int sev_get_asid(struct kvm *kvm) { struct kvm_sev_info *sev =3D &to_kvm_svm(kvm)->sev_info; =20 @@ -284,8 +286,8 @@ static int sev_guest_init(struct kvm *kvm, struct kvm_s= ev_cmd *argp) =20 static int sev_bind_asid(struct kvm *kvm, unsigned int handle, int *error) { + unsigned int asid =3D sev_get_asid(kvm); struct sev_data_activate activate; - int asid =3D sev_get_asid(kvm); int ret; =20 /* activate ASID on the given handle */ @@ -2312,7 +2314,7 @@ int sev_cpu_init(struct svm_cpu_data *sd) */ static void sev_flush_encrypted_page(struct kvm_vcpu *vcpu, void *va) { - int asid =3D to_kvm_svm(vcpu->kvm)->sev_info.asid; + unsigned int asid =3D sev_get_asid(vcpu->kvm); =20 /* * Note! The address must be a kernel address, as regular page walk @@ -2630,7 +2632,7 @@ void sev_es_unmap_ghcb(struct vcpu_svm *svm) void pre_sev_run(struct vcpu_svm *svm, int cpu) { struct svm_cpu_data *sd =3D per_cpu_ptr(&svm_data, cpu); - int asid =3D sev_get_asid(svm->vcpu.kvm); + unsigned int asid =3D sev_get_asid(svm->vcpu.kvm); =20 /* Assign the asid allocated with this SEV guest */ svm->asid =3D asid; diff --git a/arch/x86/kvm/trace.h b/arch/x86/kvm/trace.h index 88659de4d2a7..c6b4b1728006 100644 --- a/arch/x86/kvm/trace.h +++ b/arch/x86/kvm/trace.h @@ -735,13 +735,13 @@ TRACE_EVENT(kvm_nested_intr_vmexit, * Tracepoint for nested #vmexit because of interrupt pending */ TRACE_EVENT(kvm_invlpga, - TP_PROTO(__u64 rip, int asid, u64 address), + TP_PROTO(__u64 rip, unsigned int asid, u64 address), TP_ARGS(rip, asid, address), =20 TP_STRUCT__entry( - __field( __u64, rip ) - __field( int, asid ) - __field( __u64, address ) + __field( __u64, rip ) + __field( unsigned int, asid ) + __field( __u64, address ) ), =20 TP_fast_assign( @@ -750,7 +750,7 @@ TRACE_EVENT(kvm_invlpga, __entry->address =3D address; ), =20 - TP_printk("rip: 0x%016llx asid: %d address: 0x%016llx", + TP_printk("rip: 0x%016llx asid: %u address: 0x%016llx", __entry->rip, __entry->asid, __entry->address) ); =20 --=20 2.43.0 From nobody Sun Feb 8 12:57:57 2026 Received: from us-smtp-delivery-124.mimecast.com (us-smtp-delivery-124.mimecast.com [170.10.133.124]) (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 8354159B64 for ; Mon, 18 Mar 2024 22:10:11 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=170.10.133.124 ARC-Seal: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1710799813; cv=none; b=G+Rr59p97nmnkJadmR5xSkmemJtqf1TIk4vYfAgdLIn/ybQWXdwx6T4X4Y5GsHtzFN8JHIko92K+/HPbx6o7ONW+gvcOhmDLroLJ+72KP/6P4XH6Ub7NGA1CjGYQkzv11OwkLtVRTgiD4JziLNaDuxzMvgN+rUVZV/YmM9BwgJE= ARC-Message-Signature: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1710799813; c=relaxed/simple; bh=jBqGxeE+IhKyoXM9zVHSpir3KZfZHpFMsiIw7rgHpZE=; h=From:To:Cc:Subject:Date:Message-ID:In-Reply-To:References: MIME-Version:Content-Type; b=FBPHb3dlXoC+lA2zFaTtOYY6Qg2pn6nIRc/BrneLmyIWP7DKcjliYXHVhdnGdL1hib9XtGzpnQQQAoRVs/qolvvSGaG0M7BDb04QLuCOFCiobb2iJTBqGR/QqkpGlNUgDgrt550ZkhdIIhtyASpBhc6a1z7OcNefE4F/NB9/Yvk= ARC-Authentication-Results: i=1; smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=redhat.com; spf=pass smtp.mailfrom=redhat.com; dkim=pass (1024-bit key) header.d=redhat.com header.i=@redhat.com header.b=ZQYea57B; arc=none smtp.client-ip=170.10.133.124 Authentication-Results: smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=redhat.com Authentication-Results: smtp.subspace.kernel.org; spf=pass smtp.mailfrom=redhat.com Authentication-Results: smtp.subspace.kernel.org; dkim=pass (1024-bit key) header.d=redhat.com header.i=@redhat.com header.b="ZQYea57B" DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com; s=mimecast20190719; t=1710799810; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc:mime-version:mime-version:content-type:content-type: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references; bh=OyCsbi8n3w9nlxB/vU9IG/7BiogA4ynph3bT+cZ/wPg=; b=ZQYea57BYWnRORW+e2z/PzBZ96Z35+KPSWn9LeHyfwZ1DXfeW61iSuIXK/57FMVR6nqMXL DEg2iAeKFI/UY2uTLtbb82MsjXbCY72i9CObQrRZKgKwwsGSedvD1xNH+oivvwWfaVCC4M vPcGrK2Rlf0XZd1dCv5e/MOpD2Byk/g= Received: from mimecast-mx02.redhat.com (mx-ext.redhat.com [66.187.233.73]) by relay.mimecast.com with ESMTP with STARTTLS (version=TLSv1.3, cipher=TLS_AES_256_GCM_SHA384) id us-mta-262-nIs2tlAGOB-euepDbDHAPQ-1; Mon, 18 Mar 2024 18:10:04 -0400 X-MC-Unique: nIs2tlAGOB-euepDbDHAPQ-1 Received: from smtp.corp.redhat.com (int-mx09.intmail.prod.int.rdu2.redhat.com [10.11.54.9]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (2048 bits) server-digest SHA256) (No client certificate requested) by mimecast-mx02.redhat.com (Postfix) with ESMTPS id 2F78A2800E8B; Mon, 18 Mar 2024 22:10:04 +0000 (UTC) Received: from virtlab701.virt.lab.eng.bos.redhat.com (virtlab701.virt.lab.eng.bos.redhat.com [10.19.152.228]) by smtp.corp.redhat.com (Postfix) with ESMTP id 03EC9492BC8; Mon, 18 Mar 2024 22:10:03 +0000 (UTC) From: Paolo Bonzini To: linux-kernel@vger.kernel.org, kvm@vger.kernel.org Cc: seanjc@google.com, Ashish Kalra , stable@vger.kernel.org, Tom Lendacky Subject: [PATCH 3/7] KVM: SVM: Add support for allowing zero SEV ASIDs Date: Mon, 18 Mar 2024 18:09:58 -0400 Message-ID: <20240318221002.2712738-4-pbonzini@redhat.com> In-Reply-To: <20240318221002.2712738-1-pbonzini@redhat.com> References: <20240318221002.2712738-1-pbonzini@redhat.com> Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 Content-Transfer-Encoding: quoted-printable X-Scanned-By: MIMEDefang 3.4.1 on 10.11.54.9 Content-Type: text/plain; charset="utf-8" From: Ashish Kalra Some BIOSes allow the end user to set the minimum SEV ASID value (CPUID 0x8000001F_EDX) to be greater than the maximum number of encrypted guests, or maximum SEV ASID value (CPUID 0x8000001F_ECX) in order to dedicate all the SEV ASIDs to SEV-ES or SEV-SNP. The SEV support, as coded, does not handle the case where the minimum SEV ASID value can be greater than the maximum SEV ASID value. As a result, the following confusing message is issued: [ 30.715724] kvm_amd: SEV enabled (ASIDs 1007 - 1006) Fix the support to properly handle this case. Fixes: 916391a2d1dc ("KVM: SVM: Add support for SEV-ES capability in KVM") Suggested-by: Sean Christopherson Signed-off-by: Ashish Kalra Cc: stable@vger.kernel.org Acked-by: Tom Lendacky Link: https://lore.kernel.org/r/20240104190520.62510-1-Ashish.Kalra@amd.com Link: https://lore.kernel.org/r/20240131235609.4161407-4-seanjc@google.com Signed-off-by: Sean Christopherson --- arch/x86/kvm/svm/sev.c | 29 +++++++++++++++++++---------- 1 file changed, 19 insertions(+), 10 deletions(-) diff --git a/arch/x86/kvm/svm/sev.c b/arch/x86/kvm/svm/sev.c index eeef43c795d8..5f8312edee36 100644 --- a/arch/x86/kvm/svm/sev.c +++ b/arch/x86/kvm/svm/sev.c @@ -144,10 +144,21 @@ static void sev_misc_cg_uncharge(struct kvm_sev_info = *sev) =20 static int sev_asid_new(struct kvm_sev_info *sev) { - unsigned int asid, min_asid, max_asid; + /* + * SEV-enabled guests must use asid from min_sev_asid to max_sev_asid. + * SEV-ES-enabled guest can use from 1 to min_sev_asid - 1. + * Note: min ASID can end up larger than the max if basic SEV support is + * effectively disabled by disallowing use of ASIDs for SEV guests. + */ + unsigned int min_asid =3D sev->es_active ? 1 : min_sev_asid; + unsigned int max_asid =3D sev->es_active ? min_sev_asid - 1 : max_sev_asi= d; + unsigned int asid; bool retry =3D true; int ret; =20 + if (min_asid > max_asid) + return -ENOTTY; + WARN_ON(sev->misc_cg); sev->misc_cg =3D get_current_misc_cg(); ret =3D sev_misc_cg_try_charge(sev); @@ -159,12 +170,6 @@ static int sev_asid_new(struct kvm_sev_info *sev) =20 mutex_lock(&sev_bitmap_lock); =20 - /* - * SEV-enabled guests must use asid from min_sev_asid to max_sev_asid. - * SEV-ES-enabled guest can use from 1 to min_sev_asid - 1. - */ - min_asid =3D sev->es_active ? 1 : min_sev_asid; - max_asid =3D sev->es_active ? min_sev_asid - 1 : max_sev_asid; again: asid =3D find_next_zero_bit(sev_asid_bitmap, max_asid + 1, min_asid); if (asid > max_asid) { @@ -2234,8 +2239,10 @@ void __init sev_hardware_setup(void) goto out; } =20 - sev_asid_count =3D max_sev_asid - min_sev_asid + 1; - WARN_ON_ONCE(misc_cg_set_capacity(MISC_CG_RES_SEV, sev_asid_count)); + if (min_sev_asid <=3D max_sev_asid) { + sev_asid_count =3D max_sev_asid - min_sev_asid + 1; + WARN_ON_ONCE(misc_cg_set_capacity(MISC_CG_RES_SEV, sev_asid_count)); + } sev_supported =3D true; =20 /* SEV-ES support requested? */ @@ -2266,7 +2273,9 @@ void __init sev_hardware_setup(void) out: if (boot_cpu_has(X86_FEATURE_SEV)) pr_info("SEV %s (ASIDs %u - %u)\n", - sev_supported ? "enabled" : "disabled", + sev_supported ? min_sev_asid <=3D max_sev_asid ? "enabled" : + "unusable" : + "disabled", min_sev_asid, max_sev_asid); if (boot_cpu_has(X86_FEATURE_SEV_ES)) pr_info("SEV-ES %s (ASIDs %u - %u)\n", --=20 2.43.0 From nobody Sun Feb 8 12:57:57 2026 Received: from us-smtp-delivery-124.mimecast.com (us-smtp-delivery-124.mimecast.com [170.10.133.124]) (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 69E6C5A4C9 for ; Mon, 18 Mar 2024 22:10:09 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=170.10.133.124 ARC-Seal: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1710799811; cv=none; b=ZRrURnfOIfI2fqhhFFzwiA4u9GTwHipQHkKKPG5FYHEtw0zj1bVz6hTHubpMoV7ty+x3dmVStA/XpXJpEPIqMVCxB1+cWZzY7rDm5K4K/nnvE93MLXJwtC1lQ92IWYUG+QjuHIv+HfCyetxOytHWwH5DLpJF4r5BfsAdTfolNAA= ARC-Message-Signature: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1710799811; c=relaxed/simple; bh=xM5W/AEDhbWznck8GcEsoD7ke6NnQ8+Pi6POT+TXjgc=; h=From:To:Cc:Subject:Date:Message-ID:In-Reply-To:References: MIME-Version:Content-Type; b=cVT4wVXia78fBhPRa/KZhm5slvLLRG8EeEkQYvSXdeL0TKzmJIv49h9ja4NcxjYTMtO6mrjTRc0VKTHz3Vhx1O/Sa1O5CPtuEAqfhNrXgf/+PiWFdibg9q0V/iD5DporLOUe1xkYvARpqB1LsYsLoRbGUuu+YDe7NY5NlLrl4VM= ARC-Authentication-Results: i=1; smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=redhat.com; spf=pass smtp.mailfrom=redhat.com; dkim=pass (1024-bit key) header.d=redhat.com header.i=@redhat.com header.b=CzXLzgfW; arc=none smtp.client-ip=170.10.133.124 Authentication-Results: smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=redhat.com Authentication-Results: smtp.subspace.kernel.org; spf=pass smtp.mailfrom=redhat.com Authentication-Results: smtp.subspace.kernel.org; dkim=pass (1024-bit key) header.d=redhat.com header.i=@redhat.com header.b="CzXLzgfW" DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com; s=mimecast20190719; t=1710799808; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc:mime-version:mime-version:content-type:content-type: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references; bh=l14lmjr+n9Dly31dq7L8425halZyBpXBAUC4NGSIZWM=; b=CzXLzgfW9IFunAL39GW9Yd+mBJZx5nxTbJuDjucLiq0p+7dbAfS7Tv5Bi8LqYmRXVZZ3JV ZLnstcwY1RG87pvl9LgHuaHCGiHz2G3++Q+xTRmZkLVvZiwabTAe4VCjji0DBbyWN3f//+ bg/Z11N+zQBGqv1OB4AqrkmrxGCc3Lo= Received: from mimecast-mx02.redhat.com (mx-ext.redhat.com [66.187.233.73]) by relay.mimecast.com with ESMTP with STARTTLS (version=TLSv1.3, cipher=TLS_AES_256_GCM_SHA384) id us-mta-262-b88i4gU6OEacsAnFBlDGXg-1; Mon, 18 Mar 2024 18:10:04 -0400 X-MC-Unique: b88i4gU6OEacsAnFBlDGXg-1 Received: from smtp.corp.redhat.com (int-mx09.intmail.prod.int.rdu2.redhat.com [10.11.54.9]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (2048 bits) server-digest SHA256) (No client certificate requested) by mimecast-mx02.redhat.com (Postfix) with ESMTPS id 591DD2800EA6; Mon, 18 Mar 2024 22:10:04 +0000 (UTC) Received: from virtlab701.virt.lab.eng.bos.redhat.com (virtlab701.virt.lab.eng.bos.redhat.com [10.19.152.228]) by smtp.corp.redhat.com (Postfix) with ESMTP id 38595492BC8; Mon, 18 Mar 2024 22:10:04 +0000 (UTC) From: Paolo Bonzini To: linux-kernel@vger.kernel.org, kvm@vger.kernel.org Cc: seanjc@google.com, Tom Lendacky Subject: [PATCH 4/7] KVM: SVM: Return -EINVAL instead of -EBUSY on attempt to re-init SEV/SEV-ES Date: Mon, 18 Mar 2024 18:09:59 -0400 Message-ID: <20240318221002.2712738-5-pbonzini@redhat.com> In-Reply-To: <20240318221002.2712738-1-pbonzini@redhat.com> References: <20240318221002.2712738-1-pbonzini@redhat.com> Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 Content-Transfer-Encoding: quoted-printable X-Scanned-By: MIMEDefang 3.4.1 on 10.11.54.9 Content-Type: text/plain; charset="utf-8" From: Sean Christopherson Return -EINVAL instead of -EBUSY if userspace attempts KVM_SEV{,ES}_INIT on a VM that already has SEV active. Returning -EBUSY is nonsencial as it's impossible to deactivate SEV without destroying the VM, i.e. the VM isn't "busy" in any sane sense of the word, and the odds of any userspace wanting exactly -EBUSY on a userspace bug are minuscule. Reviewed-by: Tom Lendacky Link: https://lore.kernel.org/r/20240131235609.4161407-5-seanjc@google.com 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 5f8312edee36..f06f9e51ad9d 100644 --- a/arch/x86/kvm/svm/sev.c +++ b/arch/x86/kvm/svm/sev.c @@ -259,9 +259,8 @@ static int sev_guest_init(struct kvm *kvm, struct kvm_s= ev_cmd *argp) if (kvm->created_vcpus) return -EINVAL; =20 - ret =3D -EBUSY; if (unlikely(sev->active)) - return ret; + return -EINVAL; =20 sev->active =3D true; sev->es_active =3D argp->id =3D=3D KVM_SEV_ES_INIT; --=20 2.43.0 From nobody Sun Feb 8 12:57:57 2026 Received: from us-smtp-delivery-124.mimecast.com (us-smtp-delivery-124.mimecast.com [170.10.129.124]) (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 D241E5A7A7 for ; Mon, 18 Mar 2024 22:10:10 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=170.10.129.124 ARC-Seal: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1710799812; cv=none; b=M6YL5ClHoiJ4lANAQyHq3OFx/Sj9XhY8P5RR937r37M0Rt3F/EKIg4CVZJbPJO5w4IQkmgVrBSYK9TbpUQg3bSn91Aqs3QUHsP4i8wD2axqJ8CHcdpFOnpG2gOVPqdAB/OC0doogXomiSEjtxnvusb5eHndyo/5BtMdbfEZcEbk= ARC-Message-Signature: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1710799812; c=relaxed/simple; bh=WDJgBGpsjfapdQHO9gSdZJmkJ2P8LFMBkWTD21ibKpc=; h=From:To:Cc:Subject:Date:Message-ID:In-Reply-To:References: MIME-Version:Content-Type; b=g8GPfle2DiBVvXSQi8oXXkRP/EkMsPqYFghpjZzvF/tWjaIVw5/wGZIs8I1OYRqRl4y+INbOdZF9ggTx+JKqJexEMhAXdWbOmWY4Aup7Hw7rEHMmS6mVsRYbXT6ebUP/bGabOx/1MgRo2D//L3kYdalOdD9vsbGxmThmv1Sgc2Y= ARC-Authentication-Results: i=1; smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=redhat.com; spf=pass smtp.mailfrom=redhat.com; dkim=pass (1024-bit key) header.d=redhat.com header.i=@redhat.com header.b=W7TZgBg9; arc=none smtp.client-ip=170.10.129.124 Authentication-Results: smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=redhat.com Authentication-Results: smtp.subspace.kernel.org; spf=pass smtp.mailfrom=redhat.com Authentication-Results: smtp.subspace.kernel.org; dkim=pass (1024-bit key) header.d=redhat.com header.i=@redhat.com header.b="W7TZgBg9" DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com; s=mimecast20190719; t=1710799809; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc:mime-version:mime-version:content-type:content-type: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references; bh=dlbCs/oY8pq5Hz3ScnLWN4ip71+tL2nCn+OgiiJ657w=; b=W7TZgBg9VfEPBrELDCNUn6w12yFF8DfVK97AtDvZVxkQEb/Rz6qPPdP3YuAVbC7gzSRVrT e/HVTdRFKqOulcpHwo4ijjttOjCxHi5EqBKSJuqsgeyLFW3kIIMPvajIPvf1YCsM2VV4cG oc6P1EL57gOusRucJyQoSHV4j/x3Y8Q= Received: from mimecast-mx02.redhat.com (mx-ext.redhat.com [66.187.233.73]) by relay.mimecast.com with ESMTP with STARTTLS (version=TLSv1.3, cipher=TLS_AES_256_GCM_SHA384) id us-mta-671-Chlckh1nNliuyWf8NiOs8Q-1; Mon, 18 Mar 2024 18:10:04 -0400 X-MC-Unique: Chlckh1nNliuyWf8NiOs8Q-1 Received: from smtp.corp.redhat.com (int-mx09.intmail.prod.int.rdu2.redhat.com [10.11.54.9]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (2048 bits) server-digest SHA256) (No client certificate requested) by mimecast-mx02.redhat.com (Postfix) with ESMTPS id 840623C0BE2D; Mon, 18 Mar 2024 22:10:04 +0000 (UTC) Received: from virtlab701.virt.lab.eng.bos.redhat.com (virtlab701.virt.lab.eng.bos.redhat.com [10.19.152.228]) by smtp.corp.redhat.com (Postfix) with ESMTP id 618F2492BC8; Mon, 18 Mar 2024 22:10:04 +0000 (UTC) From: Paolo Bonzini To: linux-kernel@vger.kernel.org, kvm@vger.kernel.org Cc: seanjc@google.com, Michael Roth Subject: [PATCH 5/7] KVM: SEV: fix compat ABI for KVM_MEMORY_ENCRYPT_OP Date: Mon, 18 Mar 2024 18:10:00 -0400 Message-ID: <20240318221002.2712738-6-pbonzini@redhat.com> In-Reply-To: <20240318221002.2712738-1-pbonzini@redhat.com> References: <20240318221002.2712738-1-pbonzini@redhat.com> Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 Content-Transfer-Encoding: quoted-printable X-Scanned-By: MIMEDefang 3.4.1 on 10.11.54.9 Content-Type: text/plain; charset="utf-8" The data structs for KVM_MEMORY_ENCRYPT_OP have different sizes for 32- and= 64-bit userspace, but they do not make any attempt to convert from one ABI to the = other when 32-bit userspace is running on 64-bit kernels. This configuration nev= er worked, and SEV is only for 64-bit kernels so we're not breaking ABI on 32-= bit kernels. Fix this by adding the appropriate padding; no functional change intended for 64-bit userspace. Reviewed-by: Michael Roth Reviewed-by: Sean Christopherson Signed-off-by: Paolo Bonzini --- arch/x86/include/uapi/asm/kvm.h | 23 +++++++++++++++++++++++ 1 file changed, 23 insertions(+) diff --git a/arch/x86/include/uapi/asm/kvm.h b/arch/x86/include/uapi/asm/kv= m.h index ad29984d5e39..ef11aa4cab42 100644 --- a/arch/x86/include/uapi/asm/kvm.h +++ b/arch/x86/include/uapi/asm/kvm.h @@ -694,6 +694,7 @@ enum sev_cmd_id { =20 struct kvm_sev_cmd { __u32 id; + __u32 pad0; __u64 data; __u32 error; __u32 sev_fd; @@ -704,28 +705,35 @@ struct kvm_sev_launch_start { __u32 policy; __u64 dh_uaddr; __u32 dh_len; + __u32 pad0; __u64 session_uaddr; __u32 session_len; + __u32 pad1; }; =20 struct kvm_sev_launch_update_data { __u64 uaddr; __u32 len; + __u32 pad0; }; =20 =20 struct kvm_sev_launch_secret { __u64 hdr_uaddr; __u32 hdr_len; + __u32 pad0; __u64 guest_uaddr; __u32 guest_len; + __u32 pad1; __u64 trans_uaddr; __u32 trans_len; + __u32 pad2; }; =20 struct kvm_sev_launch_measure { __u64 uaddr; __u32 len; + __u32 pad0; }; =20 struct kvm_sev_guest_status { @@ -738,33 +746,43 @@ struct kvm_sev_dbg { __u64 src_uaddr; __u64 dst_uaddr; __u32 len; + __u32 pad0; }; =20 struct kvm_sev_attestation_report { __u8 mnonce[16]; __u64 uaddr; __u32 len; + __u32 pad0; }; =20 struct kvm_sev_send_start { __u32 policy; + __u32 pad0; __u64 pdh_cert_uaddr; __u32 pdh_cert_len; + __u32 pad1; __u64 plat_certs_uaddr; __u32 plat_certs_len; + __u32 pad2; __u64 amd_certs_uaddr; __u32 amd_certs_len; + __u32 pad3; __u64 session_uaddr; __u32 session_len; + __u32 pad4; }; =20 struct kvm_sev_send_update_data { __u64 hdr_uaddr; __u32 hdr_len; + __u32 pad0; __u64 guest_uaddr; __u32 guest_len; + __u32 pad1; __u64 trans_uaddr; __u32 trans_len; + __u32 pad2; }; =20 struct kvm_sev_receive_start { @@ -772,17 +790,22 @@ struct kvm_sev_receive_start { __u32 policy; __u64 pdh_uaddr; __u32 pdh_len; + __u32 pad0; __u64 session_uaddr; __u32 session_len; + __u32 pad1; }; =20 struct kvm_sev_receive_update_data { __u64 hdr_uaddr; __u32 hdr_len; + __u32 pad0; __u64 guest_uaddr; __u32 guest_len; + __u32 pad1; __u64 trans_uaddr; __u32 trans_len; + __u32 pad2; }; =20 #define KVM_X2APIC_API_USE_32BIT_IDS (1ULL << 0) --=20 2.43.0 From nobody Sun Feb 8 12:57:57 2026 Received: from us-smtp-delivery-124.mimecast.com (us-smtp-delivery-124.mimecast.com [170.10.129.124]) (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 69EB05A4CA for ; Mon, 18 Mar 2024 22:10:09 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=170.10.129.124 ARC-Seal: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1710799812; cv=none; b=asTA9S9QAlWF+C66RVZXrRoZbl0N3E5tcj5OLoXiKuaD5OnlBoyexUa2Z1/Bvi6x+905kUl1vn7KjCBTq25FzGynVQrxa9ez1NDMNWdDIRkIGPHFPogVhw9Db12DwTwIVX6mnYP3v0R6u7q72hRuerTKfAoE0BaebPdW4HssgCw= ARC-Message-Signature: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1710799812; c=relaxed/simple; bh=Z5iRfxdNh5CyrDoUPDoH234u8YFkwUvwaTp8RBly4oA=; h=From:To:Cc:Subject:Date:Message-ID:In-Reply-To:References: MIME-Version:Content-Type; b=p4elbk+OFVa1waiFocSGhTEhdg4eC5hUy+lM4EojsGeKMBEshsGOaGbejMr5AnZ6ysBvIDN8FoIMnMCNlqOaT4GtlQnu5sZhqL/C++KifJ4l+4o0NU8GbGMFKEDzFmmGgQyaLQTQx5JgQRg4queFuGmFZOhldbKHAIutQ9ev3b8= ARC-Authentication-Results: i=1; smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=redhat.com; spf=pass smtp.mailfrom=redhat.com; dkim=pass (1024-bit key) header.d=redhat.com header.i=@redhat.com header.b=XWKXmU5k; arc=none smtp.client-ip=170.10.129.124 Authentication-Results: smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=redhat.com Authentication-Results: smtp.subspace.kernel.org; spf=pass smtp.mailfrom=redhat.com Authentication-Results: smtp.subspace.kernel.org; dkim=pass (1024-bit key) header.d=redhat.com header.i=@redhat.com header.b="XWKXmU5k" DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com; s=mimecast20190719; t=1710799808; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc:mime-version:mime-version:content-type:content-type: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references; bh=WBkKm95Ln/2RsUgEOWoo/2LuPFULXZi0eLnZQwdqLAM=; b=XWKXmU5kMG0UVPLYFCQ6x0ReXR9vxZsINggyDCtk4O+4Xc46qLeGMSsMQoRIj1Y0lqpb0j UUECrgPKGsvisE2/hCBgy8FUmDoyIAoyeMW/iPxLym4VwgWXU6caFZcYXXklFALZJVGR12 gYx7MzyXyjyWvWJD9niSit79kVVbh6k= Received: from mimecast-mx02.redhat.com (mx-ext.redhat.com [66.187.233.73]) by relay.mimecast.com with ESMTP with STARTTLS (version=TLSv1.3, cipher=TLS_AES_256_GCM_SHA384) id us-mta-591-NnrrJCCFNB-Nld8hG1-VXA-1; Mon, 18 Mar 2024 18:10:05 -0400 X-MC-Unique: NnrrJCCFNB-Nld8hG1-VXA-1 Received: from smtp.corp.redhat.com (int-mx09.intmail.prod.int.rdu2.redhat.com [10.11.54.9]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (2048 bits) server-digest SHA256) (No client certificate requested) by mimecast-mx02.redhat.com (Postfix) with ESMTPS id ACB591C04330; Mon, 18 Mar 2024 22:10:04 +0000 (UTC) Received: from virtlab701.virt.lab.eng.bos.redhat.com (virtlab701.virt.lab.eng.bos.redhat.com [10.19.152.228]) by smtp.corp.redhat.com (Postfix) with ESMTP id 8BF02492BC8; Mon, 18 Mar 2024 22:10:04 +0000 (UTC) From: Paolo Bonzini To: linux-kernel@vger.kernel.org, kvm@vger.kernel.org Cc: seanjc@google.com, Michael Roth Subject: [PATCH 6/7] Documentation: kvm/sev: separate description of firmware Date: Mon, 18 Mar 2024 18:10:01 -0400 Message-ID: <20240318221002.2712738-7-pbonzini@redhat.com> In-Reply-To: <20240318221002.2712738-1-pbonzini@redhat.com> References: <20240318221002.2712738-1-pbonzini@redhat.com> Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 Content-Transfer-Encoding: quoted-printable X-Scanned-By: MIMEDefang 3.4.1 on 10.11.54.9 Content-Type: text/plain; charset="utf-8" The description of firmware is included part under the "SEV Key Management" header, part under the KVM_SEV_INIT ioctl. Put these two bits together and and rename "SEV Key Management" to what it actually is, namely a description of the KVM_MEMORY_ENCRYPT_OP API. Reviewed-by: Michael Roth Signed-off-by: Paolo Bonzini --- .../virt/kvm/x86/amd-memory-encryption.rst | 29 +++++++++++-------- 1 file changed, 17 insertions(+), 12 deletions(-) diff --git a/Documentation/virt/kvm/x86/amd-memory-encryption.rst b/Documen= tation/virt/kvm/x86/amd-memory-encryption.rst index 995780088eb2..4f2eb441c718 100644 --- a/Documentation/virt/kvm/x86/amd-memory-encryption.rst +++ b/Documentation/virt/kvm/x86/amd-memory-encryption.rst @@ -46,14 +46,8 @@ SEV hardware uses ASIDs to associate a memory encryption= key with a VM. Hence, the ASID for the SEV-enabled guests must be from 1 to a maximum val= ue defined in the CPUID 0x8000001f[ecx] field. =20 -SEV Key Management -=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D - -The SEV guest key management is handled by a separate processor called the= AMD -Secure Processor (AMD-SP). Firmware running inside the AMD-SP provides a s= ecure -key management interface to perform common hypervisor activities such as -encrypting bootstrap code, snapshot, migrating and debugging the guest. Fo= r more -information, see the SEV Key Management spec [api-spec]_ +The KVM_MEMORY_ENCRYPT_OP ioctl +=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D =20 The main ioctl to access SEV is KVM_MEMORY_ENCRYPT_OP. If the argument to KVM_MEMORY_ENCRYPT_OP is NULL, the ioctl returns 0 if SEV is enabled @@ -87,10 +81,6 @@ guests, such as launching, running, snapshotting, migrat= ing and decommissioning. The KVM_SEV_INIT command is used by the hypervisor to initialize the SEV p= latform context. In a typical workflow, this command should be the first command i= ssued. =20 -The firmware can be initialized either by using its own non-volatile stora= ge or -the OS can manage the NV storage for the firmware using the module paramet= er -``init_ex_path``. If the file specified by ``init_ex_path`` does not exist= or -is invalid, the OS will create or override the file with output from PSP. =20 Returns: 0 on success, -negative on error =20 @@ -434,6 +424,21 @@ issued by the hypervisor to make the guest ready for e= xecution. =20 Returns: 0 on success, -negative on error =20 +Firmware Management +=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D + +The SEV guest key management is handled by a separate processor called the= AMD +Secure Processor (AMD-SP). Firmware running inside the AMD-SP provides a s= ecure +key management interface to perform common hypervisor activities such as +encrypting bootstrap code, snapshot, migrating and debugging the guest. Fo= r more +information, see the SEV Key Management spec [api-spec]_ + +The AMD-SP firmware can be initialized either by using its own non-volatile +storage or the OS can manage the NV storage for the firmware using +parameter ``init_ex_path`` of the ``ccp`` module. If the file specified +by ``init_ex_path`` does not exist or is invalid, the OS will create or +override the file with PSP non-volatile storage. + References =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D =20 --=20 2.43.0 From nobody Sun Feb 8 12:57:57 2026 Received: from us-smtp-delivery-124.mimecast.com (us-smtp-delivery-124.mimecast.com [170.10.133.124]) (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 DCBCD5A4E9 for ; Mon, 18 Mar 2024 22:10:09 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=170.10.133.124 ARC-Seal: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1710799811; cv=none; b=t2tLN+FRclwjl6X1i+5tHcSVAdh8Kcjwe5dFSO7amNbci/Gwv4gHjcZ20w0dfKBWO8NgY1hRjo3dkTSxIZKZDMxTm2ULYL6m50+HTeD/hPOtHO1UzjdBv6cbVKCGlxmHg8bo9sXGAevIgw0W8SpOZsX7aYlOmHjkn+xCX2xf67Q= ARC-Message-Signature: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1710799811; c=relaxed/simple; bh=qaJEDXwpaSJXM+1hD3fE9I/G0z5IQq6ORF3Rr7L/kFA=; h=From:To:Cc:Subject:Date:Message-ID:In-Reply-To:References: MIME-Version:Content-Type; b=Ezjn14ZhcU5e5uWl/DF7h5neQhHKH1XBZtHGSOJd9C8BoN3ch7vJp4xlXNVL5M1WNI6l/a2hFIuC5e8DL8ON5CmW1MnpkXk7dfMgV058S2q2ecMzZSpBUUpqLKqdJmDN+U+ANNVoCLqOm1Ba+TxRap61di5bW46FQw0wrRU8KSg= ARC-Authentication-Results: i=1; smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=redhat.com; spf=pass smtp.mailfrom=redhat.com; dkim=pass (1024-bit key) header.d=redhat.com header.i=@redhat.com header.b=Wbvgy+qp; arc=none smtp.client-ip=170.10.133.124 Authentication-Results: smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=redhat.com Authentication-Results: smtp.subspace.kernel.org; spf=pass smtp.mailfrom=redhat.com Authentication-Results: smtp.subspace.kernel.org; dkim=pass (1024-bit key) header.d=redhat.com header.i=@redhat.com header.b="Wbvgy+qp" DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com; s=mimecast20190719; t=1710799808; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc:mime-version:mime-version:content-type:content-type: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references; bh=gMEmPn7yUS4wreWy4Dg8bjqaNwIrv+R0K2a7wjWFE2c=; b=Wbvgy+qpjzltpD+psahFXWvob3PC13wEU2g8t18e3vgBqPljWw1VazF64xnMWOsaaciUOb R/fOsXyyhSLNua98P415ICaONJvhS2zLyxnGFHOD7NXdqk3XCVkB1PmmXfBsjRryw+zd8q nxnDVQSfYqtmSPF4gCOPAF64Sf+5d/c= Received: from mimecast-mx02.redhat.com (mx-ext.redhat.com [66.187.233.73]) by relay.mimecast.com with ESMTP with STARTTLS (version=TLSv1.3, cipher=TLS_AES_256_GCM_SHA384) id us-mta-302-0_C0MuIrMzapy9sgm8UnZQ-1; Mon, 18 Mar 2024 18:10:05 -0400 X-MC-Unique: 0_C0MuIrMzapy9sgm8UnZQ-1 Received: from smtp.corp.redhat.com (int-mx09.intmail.prod.int.rdu2.redhat.com [10.11.54.9]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (2048 bits) server-digest SHA256) (No client certificate requested) by mimecast-mx02.redhat.com (Postfix) with ESMTPS id D1DC11C04332; Mon, 18 Mar 2024 22:10:04 +0000 (UTC) Received: from virtlab701.virt.lab.eng.bos.redhat.com (virtlab701.virt.lab.eng.bos.redhat.com [10.19.152.228]) by smtp.corp.redhat.com (Postfix) with ESMTP id B483F492BC8; Mon, 18 Mar 2024 22:10:04 +0000 (UTC) From: Paolo Bonzini To: linux-kernel@vger.kernel.org, kvm@vger.kernel.org Cc: seanjc@google.com Subject: [PATCH 7/7] Documentation: kvm/sev: clarify usage of KVM_MEMORY_ENCRYPT_OP Date: Mon, 18 Mar 2024 18:10:02 -0400 Message-ID: <20240318221002.2712738-8-pbonzini@redhat.com> In-Reply-To: <20240318221002.2712738-1-pbonzini@redhat.com> References: <20240318221002.2712738-1-pbonzini@redhat.com> Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 Content-Transfer-Encoding: quoted-printable X-Scanned-By: MIMEDefang 3.4.1 on 10.11.54.9 Content-Type: text/plain; charset="utf-8" Explain that it operates on the VM file descriptor, and also clarify how detection of SEV operates on old kernels predating commit 2da1ed62d55c ("KVM: SVM: document KVM_MEM_ENCRYPT_OP, let userspace detect if SEV is available"). Signed-off-by: Paolo Bonzini --- .../virt/kvm/x86/amd-memory-encryption.rst | 13 +++++++------ 1 file changed, 7 insertions(+), 6 deletions(-) diff --git a/Documentation/virt/kvm/x86/amd-memory-encryption.rst b/Documen= tation/virt/kvm/x86/amd-memory-encryption.rst index 4f2eb441c718..84335d119ff1 100644 --- a/Documentation/virt/kvm/x86/amd-memory-encryption.rst +++ b/Documentation/virt/kvm/x86/amd-memory-encryption.rst @@ -49,12 +49,13 @@ defined in the CPUID 0x8000001f[ecx] field. The KVM_MEMORY_ENCRYPT_OP ioctl =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D =20 -The main ioctl to access SEV is KVM_MEMORY_ENCRYPT_OP. If the argument -to KVM_MEMORY_ENCRYPT_OP is NULL, the ioctl returns 0 if SEV is enabled -and ``ENOTTY`` if it is disabled (on some older versions of Linux, -the ioctl runs normally even with a NULL argument, and therefore will -likely return ``EFAULT``). If non-NULL, the argument to KVM_MEMORY_ENCRYP= T_OP -must be a struct kvm_sev_cmd:: +The main ioctl to access SEV is KVM_MEMORY_ENCRYPT_OP, which operates on +the VM file descriptor. If the argument to KVM_MEMORY_ENCRYPT_OP is NULL, +the ioctl returns 0 if SEV is enabled and ``ENOTTY`` if it is disabled +(on some older versions of Linux, the ioctl tries to run normally even +with a NULL argument, and therefore will likely return ``EFAULT`` instead +of zero if SEV is enabled). If non-NULL, the argument to +KVM_MEMORY_ENCRYPT_OP must be a struct kvm_sev_cmd:: =20 struct kvm_sev_cmd { __u32 id; --=20 2.43.0