From nobody Mon Sep 16 19:16:18 2024 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 5663C3BBC1 for ; Fri, 26 Jul 2024 18:52:04 +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=1722019927; cv=none; b=Rb/952G/ErLwIyMDsVa1VfxN6ozx6F0vkkF2vS0JCb/xzNadOHqVRb8M3+P7XLtF2hsdjIYZE7a5zwc09nQfK/qiwTYk0KO45vuJ2OydSLbPFs3OugCHP3g+/fX+s7WbNND+yIPCcneEkT2VERySv7SJ/Z2xBH8pRlNQe9KQPTQ= ARC-Message-Signature: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1722019927; c=relaxed/simple; bh=O26rJ7Gcfv4ARMLR28jWxqFOljVbUnxyI2aeb/KHyHI=; h=From:To:Cc:Subject:Date:Message-ID:In-Reply-To:References: MIME-Version:Content-Type; b=O/8FG7PqYXv8ZBlcOMJPMNotJFlB0/n6/Of4IZ/vatZn0Dtc6VewwbSf/0ogrHBrxsnLK/4KQKTDRCIDdpD8lLKqlQ3UmYRgTJu15qszulbMXL1R095QIA2lrBI8SAL2I7aM3G7ofc51+WKhfLTVXpxPgtRAggs9A1YBVBTAbjw= 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=aIMMJUE3; 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="aIMMJUE3" DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com; s=mimecast20190719; t=1722019923; 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=Nzd3Ramz8UsVExhcniTAeg+8/OlVGantjS5vCPA9244=; b=aIMMJUE3fvPYySe2YtQxjcSJbdB+bKUrLT5YUZ/weZL/oChX1EeXG61N9VkXJqPck2mkTH hzK+zIbdAfmfWxqNjes6Lc6aYBB4gQSLg6sRx5FOctOf4NXKNHgmdfO/5s4LsT9bZshOg/ pt3eR8sSDg8dMGKaiplpMCFCQwSiyOg= Received: from mx-prod-mc-04.mail-002.prod.us-west-2.aws.redhat.com (ec2-54-186-198-63.us-west-2.compute.amazonaws.com [54.186.198.63]) by relay.mimecast.com with ESMTP with STARTTLS (version=TLSv1.3, cipher=TLS_AES_256_GCM_SHA384) id us-mta-12-8IdCqyXBOUWxMALqfQablw-1; Fri, 26 Jul 2024 14:52:00 -0400 X-MC-Unique: 8IdCqyXBOUWxMALqfQablw-1 Received: from mx-prod-int-01.mail-002.prod.us-west-2.aws.redhat.com (mx-prod-int-01.mail-002.prod.us-west-2.aws.redhat.com [10.30.177.4]) (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 mx-prod-mc-04.mail-002.prod.us-west-2.aws.redhat.com (Postfix) with ESMTPS id AFFD419560AD; Fri, 26 Jul 2024 18:51:59 +0000 (UTC) Received: from virtlab1023.lab.eng.rdu2.redhat.com (virtlab1023.lab.eng.rdu2.redhat.com [10.8.1.187]) by mx-prod-int-01.mail-002.prod.us-west-2.aws.redhat.com (Postfix) with ESMTP id 0048E3000194; Fri, 26 Jul 2024 18:51:58 +0000 (UTC) From: Paolo Bonzini To: linux-kernel@vger.kernel.org, kvm@vger.kernel.org Cc: seanjc@google.com, michael.roth@amd.com Subject: [PATCH v2 01/14] KVM: x86: disallow pre-fault for SNP VMs before initialization Date: Fri, 26 Jul 2024 14:51:44 -0400 Message-ID: <20240726185157.72821-2-pbonzini@redhat.com> In-Reply-To: <20240726185157.72821-1-pbonzini@redhat.com> References: <20240726185157.72821-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.30.177.4 Content-Type: text/plain; charset="utf-8" KVM_PRE_FAULT_MEMORY for an SNP guest can race with sev_gmem_post_populate() in bad ways. The following sequence for instance can potentially trigger an RMP fault: thread A, sev_gmem_post_populate: called thread B, sev_gmem_prepare: places below 'pfn' in a private state in RMP thread A, sev_gmem_post_populate: *vaddr =3D kmap_local_pfn(pfn + i); thread A, sev_gmem_post_populate: copy_from_user(vaddr, src + i * PAGE_SI= ZE, PAGE_SIZE); RMP #PF Fix this by only allowing KVM_PRE_FAULT_MEMORY to run after a guest's initial private memory contents have been finalized via KVM_SEV_SNP_LAUNCH_FINISH. Beyond fixing this issue, it just sort of makes sense to enforce this, since the KVM_PRE_FAULT_MEMORY documentation states: "KVM maps memory as if the vCPU generated a stage-2 read page fault" which sort of implies we should be acting on the same guest state that a vCPU would see post-launch after the initial guest memory is all set up. Co-developed-by: Michael Roth Signed-off-by: Michael Roth Signed-off-by: Paolo Bonzini Tested-by: Michael Roth --- Documentation/virt/kvm/api.rst | 6 ++++++ arch/x86/include/asm/kvm_host.h | 1 + arch/x86/kvm/mmu/mmu.c | 3 +++ arch/x86/kvm/svm/sev.c | 8 ++++++++ arch/x86/kvm/svm/svm.c | 1 + arch/x86/kvm/x86.c | 3 +++ 6 files changed, 22 insertions(+) diff --git a/Documentation/virt/kvm/api.rst b/Documentation/virt/kvm/api.rst index ec1cd8aa1d56..7b512286f8d2 100644 --- a/Documentation/virt/kvm/api.rst +++ b/Documentation/virt/kvm/api.rst @@ -6402,6 +6402,12 @@ for the current vCPU state. KVM maps memory as if t= he vCPU generated a stage-2 read page fault, e.g. faults in memory as needed, but doesn't break CoW. However, KVM does not mark any newly created stage-2 PTE as Accessed. =20 +In the case of confidential VM types where there is an initial set up of +private guest memory before the guest is 'finalized'/measured, this ioctl +should only be issued after completing all the necessary setup to put the +guest into a 'finalized' state so that the above semantics can be reliably +ensured. + In some cases, multiple vCPUs might share the page tables. In this case, the ioctl can be called in parallel. =20 diff --git a/arch/x86/include/asm/kvm_host.h b/arch/x86/include/asm/kvm_hos= t.h index 950a03e0181e..94e7b5a4fafe 100644 --- a/arch/x86/include/asm/kvm_host.h +++ b/arch/x86/include/asm/kvm_host.h @@ -1305,6 +1305,7 @@ struct kvm_arch { u8 vm_type; bool has_private_mem; bool has_protected_state; + bool pre_fault_allowed; struct hlist_head mmu_page_hash[KVM_NUM_MMU_PAGES]; struct list_head active_mmu_pages; struct list_head zapped_obsolete_pages; diff --git a/arch/x86/kvm/mmu/mmu.c b/arch/x86/kvm/mmu/mmu.c index 901be9e420a4..26ef5b6ac3c1 100644 --- a/arch/x86/kvm/mmu/mmu.c +++ b/arch/x86/kvm/mmu/mmu.c @@ -4743,6 +4743,9 @@ long kvm_arch_vcpu_pre_fault_memory(struct kvm_vcpu *= vcpu, u64 end; int r; =20 + if (!vcpu->kvm->arch.pre_fault_allowed) + return -EOPNOTSUPP; + /* * reload is efficient when called repeatedly, so we can do it on * every iteration. diff --git a/arch/x86/kvm/svm/sev.c b/arch/x86/kvm/svm/sev.c index a16c873b3232..6589091e8ce0 100644 --- a/arch/x86/kvm/svm/sev.c +++ b/arch/x86/kvm/svm/sev.c @@ -2549,6 +2549,14 @@ static int snp_launch_finish(struct kvm *kvm, struct= kvm_sev_cmd *argp) data->gctx_paddr =3D __psp_pa(sev->snp_context); ret =3D sev_issue_cmd(kvm, SEV_CMD_SNP_LAUNCH_FINISH, data, &argp->error); =20 + /* + * Now that there will be no more SNP_LAUNCH_UPDATE ioctls, private pages + * can be given to the guest simply by marking the RMP entry as private. + * This can happen on first access and also with KVM_PRE_FAULT_MEMORY. + */ + if (!ret) + kvm->arch.pre_fault_allowed =3D true; + kfree(id_auth); =20 e_free_id_block: diff --git a/arch/x86/kvm/svm/svm.c b/arch/x86/kvm/svm/svm.c index c115d26844f7..d6f252555ab3 100644 --- a/arch/x86/kvm/svm/svm.c +++ b/arch/x86/kvm/svm/svm.c @@ -4949,6 +4949,7 @@ static int svm_vm_init(struct kvm *kvm) to_kvm_sev_info(kvm)->need_init =3D true; =20 kvm->arch.has_private_mem =3D (type =3D=3D KVM_X86_SNP_VM); + kvm->arch.pre_fault_allowed =3D !kvm->arch.has_private_mem; } =20 if (!pause_filter_count || !pause_filter_thresh) diff --git a/arch/x86/kvm/x86.c b/arch/x86/kvm/x86.c index af6c8cf6a37a..52778689cef4 100644 --- a/arch/x86/kvm/x86.c +++ b/arch/x86/kvm/x86.c @@ -12646,6 +12646,9 @@ int kvm_arch_init_vm(struct kvm *kvm, unsigned long= type) kvm->arch.vm_type =3D type; kvm->arch.has_private_mem =3D (type =3D=3D KVM_X86_SW_PROTECTED_VM); + /* Decided by the vendor code for other VM types. */ + kvm->arch.pre_fault_allowed =3D + type =3D=3D KVM_X86_DEFAULT_VM || type =3D=3D KVM_X86_SW_PROTECTED_VM; =20 ret =3D kvm_page_track_init(kvm); if (ret) --=20 2.43.0 From nobody Mon Sep 16 19:16:18 2024 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 1077139FF2 for ; Fri, 26 Jul 2024 18:52:05 +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=1722019927; cv=none; b=Mz3dDV0gqEOteY1sJKTuJBC+2bin/w4vUjb+qhIcsaPR6nDEONhlxe4PRnFB/8pZUVRrpynZk8Zqo2wB8R/P6fw69j+r61+5EwBi7UEfBNKZQzpOfRjMpLsJq4Vk+mLv/Uy12L7kgE4MS2M0DTxxKqO2A/YvWkrWPFrz6F4jSMY= ARC-Message-Signature: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1722019927; c=relaxed/simple; bh=c9YVzEqDO40zQ3OBBViHTxLIjwogiliy+C5/MF1XVqc=; h=From:To:Cc:Subject:Date:Message-ID:In-Reply-To:References: MIME-Version:Content-Type; b=Lo8eDJSEKyQzDUJY7v9f9kMHrFyPALzXjXmJcIAxJvMYOtfL2cR1SXh5X2YuGB1O4hL6NeAte1j3TvOCBGKJra0R+95DsuMgcjmzRfer5AJDBQQEtZWPKbBCFsQJNSD0LxINX86LPKogmtg0LDNgJ7stpvghpqDlrWWa1PkQtmw= 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=UZ+SvLvu; 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="UZ+SvLvu" DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com; s=mimecast20190719; t=1722019925; 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=O9zQ9sNzJEmQ4UZRXCIvhZzfwYgz5vrNz7CYpnOR5vY=; b=UZ+SvLvum8Ki/oM5JHE5trQUb0RJFkP8rwQQURXeb46WFI1k7UlBieFArogm0n9rMy/Fvs mn6P/+qbNqoU0EN1nqYt4lsFk/dDkFEBmtOJ5G7imCFRPekwYwZpvcEJ1JeRF6Q41Yt7Yp HoBlK2qmDG9VpA9eytiNkkt5LaoAnEw= Received: from mx-prod-mc-04.mail-002.prod.us-west-2.aws.redhat.com (ec2-54-186-198-63.us-west-2.compute.amazonaws.com [54.186.198.63]) by relay.mimecast.com with ESMTP with STARTTLS (version=TLSv1.3, cipher=TLS_AES_256_GCM_SHA384) id us-mta-113-sDAKDUzLM9-O3CMsdCP6rg-1; Fri, 26 Jul 2024 14:52:01 -0400 X-MC-Unique: sDAKDUzLM9-O3CMsdCP6rg-1 Received: from mx-prod-int-01.mail-002.prod.us-west-2.aws.redhat.com (mx-prod-int-01.mail-002.prod.us-west-2.aws.redhat.com [10.30.177.4]) (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 mx-prod-mc-04.mail-002.prod.us-west-2.aws.redhat.com (Postfix) with ESMTPS id A3F391955D42; Fri, 26 Jul 2024 18:52:00 +0000 (UTC) Received: from virtlab1023.lab.eng.rdu2.redhat.com (virtlab1023.lab.eng.rdu2.redhat.com [10.8.1.187]) by mx-prod-int-01.mail-002.prod.us-west-2.aws.redhat.com (Postfix) with ESMTP id D31283000194; Fri, 26 Jul 2024 18:51:59 +0000 (UTC) From: Paolo Bonzini To: linux-kernel@vger.kernel.org, kvm@vger.kernel.org Cc: seanjc@google.com, michael.roth@amd.com Subject: [PATCH v2 02/14] KVM: guest_memfd: return folio from __kvm_gmem_get_pfn() Date: Fri, 26 Jul 2024 14:51:45 -0400 Message-ID: <20240726185157.72821-3-pbonzini@redhat.com> In-Reply-To: <20240726185157.72821-1-pbonzini@redhat.com> References: <20240726185157.72821-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.30.177.4 Content-Type: text/plain; charset="utf-8" Right now this is simply more consistent and avoids use of pfn_to_page() and put_page(). It will be put to more use in upcoming patches, to ensure that the up-to-date flag is set at the very end of both the kvm_gmem_get_pfn() and kvm_gmem_populate() flows. Reviewed-by: Michael Roth Signed-off-by: Paolo Bonzini Tested-by: Michael Roth --- virt/kvm/guest_memfd.c | 37 ++++++++++++++++++++----------------- 1 file changed, 20 insertions(+), 17 deletions(-) diff --git a/virt/kvm/guest_memfd.c b/virt/kvm/guest_memfd.c index 1c509c351261..522e1b28e7ae 100644 --- a/virt/kvm/guest_memfd.c +++ b/virt/kvm/guest_memfd.c @@ -541,34 +541,34 @@ void kvm_gmem_unbind(struct kvm_memory_slot *slot) fput(file); } =20 -static int __kvm_gmem_get_pfn(struct file *file, struct kvm_memory_slot *s= lot, - gfn_t gfn, kvm_pfn_t *pfn, int *max_order, bool prepare) +static struct folio * +__kvm_gmem_get_pfn(struct file *file, struct kvm_memory_slot *slot, + gfn_t gfn, kvm_pfn_t *pfn, int *max_order, bool prepare) { pgoff_t index =3D gfn - slot->base_gfn + slot->gmem.pgoff; struct kvm_gmem *gmem =3D file->private_data; struct folio *folio; struct page *page; - int r; =20 if (file !=3D slot->gmem.file) { WARN_ON_ONCE(slot->gmem.file); - return -EFAULT; + return ERR_PTR(-EFAULT); } =20 gmem =3D file->private_data; if (xa_load(&gmem->bindings, index) !=3D slot) { WARN_ON_ONCE(xa_load(&gmem->bindings, index)); - return -EIO; + return ERR_PTR(-EIO); } =20 folio =3D kvm_gmem_get_folio(file_inode(file), index, prepare); if (IS_ERR(folio)) - return PTR_ERR(folio); + return folio; =20 if (folio_test_hwpoison(folio)) { folio_unlock(folio); folio_put(folio); - return -EHWPOISON; + return ERR_PTR(-EHWPOISON); } =20 page =3D folio_file_page(folio, index); @@ -577,25 +577,25 @@ static int __kvm_gmem_get_pfn(struct file *file, stru= ct kvm_memory_slot *slot, if (max_order) *max_order =3D 0; =20 - r =3D 0; - folio_unlock(folio); - - return r; + return folio; } =20 int kvm_gmem_get_pfn(struct kvm *kvm, struct kvm_memory_slot *slot, gfn_t gfn, kvm_pfn_t *pfn, int *max_order) { struct file *file =3D kvm_gmem_get_file(slot); - int r; + struct folio *folio; =20 if (!file) return -EFAULT; =20 - r =3D __kvm_gmem_get_pfn(file, slot, gfn, pfn, max_order, true); + folio =3D __kvm_gmem_get_pfn(file, slot, gfn, pfn, max_order, true); fput(file); - return r; + if (IS_ERR(folio)) + return PTR_ERR(folio); + + return 0; } EXPORT_SYMBOL_GPL(kvm_gmem_get_pfn); =20 @@ -625,6 +625,7 @@ long kvm_gmem_populate(struct kvm *kvm, gfn_t start_gfn= , void __user *src, long =20 npages =3D min_t(ulong, slot->npages - (start_gfn - slot->base_gfn), npag= es); for (i =3D 0; i < npages; i +=3D (1 << max_order)) { + struct folio *folio; gfn_t gfn =3D start_gfn + i; kvm_pfn_t pfn; =20 @@ -633,9 +634,11 @@ long kvm_gmem_populate(struct kvm *kvm, gfn_t start_gf= n, void __user *src, long break; } =20 - ret =3D __kvm_gmem_get_pfn(file, slot, gfn, &pfn, &max_order, false); - if (ret) + folio =3D __kvm_gmem_get_pfn(file, slot, gfn, &pfn, &max_order, false); + if (IS_ERR(folio)) { + ret =3D PTR_ERR(folio); break; + } =20 if (!IS_ALIGNED(gfn, (1 << max_order)) || (npages - i) < (1 << max_order)) @@ -644,7 +647,7 @@ long kvm_gmem_populate(struct kvm *kvm, gfn_t start_gfn= , void __user *src, long p =3D src ? src + i * PAGE_SIZE : NULL; ret =3D post_populate(kvm, gfn, pfn, p, max_order, opaque); =20 - put_page(pfn_to_page(pfn)); + folio_put(folio); if (ret) break; } --=20 2.43.0 From nobody Mon Sep 16 19:16:18 2024 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 04DC844C8F for ; Fri, 26 Jul 2024 18:52:06 +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=1722019928; cv=none; b=APOXYuz4spDzB5mPQGimVC0KZMmQiFBjl4zt6z2Kkno6HLbW4o9c4zM71j6fNAe/x0QkiupJLcIhcc5rm9kFE2XR8340/haQryuXLEFY0nJO1JIOc+c84ZUlUFWOBpmbuK14LXLVaPuWENLmqdYQw/SCFAHPQM4CBFrYEGd7hjE= ARC-Message-Signature: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1722019928; c=relaxed/simple; bh=HnUElBeQKRL1MutPm5oCZ7vX+DXUmz4ApaPIT5WcH7E=; h=From:To:Cc:Subject:Date:Message-ID:In-Reply-To:References: MIME-Version:Content-Type; b=O7LwZpAO/hvfHCuy+X89Enph9bWGbR8PSEHFNrp3RbW5iECWLZejyhvuyp3tVf01z2GV9sypFqRaV9udEM89pCSlHQix9ZPpzTJTmcytezntol8kf8qAU2QFCyX8uliVfwqtdJ0NhNtd4aXEPTJO761b9XM9Tg9yndjux3/mvqw= 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=NNYpQo8U; 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="NNYpQo8U" DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com; s=mimecast20190719; t=1722019925; 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=rlInCC/uW0M23bzyOsgzc7VI9SzS/mJVpYI8FhQeX5c=; b=NNYpQo8U8tlBS4KKlP3J1M9Xd7wSQVrXz6Tjc3C7k4La3QkoxHsjIHUhHlb1N/en2LOmOf HWFsTNDc1Z4ZRIADyptmTjBn51tm534W40Ko4o1fUzOzrgfAvRa5dAOPJz7hox0i9NuQU9 IlVr1XW3PoceTcmg8yfhI+7jjt04jeA= Received: from mx-prod-mc-05.mail-002.prod.us-west-2.aws.redhat.com (ec2-54-186-198-63.us-west-2.compute.amazonaws.com [54.186.198.63]) by relay.mimecast.com with ESMTP with STARTTLS (version=TLSv1.3, cipher=TLS_AES_256_GCM_SHA384) id us-mta-125-zIj4yEPJO9242zJO79y3cw-1; Fri, 26 Jul 2024 14:52:02 -0400 X-MC-Unique: zIj4yEPJO9242zJO79y3cw-1 Received: from mx-prod-int-01.mail-002.prod.us-west-2.aws.redhat.com (mx-prod-int-01.mail-002.prod.us-west-2.aws.redhat.com [10.30.177.4]) (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 mx-prod-mc-05.mail-002.prod.us-west-2.aws.redhat.com (Postfix) with ESMTPS id 613D41956095; Fri, 26 Jul 2024 18:52:01 +0000 (UTC) Received: from virtlab1023.lab.eng.rdu2.redhat.com (virtlab1023.lab.eng.rdu2.redhat.com [10.8.1.187]) by mx-prod-int-01.mail-002.prod.us-west-2.aws.redhat.com (Postfix) with ESMTP id AB4B93000194; Fri, 26 Jul 2024 18:52:00 +0000 (UTC) From: Paolo Bonzini To: linux-kernel@vger.kernel.org, kvm@vger.kernel.org Cc: seanjc@google.com, michael.roth@amd.com Subject: [PATCH v2 03/14] KVM: guest_memfd: delay folio_mark_uptodate() until after successful preparation Date: Fri, 26 Jul 2024 14:51:46 -0400 Message-ID: <20240726185157.72821-4-pbonzini@redhat.com> In-Reply-To: <20240726185157.72821-1-pbonzini@redhat.com> References: <20240726185157.72821-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.30.177.4 Content-Type: text/plain; charset="utf-8" The up-to-date flag as is now is not too useful; it tells guest_memfd not to overwrite the contents of a folio, but it doesn't say that the page is ready to be mapped into the guest. For encrypted guests, mapping a private page requires that the "preparation" phase has succeeded, and at the same time the same page cannot be prepared twice. So, ensure that folio_mark_uptodate() is only called on a prepared page. If kvm_gmem_prepare_folio() or the post_populate callback fail, the folio will not be marked up-to-date; it's not a problem to call clear_highpage() again on such a page prior to the next preparation attempt. Reviewed-by: Michael Roth Signed-off-by: Paolo Bonzini Tested-by: Michael Roth --- virt/kvm/guest_memfd.c | 6 ++++-- 1 file changed, 4 insertions(+), 2 deletions(-) diff --git a/virt/kvm/guest_memfd.c b/virt/kvm/guest_memfd.c index 522e1b28e7ae..1ea632dbae57 100644 --- a/virt/kvm/guest_memfd.c +++ b/virt/kvm/guest_memfd.c @@ -73,8 +73,6 @@ static struct folio *kvm_gmem_get_folio(struct inode *ino= de, pgoff_t index, bool =20 for (i =3D 0; i < nr_pages; i++) clear_highpage(folio_page(folio, i)); - - folio_mark_uptodate(folio); } =20 if (prepare) { @@ -84,6 +82,8 @@ static struct folio *kvm_gmem_get_folio(struct inode *ino= de, pgoff_t index, bool folio_put(folio); return ERR_PTR(r); } + + folio_mark_uptodate(folio); } =20 /* @@ -646,6 +646,8 @@ long kvm_gmem_populate(struct kvm *kvm, gfn_t start_gfn= , void __user *src, long =20 p =3D src ? src + i * PAGE_SIZE : NULL; ret =3D post_populate(kvm, gfn, pfn, p, max_order, opaque); + if (!ret) + folio_mark_uptodate(folio); =20 folio_put(folio); if (ret) --=20 2.43.0 From nobody Mon Sep 16 19:16:18 2024 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 8FF141494DA for ; Fri, 26 Jul 2024 18:52: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=1722019933; cv=none; b=rdpSMBZbFC07PhJpuaZHKC60hH0q5hckaaHfaCQX9soSsw/m7D0+wby+gttoLgXDgQnziaC04Ted4lTnEeo6B2v8gWZ3ISMngK9ujSql5jfWnyaqHl8lkB4AoU5hha+y8nC4uYhb9mdCKd1w+F1X9RV3U2JGV6IYwjhNTyjzjjM= ARC-Message-Signature: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1722019933; c=relaxed/simple; bh=NDbda/Ay/1xJqArcGx0bked2NGRi+6Ohsay/zZhA/IU=; h=From:To:Cc:Subject:Date:Message-ID:In-Reply-To:References: MIME-Version:Content-Type; b=PhLX/QByp4dH2k9l6rMeNuggs+vzGpLc3TO0UNEwCZwF7z81iE1aES+lwLXJEJjoS4BylY+iIMtHCFoqRQaH1sYp4WTi6leSmyoNh7wIor0Mla7qup61RY7kFq9dD3ln/ynU1fW2pulRguPRvcrFvlnbQbXS1Pxhq3CUYL0PT2A= 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=C0Z4Gf+8; 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="C0Z4Gf+8" DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com; s=mimecast20190719; t=1722019929; 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=Ta8n6FT1C8nWR9P2nHAKq1BKuhG6d6FvblCdyS+kHxw=; b=C0Z4Gf+8pZ7HT8aIF9sKjtCY5Xl3kDeLV8lhFYJNbIzqNNVA/PmMWmvyXmVXterLeFLFvP Mfu8vhyeUFU6RKUVRh0uni036DXYStxamj+sndoXLHJKDCtoKaVgFgPI+xOm0lWyisGgw3 MzJKcotS+7kqBJ89ymXIEvzjabyK/to= Received: from mx-prod-mc-05.mail-002.prod.us-west-2.aws.redhat.com (ec2-54-186-198-63.us-west-2.compute.amazonaws.com [54.186.198.63]) by relay.mimecast.com with ESMTP with STARTTLS (version=TLSv1.3, cipher=TLS_AES_256_GCM_SHA384) id us-mta-61-Br-Vhj7bPlei2CGeHRIeOg-1; Fri, 26 Jul 2024 14:52:03 -0400 X-MC-Unique: Br-Vhj7bPlei2CGeHRIeOg-1 Received: from mx-prod-int-01.mail-002.prod.us-west-2.aws.redhat.com (mx-prod-int-01.mail-002.prod.us-west-2.aws.redhat.com [10.30.177.4]) (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 mx-prod-mc-05.mail-002.prod.us-west-2.aws.redhat.com (Postfix) with ESMTPS id 6EE881955F65; Fri, 26 Jul 2024 18:52:02 +0000 (UTC) Received: from virtlab1023.lab.eng.rdu2.redhat.com (virtlab1023.lab.eng.rdu2.redhat.com [10.8.1.187]) by mx-prod-int-01.mail-002.prod.us-west-2.aws.redhat.com (Postfix) with ESMTP id 83CEE3000194; Fri, 26 Jul 2024 18:52:01 +0000 (UTC) From: Paolo Bonzini To: linux-kernel@vger.kernel.org, kvm@vger.kernel.org Cc: seanjc@google.com, michael.roth@amd.com Subject: [PATCH v2 04/14] KVM: guest_memfd: do not go through struct page Date: Fri, 26 Jul 2024 14:51:47 -0400 Message-ID: <20240726185157.72821-5-pbonzini@redhat.com> In-Reply-To: <20240726185157.72821-1-pbonzini@redhat.com> References: <20240726185157.72821-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.30.177.4 Content-Type: text/plain; charset="utf-8" We have a perfectly usable folio, use it to retrieve the pfn and order. All that's needed is a version of folio_file_page that returns a pfn. Reviewed-by: Michael Roth Signed-off-by: Paolo Bonzini Tested-by: Michael Roth --- virt/kvm/guest_memfd.c | 27 +++++++++++++++++---------- 1 file changed, 17 insertions(+), 10 deletions(-) diff --git a/virt/kvm/guest_memfd.c b/virt/kvm/guest_memfd.c index 1ea632dbae57..5221b584288f 100644 --- a/virt/kvm/guest_memfd.c +++ b/virt/kvm/guest_memfd.c @@ -13,6 +13,18 @@ struct kvm_gmem { struct list_head entry; }; =20 +/** + * folio_file_pfn - like folio_file_page, but return a pfn. + * @folio: The folio which contains this index. + * @index: The index we want to look up. + * + * Return: The pfn for this index. + */ +static inline kvm_pfn_t folio_file_pfn(struct folio *folio, pgoff_t index) +{ + return folio_pfn(folio) + (index & (folio_nr_pages(folio) - 1)); +} + static int kvm_gmem_prepare_folio(struct inode *inode, pgoff_t index, stru= ct folio *folio) { #ifdef CONFIG_HAVE_KVM_GMEM_PREPARE @@ -22,7 +34,6 @@ static int kvm_gmem_prepare_folio(struct inode *inode, pg= off_t index, struct fol list_for_each_entry(gmem, gmem_list, entry) { struct kvm_memory_slot *slot; struct kvm *kvm =3D gmem->kvm; - struct page *page; kvm_pfn_t pfn; gfn_t gfn; int rc; @@ -34,13 +45,12 @@ static int kvm_gmem_prepare_folio(struct inode *inode, = pgoff_t index, struct fol if (!slot) continue; =20 - page =3D folio_file_page(folio, index); - pfn =3D page_to_pfn(page); + pfn =3D folio_file_pfn(folio, index); gfn =3D slot->base_gfn + index - slot->gmem.pgoff; - rc =3D kvm_arch_gmem_prepare(kvm, gfn, pfn, compound_order(compound_head= (page))); + rc =3D kvm_arch_gmem_prepare(kvm, gfn, pfn, folio_order(folio)); if (rc) { - pr_warn_ratelimited("gmem: Failed to prepare folio for index %lx GFN %l= lx PFN %llx error %d.\n", - index, gfn, pfn, rc); + pr_warn_ratelimited("gmem: Failed to prepare folio for GFN %llx PFN %ll= x error %d.\n", + gfn, pfn, rc); return rc; } } @@ -548,7 +558,6 @@ __kvm_gmem_get_pfn(struct file *file, struct kvm_memory= _slot *slot, pgoff_t index =3D gfn - slot->base_gfn + slot->gmem.pgoff; struct kvm_gmem *gmem =3D file->private_data; struct folio *folio; - struct page *page; =20 if (file !=3D slot->gmem.file) { WARN_ON_ONCE(slot->gmem.file); @@ -571,9 +580,7 @@ __kvm_gmem_get_pfn(struct file *file, struct kvm_memory= _slot *slot, return ERR_PTR(-EHWPOISON); } =20 - page =3D folio_file_page(folio, index); - - *pfn =3D page_to_pfn(page); + *pfn =3D folio_file_pfn(folio, index); if (max_order) *max_order =3D 0; =20 --=20 2.43.0 From nobody Mon Sep 16 19:16:18 2024 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 E2839149C78 for ; Fri, 26 Jul 2024 18:52:10 +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=1722019932; cv=none; b=VBnVEp00v8kx9VZduNlKIFwpSaXVQFWMMpRVbhmcJlWIXw32YqVvdEd83sS3JVsrP2IIFimAbwuci3jNUaeSKbTglcnqHh0N0at2rUwTdIWdo8xwdtXOdPTfimm4RRmcCdSOaIYF2GMfpzLRCxJaetI55wrW9m/fBfAcEeWId2s= ARC-Message-Signature: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1722019932; c=relaxed/simple; bh=1HnlQBL0vOBZ84lrHA6yeyQdIFc95bnX4c16QrKV+Bs=; h=From:To:Cc:Subject:Date:Message-ID:In-Reply-To:References: MIME-Version:Content-Type; b=iGzrJYX9VovR30AutXmrDNpTWuS9AsNR6NNdEis6xVwIwBTD0Ow0lDbS8ickEC5pXWlvN8cGR+Rm+tWoxsuMkKoZzBH5V+BWtIICFPHacN6g2KNn2CvsMoVPETFGXUOuv5OFmA6MwyssenF1IKF348P3Fua560RkINHHNHRWJtE= 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=GeY3j9Q3; 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="GeY3j9Q3" DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com; s=mimecast20190719; t=1722019930; 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=SuhCap/2b9IgG9yLnMTDbfY/3XP60mbxoJ9OrpN+C8M=; b=GeY3j9Q3DPfqcqhe9I76JpgN1xCZ5pzZQ76/XQL9fBNXlr5XU8UeE7csNY13vN1QM4gaRE Q7OM8/ph4r+qKe7Mv2ygzePRu9onFPnDNEQBcCVg/SgzaRaw1digk1zbzjl9zH1vsLIE0R pLL1BW70NN0j/e2ER5HBTb9UY7orttY= Received: from mx-prod-mc-02.mail-002.prod.us-west-2.aws.redhat.com (ec2-54-186-198-63.us-west-2.compute.amazonaws.com [54.186.198.63]) by relay.mimecast.com with ESMTP with STARTTLS (version=TLSv1.3, cipher=TLS_AES_256_GCM_SHA384) id us-mta-340-FQ18fmSdNFObSzQ2RjgnNg-1; Fri, 26 Jul 2024 14:52:05 -0400 X-MC-Unique: FQ18fmSdNFObSzQ2RjgnNg-1 Received: from mx-prod-int-01.mail-002.prod.us-west-2.aws.redhat.com (mx-prod-int-01.mail-002.prod.us-west-2.aws.redhat.com [10.30.177.4]) (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 mx-prod-mc-02.mail-002.prod.us-west-2.aws.redhat.com (Postfix) with ESMTPS id 2AB8B1955D4D; Fri, 26 Jul 2024 18:52:03 +0000 (UTC) Received: from virtlab1023.lab.eng.rdu2.redhat.com (virtlab1023.lab.eng.rdu2.redhat.com [10.8.1.187]) by mx-prod-int-01.mail-002.prod.us-west-2.aws.redhat.com (Postfix) with ESMTP id 5AEE43000197; Fri, 26 Jul 2024 18:52:02 +0000 (UTC) From: Paolo Bonzini To: linux-kernel@vger.kernel.org, kvm@vger.kernel.org Cc: seanjc@google.com, michael.roth@amd.com Subject: [PATCH v2 05/14] KVM: rename CONFIG_HAVE_KVM_GMEM_* to CONFIG_HAVE_KVM_ARCH_GMEM_* Date: Fri, 26 Jul 2024 14:51:48 -0400 Message-ID: <20240726185157.72821-6-pbonzini@redhat.com> In-Reply-To: <20240726185157.72821-1-pbonzini@redhat.com> References: <20240726185157.72821-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.30.177.4 Content-Type: text/plain; charset="utf-8" Add "ARCH" to the symbols; shortly, the "prepare" phase will include both the arch-independent step to clear out contents left in the page by the host, and the arch-dependent step enabled by CONFIG_HAVE_KVM_GMEM_PREPARE. For consistency do the same for CONFIG_HAVE_KVM_GMEM_INVALIDATE as well. Reviewed-by: Michael Roth Signed-off-by: Paolo Bonzini Tested-by: Michael Roth --- arch/x86/kvm/Kconfig | 4 ++-- arch/x86/kvm/x86.c | 4 ++-- include/linux/kvm_host.h | 4 ++-- virt/kvm/Kconfig | 4 ++-- virt/kvm/guest_memfd.c | 6 +++--- 5 files changed, 11 insertions(+), 11 deletions(-) diff --git a/arch/x86/kvm/Kconfig b/arch/x86/kvm/Kconfig index 4287a8071a3a..472a1537b7a9 100644 --- a/arch/x86/kvm/Kconfig +++ b/arch/x86/kvm/Kconfig @@ -141,8 +141,8 @@ config KVM_AMD_SEV depends on CRYPTO_DEV_SP_PSP && !(KVM_AMD=3Dy && CRYPTO_DEV_CCP_DD=3Dm) select ARCH_HAS_CC_PLATFORM select KVM_GENERIC_PRIVATE_MEM - select HAVE_KVM_GMEM_PREPARE - select HAVE_KVM_GMEM_INVALIDATE + select HAVE_KVM_ARCH_GMEM_PREPARE + select HAVE_KVM_ARCH_GMEM_INVALIDATE help Provides support for launching Encrypted VMs (SEV) and Encrypted VMs with Encrypted State (SEV-ES) on AMD processors. diff --git a/arch/x86/kvm/x86.c b/arch/x86/kvm/x86.c index 52778689cef4..4db18924b2f2 100644 --- a/arch/x86/kvm/x86.c +++ b/arch/x86/kvm/x86.c @@ -13644,7 +13644,7 @@ bool kvm_arch_no_poll(struct kvm_vcpu *vcpu) } EXPORT_SYMBOL_GPL(kvm_arch_no_poll); =20 -#ifdef CONFIG_HAVE_KVM_GMEM_PREPARE +#ifdef CONFIG_HAVE_KVM_ARCH_GMEM_PREPARE bool kvm_arch_gmem_prepare_needed(struct kvm *kvm) { return kvm->arch.vm_type =3D=3D KVM_X86_SNP_VM; @@ -13656,7 +13656,7 @@ int kvm_arch_gmem_prepare(struct kvm *kvm, gfn_t gf= n, kvm_pfn_t pfn, int max_ord } #endif =20 -#ifdef CONFIG_HAVE_KVM_GMEM_INVALIDATE +#ifdef CONFIG_HAVE_KVM_ARCH_GMEM_INVALIDATE void kvm_arch_gmem_invalidate(kvm_pfn_t start, kvm_pfn_t end) { kvm_x86_call(gmem_invalidate)(start, end); diff --git a/include/linux/kvm_host.h b/include/linux/kvm_host.h index 689e8be873a7..344d90771844 100644 --- a/include/linux/kvm_host.h +++ b/include/linux/kvm_host.h @@ -2445,7 +2445,7 @@ static inline int kvm_gmem_get_pfn(struct kvm *kvm, } #endif /* CONFIG_KVM_PRIVATE_MEM */ =20 -#ifdef CONFIG_HAVE_KVM_GMEM_PREPARE +#ifdef CONFIG_HAVE_KVM_ARCH_GMEM_PREPARE int kvm_arch_gmem_prepare(struct kvm *kvm, gfn_t gfn, kvm_pfn_t pfn, int m= ax_order); bool kvm_arch_gmem_prepare_needed(struct kvm *kvm); #endif @@ -2477,7 +2477,7 @@ typedef int (*kvm_gmem_populate_cb)(struct kvm *kvm, = gfn_t gfn, kvm_pfn_t pfn, long kvm_gmem_populate(struct kvm *kvm, gfn_t gfn, void __user *src, long = npages, kvm_gmem_populate_cb post_populate, void *opaque); =20 -#ifdef CONFIG_HAVE_KVM_GMEM_INVALIDATE +#ifdef CONFIG_HAVE_KVM_ARCH_GMEM_INVALIDATE void kvm_arch_gmem_invalidate(kvm_pfn_t start, kvm_pfn_t end); #endif =20 diff --git a/virt/kvm/Kconfig b/virt/kvm/Kconfig index b14e14cdbfb9..fd6a3010afa8 100644 --- a/virt/kvm/Kconfig +++ b/virt/kvm/Kconfig @@ -113,10 +113,10 @@ config KVM_GENERIC_PRIVATE_MEM select KVM_PRIVATE_MEM bool =20 -config HAVE_KVM_GMEM_PREPARE +config HAVE_KVM_ARCH_GMEM_PREPARE bool depends on KVM_PRIVATE_MEM =20 -config HAVE_KVM_GMEM_INVALIDATE +config HAVE_KVM_ARCH_GMEM_INVALIDATE bool depends on KVM_PRIVATE_MEM diff --git a/virt/kvm/guest_memfd.c b/virt/kvm/guest_memfd.c index 5221b584288f..76139332f2f3 100644 --- a/virt/kvm/guest_memfd.c +++ b/virt/kvm/guest_memfd.c @@ -27,7 +27,7 @@ static inline kvm_pfn_t folio_file_pfn(struct folio *foli= o, pgoff_t index) =20 static int kvm_gmem_prepare_folio(struct inode *inode, pgoff_t index, stru= ct folio *folio) { -#ifdef CONFIG_HAVE_KVM_GMEM_PREPARE +#ifdef CONFIG_HAVE_KVM_ARCH_GMEM_PREPARE struct list_head *gmem_list =3D &inode->i_mapping->i_private_list; struct kvm_gmem *gmem; =20 @@ -353,7 +353,7 @@ static int kvm_gmem_error_folio(struct address_space *m= apping, struct folio *fol return MF_DELAYED; } =20 -#ifdef CONFIG_HAVE_KVM_GMEM_INVALIDATE +#ifdef CONFIG_HAVE_KVM_ARCH_GMEM_INVALIDATE static void kvm_gmem_free_folio(struct folio *folio) { struct page *page =3D folio_page(folio, 0); @@ -368,7 +368,7 @@ static const struct address_space_operations kvm_gmem_a= ops =3D { .dirty_folio =3D noop_dirty_folio, .migrate_folio =3D kvm_gmem_migrate_folio, .error_remove_folio =3D kvm_gmem_error_folio, -#ifdef CONFIG_HAVE_KVM_GMEM_INVALIDATE +#ifdef CONFIG_HAVE_KVM_ARCH_GMEM_INVALIDATE .free_folio =3D kvm_gmem_free_folio, #endif }; --=20 2.43.0 From nobody Mon Sep 16 19:16:18 2024 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 4EFC6149E1E for ; Fri, 26 Jul 2024 18:52:11 +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=1722019933; cv=none; b=ANddvwgUKNuzUshfAe4ltf02/Y1H9WUunCGlK7XBIJsEF/Fs5qmIUxmRI1ez9g5tk3+kA/+7hnoejElTCvU/riO8pCz6k1wE4wjKgyFq+rztZOs3Ino/000JLb3qEHYBFJ1DYtMpf8s3w+jesu3s1K6N5bp4Rzh9YdVzEL/B2bo= ARC-Message-Signature: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1722019933; c=relaxed/simple; bh=eB5wvMbxqMd2gdO84ZLM6DxbjjXIhV+8XZ9H/PrfdNU=; h=From:To:Cc:Subject:Date:Message-ID:In-Reply-To:References: MIME-Version:Content-Type; b=s6XlkJbNXliCNIYvOhn0qhfhpWgkPNg3tQpFg9F98Un4E4Hx16ueDq/so3D0qZjSD3d3Y2bOagqcVrH9twrjnjmtgQS8AL8qt5J5a0f06Pd5egoD9IPz+O2B3ZiQFRJtRrwubiinYnDmVNqYqtSADT+f5s4Z7VS3S8mu+t4Us+s= 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=dXTl78dq; 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="dXTl78dq" DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com; s=mimecast20190719; t=1722019931; 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=MqNWXGOZI8rRuyocNScf5f61l7jMBqsk673rmo19d60=; b=dXTl78dqc6wMT3fVnVR+I1thkpbAOomeZ6hLsNf4yxdKO0q4LIDZcwGxTbV9tTtSEl8Hw8 u1/NPuK8bnTskS7mtKSTNR95ZfHQZDg361VDlA27U8dz5iP8qZLTcs+60il/1r3ZU2/oaE YfhqkWPOwGgTKTD69C+Wg4rop25XQAM= Received: from mx-prod-mc-01.mail-002.prod.us-west-2.aws.redhat.com (ec2-54-186-198-63.us-west-2.compute.amazonaws.com [54.186.198.63]) by relay.mimecast.com with ESMTP with STARTTLS (version=TLSv1.3, cipher=TLS_AES_256_GCM_SHA384) id us-mta-381-uI72tXPuMCyKMdRNKyBE_g-1; Fri, 26 Jul 2024 14:52:07 -0400 X-MC-Unique: uI72tXPuMCyKMdRNKyBE_g-1 Received: from mx-prod-int-01.mail-002.prod.us-west-2.aws.redhat.com (mx-prod-int-01.mail-002.prod.us-west-2.aws.redhat.com [10.30.177.4]) (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 mx-prod-mc-01.mail-002.prod.us-west-2.aws.redhat.com (Postfix) with ESMTPS id D9F731955D47; Fri, 26 Jul 2024 18:52:03 +0000 (UTC) Received: from virtlab1023.lab.eng.rdu2.redhat.com (virtlab1023.lab.eng.rdu2.redhat.com [10.8.1.187]) by mx-prod-int-01.mail-002.prod.us-west-2.aws.redhat.com (Postfix) with ESMTP id 31D6D3000194; Fri, 26 Jul 2024 18:52:03 +0000 (UTC) From: Paolo Bonzini To: linux-kernel@vger.kernel.org, kvm@vger.kernel.org Cc: seanjc@google.com, michael.roth@amd.com Subject: [PATCH v2 06/14] KVM: guest_memfd: return locked folio from __kvm_gmem_get_pfn Date: Fri, 26 Jul 2024 14:51:49 -0400 Message-ID: <20240726185157.72821-7-pbonzini@redhat.com> In-Reply-To: <20240726185157.72821-1-pbonzini@redhat.com> References: <20240726185157.72821-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.30.177.4 Content-Type: text/plain; charset="utf-8" Allow testing the up-to-date flag in the caller without taking the lock again. Reviewed-by: Michael Roth Signed-off-by: Paolo Bonzini Tested-by: Michael Roth --- virt/kvm/guest_memfd.c | 5 ++++- 1 file changed, 4 insertions(+), 1 deletion(-) diff --git a/virt/kvm/guest_memfd.c b/virt/kvm/guest_memfd.c index 76139332f2f3..9271aba9b7b3 100644 --- a/virt/kvm/guest_memfd.c +++ b/virt/kvm/guest_memfd.c @@ -59,6 +59,7 @@ static int kvm_gmem_prepare_folio(struct inode *inode, pg= off_t index, struct fol return 0; } =20 +/* Returns a locked folio on success. */ static struct folio *kvm_gmem_get_folio(struct inode *inode, pgoff_t index= , bool prepare) { struct folio *folio; @@ -551,6 +552,7 @@ void kvm_gmem_unbind(struct kvm_memory_slot *slot) fput(file); } =20 +/* Returns a locked folio on success. */ static struct folio * __kvm_gmem_get_pfn(struct file *file, struct kvm_memory_slot *slot, gfn_t gfn, kvm_pfn_t *pfn, int *max_order, bool prepare) @@ -584,7 +586,6 @@ __kvm_gmem_get_pfn(struct file *file, struct kvm_memory= _slot *slot, if (max_order) *max_order =3D 0; =20 - folio_unlock(folio); return folio; } =20 @@ -602,6 +603,7 @@ int kvm_gmem_get_pfn(struct kvm *kvm, struct kvm_memory= _slot *slot, if (IS_ERR(folio)) return PTR_ERR(folio); =20 + folio_unlock(folio); return 0; } EXPORT_SYMBOL_GPL(kvm_gmem_get_pfn); @@ -647,6 +649,7 @@ long kvm_gmem_populate(struct kvm *kvm, gfn_t start_gfn= , void __user *src, long break; } =20 + folio_unlock(folio); if (!IS_ALIGNED(gfn, (1 << max_order)) || (npages - i) < (1 << max_order)) max_order =3D 0; --=20 2.43.0 From nobody Mon Sep 16 19:16:18 2024 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 2EADA14A4D9 for ; Fri, 26 Jul 2024 18:52:13 +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=1722019936; cv=none; b=cQEXaBskh0AAAOGEaVnbVsyYm4BG6jFKAOQVQ3zTwLjnu6WM4iXjmDCHXMh650Gcc8vrzJylDr0eg5BUfbqkhL7pwPKd2HUxA56p+yA6Ajb3IX5ZIgUJp+WPDVVonnW56hiDxjSy+nnREQh9POTR/IIgQW47wr+TjsUFj5ORwo0= ARC-Message-Signature: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1722019936; c=relaxed/simple; bh=/0sKHZPgYzNq0hyes5yHbqRWSCr6Vw0yDsXxhYlzH08=; h=From:To:Cc:Subject:Date:Message-ID:In-Reply-To:References: MIME-Version:Content-Type; b=ZE9K25GA6QBdALWazGGy4k6RWL0qxjeVwWNMG7dOpm2H4aqXjO7dMBbjA91frmIdhGaHX0DCbJ56EqoyXJo16Y8RYit5F+9mjeJTvgK43LFS+iWqx8ekgi2VT0nUeaG+kQkTtFfLraGusBoks01fBM2oMVMBQyBXh5iXfuJq1dg= 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=Q2V7csl9; 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="Q2V7csl9" DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com; s=mimecast20190719; t=1722019932; 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=QGWFg9ZVhjL4mdKgfZYcs3I+NfLf4BvmOKKsaWtAvBw=; b=Q2V7csl9ny1SH48Hn8NT5K8BjjlrBdSYXcQP7jpyFOloxUcIVvoqlBp6JH0/xoHkO9Xbzs 7Kd3y4KVe7MDQY4ip32pDV6awdbXQpeBXjcSaVlgS2M8XFiV7tMRpU/kYHgrLGzQRVdFhO HeR5I6wxTm/NXTR83qtcovf1YT9TKNM= Received: from mx-prod-mc-04.mail-002.prod.us-west-2.aws.redhat.com (ec2-54-186-198-63.us-west-2.compute.amazonaws.com [54.186.198.63]) by relay.mimecast.com with ESMTP with STARTTLS (version=TLSv1.3, cipher=TLS_AES_256_GCM_SHA384) id us-mta-307-OJo7LKmTNt-aFQocPXB9Hg-1; Fri, 26 Jul 2024 14:52:05 -0400 X-MC-Unique: OJo7LKmTNt-aFQocPXB9Hg-1 Received: from mx-prod-int-01.mail-002.prod.us-west-2.aws.redhat.com (mx-prod-int-01.mail-002.prod.us-west-2.aws.redhat.com [10.30.177.4]) (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 mx-prod-mc-04.mail-002.prod.us-west-2.aws.redhat.com (Postfix) with ESMTPS id B274E1955D44; Fri, 26 Jul 2024 18:52:04 +0000 (UTC) Received: from virtlab1023.lab.eng.rdu2.redhat.com (virtlab1023.lab.eng.rdu2.redhat.com [10.8.1.187]) by mx-prod-int-01.mail-002.prod.us-west-2.aws.redhat.com (Postfix) with ESMTP id 0902C3000194; Fri, 26 Jul 2024 18:52:03 +0000 (UTC) From: Paolo Bonzini To: linux-kernel@vger.kernel.org, kvm@vger.kernel.org Cc: seanjc@google.com, michael.roth@amd.com Subject: [PATCH v2 07/14] KVM: guest_memfd: delay kvm_gmem_prepare_folio() until the memory is passed to the guest Date: Fri, 26 Jul 2024 14:51:50 -0400 Message-ID: <20240726185157.72821-8-pbonzini@redhat.com> In-Reply-To: <20240726185157.72821-1-pbonzini@redhat.com> References: <20240726185157.72821-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.30.177.4 Content-Type: text/plain; charset="utf-8" Initializing the contents of the folio on fallocate() is unnecessarily restrictive. It means that the page is registered with the firmware and then it cannot be touched anymore. In particular, this loses the possibility of using fallocate() to pre-allocate the page for SEV-SNP guests, because kvm_arch_gmem_prepare() then fails. It's only when the guest actually accesses the page (and therefore kvm_gmem_get_pfn() is called) that the page must be cleared from any stale host data and registered with the firmware. The up-to-date flag is clear if this has to be done (i.e. it is the first access and kvm_gmem_populate() has not been called). All in all, there are enough differences between kvm_gmem_get_pfn() and kvm_gmem_populate(), that it's better to separate the two flows completely. Extract the bulk of kvm_gmem_get_folio(), which take a folio and end up setting its up-to-date flag, to a new function kvm_gmem_prepare_folio(); these are now done only by the non-__-prefixed kvm_gmem_get_pfn(). As a bonus, __kvm_gmem_get_pfn() loses its ugly "bool prepare" argument. One difference is that fallocate(PUNCH_HOLE) can now race with a page fault. Potentially this causes a page to be prepared and into the filemap even after fallocate(PUNCH_HOLE). This is harmless, as it can be fixed by another hole punching operation, and can be avoided by clearing the private-page attribute prior to invoking fallocate(PUNCH_HOLE). This way, the page fault will cause an exit to user space. The previous semantics, where fallocate() could be used to prepare the pages in advance of running the guest, can be accessed with KVM_PRE_FAULT_MEMORY. For now, accessing a page in one VM will attempt to call kvm_arch_gmem_prepare() in all of those that have bound the guest_memfd. Cleaning this up is left to a separate patch. Suggested-by: Sean Christopherson Signed-off-by: Paolo Bonzini Tested-by: Michael Roth --- virt/kvm/guest_memfd.c | 110 ++++++++++++++++++++++++----------------- 1 file changed, 66 insertions(+), 44 deletions(-) diff --git a/virt/kvm/guest_memfd.c b/virt/kvm/guest_memfd.c index 9271aba9b7b3..5af278c7adba 100644 --- a/virt/kvm/guest_memfd.c +++ b/virt/kvm/guest_memfd.c @@ -25,7 +25,7 @@ static inline kvm_pfn_t folio_file_pfn(struct folio *foli= o, pgoff_t index) return folio_pfn(folio) + (index & (folio_nr_pages(folio) - 1)); } =20 -static int kvm_gmem_prepare_folio(struct inode *inode, pgoff_t index, stru= ct folio *folio) +static int __kvm_gmem_prepare_folio(struct inode *inode, pgoff_t index, st= ruct folio *folio) { #ifdef CONFIG_HAVE_KVM_ARCH_GMEM_PREPARE struct list_head *gmem_list =3D &inode->i_mapping->i_private_list; @@ -59,49 +59,63 @@ static int kvm_gmem_prepare_folio(struct inode *inode, = pgoff_t index, struct fol return 0; } =20 -/* Returns a locked folio on success. */ -static struct folio *kvm_gmem_get_folio(struct inode *inode, pgoff_t index= , bool prepare) +/* + * Process @folio, which contains @gfn, so that the guest can use it. + * The folio must be locked and the gfn must be contained in @slot. + * On successful return the guest sees a zero page so as to avoid + * leaking host data and the up-to-date flag is set. + */ +static int kvm_gmem_prepare_folio(struct file *file, struct kvm_memory_slo= t *slot, + gfn_t gfn, struct folio *folio) { - struct folio *folio; + unsigned long nr_pages, i; + pgoff_t index; + int r; =20 - /* TODO: Support huge pages. */ - folio =3D filemap_grab_folio(inode->i_mapping, index); - if (IS_ERR(folio)) - return folio; + if (folio_test_uptodate(folio)) + return 0; + + nr_pages =3D folio_nr_pages(folio); + for (i =3D 0; i < nr_pages; i++) + clear_highpage(folio_page(folio, i)); =20 /* - * Use the up-to-date flag to track whether or not the memory has been - * zeroed before being handed off to the guest. There is no backing - * storage for the memory, so the folio will remain up-to-date until - * it's removed. + * Preparing huge folios should always be safe, since it should + * be possible to split them later if needed. * - * TODO: Skip clearing pages when trusted firmware will do it when - * assigning memory to the guest. + * Right now the folio order is always going to be zero, but the + * code is ready for huge folios. The only assumption is that + * the base pgoff of memslots is naturally aligned with the + * requested page order, ensuring that huge folios can also use + * huge page table entries for GPA->HPA mapping. + * + * The order will be passed when creating the guest_memfd, and + * checked when creating memslots. */ - if (!folio_test_uptodate(folio)) { - unsigned long nr_pages =3D folio_nr_pages(folio); - unsigned long i; - - for (i =3D 0; i < nr_pages; i++) - clear_highpage(folio_page(folio, i)); - } - - if (prepare) { - int r =3D kvm_gmem_prepare_folio(inode, index, folio); - if (r < 0) { - folio_unlock(folio); - folio_put(folio); - return ERR_PTR(r); - } + WARN_ON(!IS_ALIGNED(slot->gmem.pgoff, 1 << folio_order(folio))); + index =3D gfn - slot->base_gfn + slot->gmem.pgoff; + index =3D ALIGN_DOWN(index, 1 << folio_order(folio)); =20 + r =3D __kvm_gmem_prepare_folio(file_inode(file), index, folio); + if (!r) folio_mark_uptodate(folio); - } =20 - /* - * Ignore accessed, referenced, and dirty flags. The memory is - * unevictable and there is no storage to write back to. - */ - return folio; + return r; +} + +/* + * Returns a locked folio on success. The caller is responsible for + * setting the up-to-date flag before the memory is mapped into the guest. + * There is no backing storage for the memory, so the folio will remain + * up-to-date until it's removed. + * + * Ignore accessed, referenced, and dirty flags. The memory is + * unevictable and there is no storage to write back to. + */ +static struct folio *kvm_gmem_get_folio(struct inode *inode, pgoff_t index) +{ + /* TODO: Support huge pages. */ + return filemap_grab_folio(inode->i_mapping, index); } =20 static void kvm_gmem_invalidate_begin(struct kvm_gmem *gmem, pgoff_t start, @@ -201,7 +215,7 @@ static long kvm_gmem_allocate(struct inode *inode, loff= _t offset, loff_t len) break; } =20 - folio =3D kvm_gmem_get_folio(inode, index, true); + folio =3D kvm_gmem_get_folio(inode, index); if (IS_ERR(folio)) { r =3D PTR_ERR(folio); break; @@ -555,7 +569,7 @@ void kvm_gmem_unbind(struct kvm_memory_slot *slot) /* Returns a locked folio on success. */ static struct folio * __kvm_gmem_get_pfn(struct file *file, struct kvm_memory_slot *slot, - gfn_t gfn, kvm_pfn_t *pfn, int *max_order, bool prepare) + gfn_t gfn, kvm_pfn_t *pfn, int *max_order) { pgoff_t index =3D gfn - slot->base_gfn + slot->gmem.pgoff; struct kvm_gmem *gmem =3D file->private_data; @@ -572,7 +586,7 @@ __kvm_gmem_get_pfn(struct file *file, struct kvm_memory= _slot *slot, return ERR_PTR(-EIO); } =20 - folio =3D kvm_gmem_get_folio(file_inode(file), index, prepare); + folio =3D kvm_gmem_get_folio(file_inode(file), index); if (IS_ERR(folio)) return folio; =20 @@ -594,17 +608,25 @@ int kvm_gmem_get_pfn(struct kvm *kvm, struct kvm_memo= ry_slot *slot, { struct file *file =3D kvm_gmem_get_file(slot); struct folio *folio; + int r =3D 0; =20 if (!file) return -EFAULT; =20 - folio =3D __kvm_gmem_get_pfn(file, slot, gfn, pfn, max_order, true); - fput(file); - if (IS_ERR(folio)) - return PTR_ERR(folio); + folio =3D __kvm_gmem_get_pfn(file, slot, gfn, pfn, max_order); + if (IS_ERR(folio)) { + r =3D PTR_ERR(folio); + goto out; + } =20 + r =3D kvm_gmem_prepare_folio(file, slot, gfn, folio); folio_unlock(folio); - return 0; + if (r < 0) + folio_put(folio); + +out: + fput(file); + return r; } EXPORT_SYMBOL_GPL(kvm_gmem_get_pfn); =20 @@ -643,7 +665,7 @@ long kvm_gmem_populate(struct kvm *kvm, gfn_t start_gfn= , void __user *src, long break; } =20 - folio =3D __kvm_gmem_get_pfn(file, slot, gfn, &pfn, &max_order, false); + folio =3D __kvm_gmem_get_pfn(file, slot, gfn, &pfn, &max_order); if (IS_ERR(folio)) { ret =3D PTR_ERR(folio); break; --=20 2.43.0 From nobody Mon Sep 16 19:16:18 2024 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 157ED149E17 for ; Fri, 26 Jul 2024 18:52: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=1722019933; cv=none; b=eP/rUedUyIvC04WoxCz+DZ/P9xJfc2sPU9Dan0nz+7QJ20IUq0NGk5wB2rUCPbTbxWTwSNRLN+R95+icOXZ3+1ftiCZjtYohhASypatcRBkU/VmgSQqVNeNp1xV5CgNJ8CkBL03BqRzvWV9N3ir04icv87Y9daj6r5aCZ4NKCJM= ARC-Message-Signature: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1722019933; c=relaxed/simple; bh=XSdNQoHsGUkDa3pf0xSuEozquSEJkf0oa8FSNs1tQMc=; h=From:To:Cc:Subject:Date:Message-ID:In-Reply-To:References: MIME-Version:Content-Type; b=O58LizFW7dOV41i0rNRBXWA/r6b0dFE9CaCNfKFu6+rpUHBCAhrZLPmgPMw722ZUO9KkjBradQodzTakVl7ja5XJhCoLfr0Avjpw9nXuAWIp30vIfJHaQe8KD/ltGMaSUDbOCtdMsxD64Ro6JIqbdmYuBfTFZ77nVm6zbSJa09A= 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=a/EwnLUy; 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="a/EwnLUy" DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com; s=mimecast20190719; t=1722019931; 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=TGMAXDTsfgqY90JMKJHbO1dD70msUk6Bwq2HA67kBP4=; b=a/EwnLUy2MJnvwIVi2OF4JMcNHPnWDQhK6HhqE2v3boKc7BYK3QWOlt7hoGzx/KnxtYNJX eWK/cj8+uFQk14Ixc6LFuE+cj7hULE6p2fKv5N58ryZGj2MhPzlAxtQbgFxHDic9NWDFWB piWz8ms341Uhs+l3AnczBjfZntnYVpc= Received: from mx-prod-mc-02.mail-002.prod.us-west-2.aws.redhat.com (ec2-54-186-198-63.us-west-2.compute.amazonaws.com [54.186.198.63]) by relay.mimecast.com with ESMTP with STARTTLS (version=TLSv1.3, cipher=TLS_AES_256_GCM_SHA384) id us-mta-196-hx5-ql0RN12ZrOGqrR38WA-1; Fri, 26 Jul 2024 14:52:06 -0400 X-MC-Unique: hx5-ql0RN12ZrOGqrR38WA-1 Received: from mx-prod-int-01.mail-002.prod.us-west-2.aws.redhat.com (mx-prod-int-01.mail-002.prod.us-west-2.aws.redhat.com [10.30.177.4]) (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 mx-prod-mc-02.mail-002.prod.us-west-2.aws.redhat.com (Postfix) with ESMTPS id A965C1955D57; Fri, 26 Jul 2024 18:52:05 +0000 (UTC) Received: from virtlab1023.lab.eng.rdu2.redhat.com (virtlab1023.lab.eng.rdu2.redhat.com [10.8.1.187]) by mx-prod-int-01.mail-002.prod.us-west-2.aws.redhat.com (Postfix) with ESMTP id D445F3000194; Fri, 26 Jul 2024 18:52:04 +0000 (UTC) From: Paolo Bonzini To: linux-kernel@vger.kernel.org, kvm@vger.kernel.org Cc: seanjc@google.com, michael.roth@amd.com Subject: [PATCH v2 08/14] KVM: guest_memfd: make kvm_gmem_prepare_folio() operate on a single struct kvm Date: Fri, 26 Jul 2024 14:51:51 -0400 Message-ID: <20240726185157.72821-9-pbonzini@redhat.com> In-Reply-To: <20240726185157.72821-1-pbonzini@redhat.com> References: <20240726185157.72821-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.30.177.4 Content-Type: text/plain; charset="utf-8" This is now possible because preparation is done by kvm_gmem_get_pfn() instead of fallocate(). In practice this is not a limitation, because even though guest_memfd can be bound to multiple struct kvm, for hardware implementations of confidential computing only one guest (identified by an ASID on SEV-SNP, or an HKID on TDX) will be able to access it. In the case of intra-host migration (not implemented yet for SEV-SNP, but we can use SEV-ES as an idea of how it will work), the new struct kvm inherits the same ASID and preparation need not be repeated. Reviewed-by: Michael Roth Signed-off-by: Paolo Bonzini Tested-by: Michael Roth --- virt/kvm/guest_memfd.c | 47 ++++++++++++++++-------------------------- 1 file changed, 18 insertions(+), 29 deletions(-) diff --git a/virt/kvm/guest_memfd.c b/virt/kvm/guest_memfd.c index 5af278c7adba..444ded162154 100644 --- a/virt/kvm/guest_memfd.c +++ b/virt/kvm/guest_memfd.c @@ -25,37 +25,27 @@ static inline kvm_pfn_t folio_file_pfn(struct folio *fo= lio, pgoff_t index) return folio_pfn(folio) + (index & (folio_nr_pages(folio) - 1)); } =20 -static int __kvm_gmem_prepare_folio(struct inode *inode, pgoff_t index, st= ruct folio *folio) +static int __kvm_gmem_prepare_folio(struct kvm *kvm, struct kvm_memory_slo= t *slot, + pgoff_t index, struct folio *folio) { #ifdef CONFIG_HAVE_KVM_ARCH_GMEM_PREPARE - struct list_head *gmem_list =3D &inode->i_mapping->i_private_list; - struct kvm_gmem *gmem; + kvm_pfn_t pfn; + gfn_t gfn; + int rc; =20 - list_for_each_entry(gmem, gmem_list, entry) { - struct kvm_memory_slot *slot; - struct kvm *kvm =3D gmem->kvm; - kvm_pfn_t pfn; - gfn_t gfn; - int rc; + if (!kvm_arch_gmem_prepare_needed(kvm)) + return 0; =20 - if (!kvm_arch_gmem_prepare_needed(kvm)) - continue; - - slot =3D xa_load(&gmem->bindings, index); - if (!slot) - continue; - - pfn =3D folio_file_pfn(folio, index); - gfn =3D slot->base_gfn + index - slot->gmem.pgoff; - rc =3D kvm_arch_gmem_prepare(kvm, gfn, pfn, folio_order(folio)); - if (rc) { - pr_warn_ratelimited("gmem: Failed to prepare folio for GFN %llx PFN %ll= x error %d.\n", - gfn, pfn, rc); - return rc; - } + pfn =3D folio_file_pfn(folio, index); + gfn =3D slot->base_gfn + index - slot->gmem.pgoff; + rc =3D kvm_arch_gmem_prepare(kvm, gfn, pfn, folio_order(folio)); + if (rc) { + pr_warn_ratelimited("gmem: Failed to prepare folio for index %lx GFN %ll= x PFN %llx error %d.\n", + index, gfn, pfn, rc); + return rc; } - #endif + return 0; } =20 @@ -65,7 +55,7 @@ static int __kvm_gmem_prepare_folio(struct inode *inode, = pgoff_t index, struct f * On successful return the guest sees a zero page so as to avoid * leaking host data and the up-to-date flag is set. */ -static int kvm_gmem_prepare_folio(struct file *file, struct kvm_memory_slo= t *slot, +static int kvm_gmem_prepare_folio(struct kvm *kvm, struct kvm_memory_slot = *slot, gfn_t gfn, struct folio *folio) { unsigned long nr_pages, i; @@ -95,8 +85,7 @@ static int kvm_gmem_prepare_folio(struct file *file, stru= ct kvm_memory_slot *slo WARN_ON(!IS_ALIGNED(slot->gmem.pgoff, 1 << folio_order(folio))); index =3D gfn - slot->base_gfn + slot->gmem.pgoff; index =3D ALIGN_DOWN(index, 1 << folio_order(folio)); - - r =3D __kvm_gmem_prepare_folio(file_inode(file), index, folio); + r =3D __kvm_gmem_prepare_folio(kvm, slot, index, folio); if (!r) folio_mark_uptodate(folio); =20 @@ -619,7 +608,7 @@ int kvm_gmem_get_pfn(struct kvm *kvm, struct kvm_memory= _slot *slot, goto out; } =20 - r =3D kvm_gmem_prepare_folio(file, slot, gfn, folio); + r =3D kvm_gmem_prepare_folio(kvm, slot, gfn, folio); folio_unlock(folio); if (r < 0) folio_put(folio); --=20 2.43.0 From nobody Mon Sep 16 19:16:18 2024 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 D157844C8F for ; Fri, 26 Jul 2024 18:52: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=1722019933; cv=none; b=CtNbnVh1oVA6AS5C4zgubi1gpn2w5DZNz80ATYYX0VDYDw8ue36EAXqAFxYOhR+Hfy8GS0/zvkJf6Pdivyx8ENKK1iP8SZ5lemcZlLxcKbFFNZgvgSlcOt3oubRDMEC/SCc3fsq1L7u15VHtqZKPa6ayMxpIIu30/S7wyFOzugY= ARC-Message-Signature: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1722019933; c=relaxed/simple; bh=6tNs2cHQ2RFZtPiBUBUq2AcBiZQsQu9np+t8r28UwcM=; h=From:To:Cc:Subject:Date:Message-ID:In-Reply-To:References: MIME-Version:Content-Type; b=FRvWaFrmwo+TSegV/yfCj6FGfKsOyvqhOyOYiQukEtc78gD5sHWGsOFmVHMJXR0NTkhnlLzWCxNZnx/71wfUcc60idEzb79+VI2uuYLQHEdUWYATckIvS81cm+46yXaVgmhjijdB9wRlWiI64tdPKz0MhSR4j6YYgB5MUFeLT30= 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=B65qwNnt; 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="B65qwNnt" DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com; s=mimecast20190719; t=1722019931; 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=psXS9EhBP2n6eAzjDDe2ar1r5ouEtqCtOES7FlMuMI0=; b=B65qwNntt/JOTG10DFbMOqUL6a8r9SU8O4H1XKR3Pj5YLc8UvLWaGnZIKUqGbmGB20QJa6 hFu9uR7HLZ8Y2HyFdT9Kzv7kYNgSaapFHsYEv9Zqhg7BkKS8BBfb2xnb1s/Cy029CWMzXZ x00ANlO1nXN2LMs6ryM8fz+bVfEfXwM= Received: from mx-prod-mc-04.mail-002.prod.us-west-2.aws.redhat.com (ec2-54-186-198-63.us-west-2.compute.amazonaws.com [54.186.198.63]) by relay.mimecast.com with ESMTP with STARTTLS (version=TLSv1.3, cipher=TLS_AES_256_GCM_SHA384) id us-mta-62-6-kXwFw-PTmZsx-pm4QQ0w-1; Fri, 26 Jul 2024 14:52:07 -0400 X-MC-Unique: 6-kXwFw-PTmZsx-pm4QQ0w-1 Received: from mx-prod-int-01.mail-002.prod.us-west-2.aws.redhat.com (mx-prod-int-01.mail-002.prod.us-west-2.aws.redhat.com [10.30.177.4]) (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 mx-prod-mc-04.mail-002.prod.us-west-2.aws.redhat.com (Postfix) with ESMTPS id 5FFE11955D54; Fri, 26 Jul 2024 18:52:06 +0000 (UTC) Received: from virtlab1023.lab.eng.rdu2.redhat.com (virtlab1023.lab.eng.rdu2.redhat.com [10.8.1.187]) by mx-prod-int-01.mail-002.prod.us-west-2.aws.redhat.com (Postfix) with ESMTP id AD9653000194; Fri, 26 Jul 2024 18:52:05 +0000 (UTC) From: Paolo Bonzini To: linux-kernel@vger.kernel.org, kvm@vger.kernel.org Cc: seanjc@google.com, michael.roth@amd.com Subject: [PATCH v2 09/14] KVM: remove kvm_arch_gmem_prepare_needed() Date: Fri, 26 Jul 2024 14:51:52 -0400 Message-ID: <20240726185157.72821-10-pbonzini@redhat.com> In-Reply-To: <20240726185157.72821-1-pbonzini@redhat.com> References: <20240726185157.72821-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.30.177.4 Content-Type: text/plain; charset="utf-8" It is enough to return 0 if a guest need not do any preparation. This is in fact how sev_gmem_prepare() works for non-SNP guests, and it extends naturally to Intel hosts: the x86 callback for gmem_prepare is optional and returns 0 if not defined. Reviewed-by: Michael Roth Signed-off-by: Paolo Bonzini Tested-by: Michael Roth --- arch/x86/kvm/x86.c | 5 ----- include/linux/kvm_host.h | 1 - virt/kvm/guest_memfd.c | 13 +++---------- 3 files changed, 3 insertions(+), 16 deletions(-) diff --git a/arch/x86/kvm/x86.c b/arch/x86/kvm/x86.c index 4db18924b2f2..ef3d3511e4af 100644 --- a/arch/x86/kvm/x86.c +++ b/arch/x86/kvm/x86.c @@ -13645,11 +13645,6 @@ bool kvm_arch_no_poll(struct kvm_vcpu *vcpu) EXPORT_SYMBOL_GPL(kvm_arch_no_poll); =20 #ifdef CONFIG_HAVE_KVM_ARCH_GMEM_PREPARE -bool kvm_arch_gmem_prepare_needed(struct kvm *kvm) -{ - return kvm->arch.vm_type =3D=3D KVM_X86_SNP_VM; -} - int kvm_arch_gmem_prepare(struct kvm *kvm, gfn_t gfn, kvm_pfn_t pfn, int m= ax_order) { return kvm_x86_call(gmem_prepare)(kvm, pfn, gfn, max_order); diff --git a/include/linux/kvm_host.h b/include/linux/kvm_host.h index 344d90771844..45373d42f314 100644 --- a/include/linux/kvm_host.h +++ b/include/linux/kvm_host.h @@ -2447,7 +2447,6 @@ static inline int kvm_gmem_get_pfn(struct kvm *kvm, =20 #ifdef CONFIG_HAVE_KVM_ARCH_GMEM_PREPARE int kvm_arch_gmem_prepare(struct kvm *kvm, gfn_t gfn, kvm_pfn_t pfn, int m= ax_order); -bool kvm_arch_gmem_prepare_needed(struct kvm *kvm); #endif =20 /** diff --git a/virt/kvm/guest_memfd.c b/virt/kvm/guest_memfd.c index 444ded162154..191fd42067c0 100644 --- a/virt/kvm/guest_memfd.c +++ b/virt/kvm/guest_memfd.c @@ -29,16 +29,9 @@ static int __kvm_gmem_prepare_folio(struct kvm *kvm, str= uct kvm_memory_slot *slo pgoff_t index, struct folio *folio) { #ifdef CONFIG_HAVE_KVM_ARCH_GMEM_PREPARE - kvm_pfn_t pfn; - gfn_t gfn; - int rc; - - if (!kvm_arch_gmem_prepare_needed(kvm)) - return 0; - - pfn =3D folio_file_pfn(folio, index); - gfn =3D slot->base_gfn + index - slot->gmem.pgoff; - rc =3D kvm_arch_gmem_prepare(kvm, gfn, pfn, folio_order(folio)); + kvm_pfn_t pfn =3D folio_file_pfn(folio, index); + gfn_t gfn =3D slot->base_gfn + index - slot->gmem.pgoff; + int rc =3D kvm_arch_gmem_prepare(kvm, gfn, pfn, folio_order(folio)); if (rc) { pr_warn_ratelimited("gmem: Failed to prepare folio for index %lx GFN %ll= x PFN %llx error %d.\n", index, gfn, pfn, rc); --=20 2.43.0 From nobody Mon Sep 16 19:16:18 2024 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 AE2D114D282 for ; Fri, 26 Jul 2024 18:52:13 +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=1722019935; cv=none; b=S6e4MyrT0nwoo2NEOYPPqInP2RjyyyD0cY2YiDSxvHTbtDn6JB1/CQjZzTFkfebfCbGJRyIe3oR8XKiysSO3N/s3lpmE8HOVx3l24dtnrKkZPALBKLpa4Jnp808y0n8Z2zN2zdFgL/QT0nQqN3xZ/n17G65qZt1r7Hvcxybkywg= ARC-Message-Signature: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1722019935; c=relaxed/simple; bh=ifbo9j+5kmjHjJq4lVj1MOCrJiSz5tdU3l3BsqETtIU=; h=From:To:Cc:Subject:Date:Message-ID:In-Reply-To:References: MIME-Version:Content-Type; b=HjRY4ZgOnVZGVvH/Ktkz/9CWSi/eM3F3/OIqSdyuyvI3ig0QA+l34m8pMoWnvLfOgjqHUc9eadCOZz5i88Q5x2MH/Lerkn0wEsB3OaB3afNWeUM7KEy7ZIAXtj6LzRtCX7OQN4WNxmvrWlSnqAauH5qPGOy0/U2iBeBKAWCHwE4= 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=Wkb5AEUS; 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="Wkb5AEUS" DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com; s=mimecast20190719; t=1722019932; 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=gdQXRewcaCvJ7fsXxayPldP2wYuonqZxSpjigXlrQvw=; b=Wkb5AEUSOB08tvz2Zfr6FpO4HQCB7xh2kjIfBncBHkRETNzB5NsDV/XrPb4QlifVcQOMB7 rjB9kvqTdYhf5dw9Hya2xBY7JpUYMQdTy2V5USzpIN20efXFmKGWWtvKKAzlwDafNnMc11 f8TGmaWd1Wphk3DB7corJLkavBPcajc= Received: from mx-prod-mc-05.mail-002.prod.us-west-2.aws.redhat.com (ec2-54-186-198-63.us-west-2.compute.amazonaws.com [54.186.198.63]) by relay.mimecast.com with ESMTP with STARTTLS (version=TLSv1.3, cipher=TLS_AES_256_GCM_SHA384) id us-mta-255-ehTjmrJONyikROZY9NYHeg-1; Fri, 26 Jul 2024 14:52:08 -0400 X-MC-Unique: ehTjmrJONyikROZY9NYHeg-1 Received: from mx-prod-int-04.mail-002.prod.us-west-2.aws.redhat.com (mx-prod-int-04.mail-002.prod.us-west-2.aws.redhat.com [10.30.177.40]) (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 mx-prod-mc-05.mail-002.prod.us-west-2.aws.redhat.com (Postfix) with ESMTPS id EC23F1955F66; Fri, 26 Jul 2024 18:52:07 +0000 (UTC) Received: from virtlab1023.lab.eng.rdu2.redhat.com (virtlab1023.lab.eng.rdu2.redhat.com [10.8.1.187]) by mx-prod-int-04.mail-002.prod.us-west-2.aws.redhat.com (Postfix) with ESMTP id 297A71955D42; Fri, 26 Jul 2024 18:52:07 +0000 (UTC) From: Paolo Bonzini To: linux-kernel@vger.kernel.org, kvm@vger.kernel.org Cc: seanjc@google.com, michael.roth@amd.com Subject: [PATCH v2 10/14] KVM: guest_memfd: move check for already-populated page to common code Date: Fri, 26 Jul 2024 14:51:53 -0400 Message-ID: <20240726185157.72821-11-pbonzini@redhat.com> In-Reply-To: <20240726185157.72821-1-pbonzini@redhat.com> References: <20240726185157.72821-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.0 on 10.30.177.40 Content-Type: text/plain; charset="utf-8" Do not allow populating the same page twice with startup data. In the case of SEV-SNP, for example, the firmware does not allow it anyway, since the launch-update operation is only possible on pages that are still shared in the RMP. Even if it worked, kvm_gmem_populate()'s callback is meant to have side effects such as updating launch measurements, and updating the same page twice is unlikely to have the desired results. Races between calls to the ioctl are not possible because kvm_gmem_populate() holds slots_lock and the VM should not be running. But again, even if this worked on other confidential computing technology, it doesn't matter to guest_memfd.c whether this is something fishy such as missing synchronization in userspace, or rather something intentional. One of the racers wins, and the page is initialized by either kvm_gmem_prepare_folio() or kvm_gmem_populate(). Anyway, out of paranoia, adjust sev_gmem_post_populate() anyway to use the same errno that kvm_gmem_populate() is using. Reviewed-by: Michael Roth Signed-off-by: Paolo Bonzini Tested-by: Michael Roth --- arch/x86/kvm/svm/sev.c | 2 +- virt/kvm/guest_memfd.c | 7 +++++++ 2 files changed, 8 insertions(+), 1 deletion(-) diff --git a/arch/x86/kvm/svm/sev.c b/arch/x86/kvm/svm/sev.c index 6589091e8ce0..752d2fff0f10 100644 --- a/arch/x86/kvm/svm/sev.c +++ b/arch/x86/kvm/svm/sev.c @@ -2290,7 +2290,7 @@ static int sev_gmem_post_populate(struct kvm *kvm, gf= n_t gfn_start, kvm_pfn_t pf if (ret || assigned) { pr_debug("%s: Failed to ensure GFN 0x%llx RMP entry is initial shared s= tate, ret: %d assigned: %d\n", __func__, gfn, ret, assigned); - ret =3D -EINVAL; + ret =3D ret ? -EINVAL : -EEXIST; goto err; } =20 diff --git a/virt/kvm/guest_memfd.c b/virt/kvm/guest_memfd.c index 191fd42067c0..319ec491ca47 100644 --- a/virt/kvm/guest_memfd.c +++ b/virt/kvm/guest_memfd.c @@ -653,6 +653,13 @@ long kvm_gmem_populate(struct kvm *kvm, gfn_t start_gf= n, void __user *src, long break; } =20 + if (folio_test_uptodate(folio)) { + folio_unlock(folio); + folio_put(folio); + ret =3D -EEXIST; + break; + } + folio_unlock(folio); if (!IS_ALIGNED(gfn, (1 << max_order)) || (npages - i) < (1 << max_order)) --=20 2.43.0 From nobody Mon Sep 16 19:16:18 2024 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 8B84C14F9FD for ; Fri, 26 Jul 2024 18:52:14 +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=1722019936; cv=none; b=NM7/jlZys7Mg0foohuERe7XTwjTQIAorLfYjcRT+cvobfaTOUiCQJp1TYwENG4IoLdppZPEr7JhA0IcS21GeGaeB16kKS5f46BORApxD9vltP4WYUTAhUcQDeMUw0sfijwiEYkmdLNNLiTTvHOJspLs4C58MB1GgohAa6T7uO84= ARC-Message-Signature: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1722019936; c=relaxed/simple; bh=tRmOfP51wV+9jZPLASWdFle6gQpf383/WN4M1AOGJtY=; h=From:To:Cc:Subject:Date:Message-ID:In-Reply-To:References: MIME-Version:Content-Type; b=QyfjpWwvucpivPKQ9EiWX0EwGAvT4Zt7WNARI+CfkCyE9ljjkqFbqo1025U1joh2KkL5BK+uZ1tneZ4jZ5RX+vhq+UsqO+A5ohwF+dzndD5RYyTg7JztqggzXciJ3zA8FRbZrAxgTAP6loRXWrMjhXPlnW+brlaNIM43RtXraOg= 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=K+RioNmS; 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="K+RioNmS" DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com; s=mimecast20190719; t=1722019933; 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=g+8+16JprI1cjYByMUu0g/0uxoZ4686g4X0q/5qRlUc=; b=K+RioNmSRBUxfZnazHrJ7p5Z6PgvtrB7yh/gS2gvuobczps7hwF8tXMbbGIrKbAUBujufd 6QXDV9wCBDb3JJrV5Xn+R+Z+Uxtw5ZGJGVcZiKTPbMjZKifi4EyHUAF4W8bOrRBb7mXl5u tGPtLGQANsFysxizbXdg1rHbS9FKecI= Received: from mx-prod-mc-05.mail-002.prod.us-west-2.aws.redhat.com (ec2-54-186-198-63.us-west-2.compute.amazonaws.com [54.186.198.63]) by relay.mimecast.com with ESMTP with STARTTLS (version=TLSv1.3, cipher=TLS_AES_256_GCM_SHA384) id us-mta-303-91BFzPAdN0uohizw7eeM_Q-1; Fri, 26 Jul 2024 14:52:10 -0400 X-MC-Unique: 91BFzPAdN0uohizw7eeM_Q-1 Received: from mx-prod-int-04.mail-002.prod.us-west-2.aws.redhat.com (mx-prod-int-04.mail-002.prod.us-west-2.aws.redhat.com [10.30.177.40]) (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 mx-prod-mc-05.mail-002.prod.us-west-2.aws.redhat.com (Postfix) with ESMTPS id C42FA195609F; Fri, 26 Jul 2024 18:52:08 +0000 (UTC) Received: from virtlab1023.lab.eng.rdu2.redhat.com (virtlab1023.lab.eng.rdu2.redhat.com [10.8.1.187]) by mx-prod-int-04.mail-002.prod.us-west-2.aws.redhat.com (Postfix) with ESMTP id F37401955D42; Fri, 26 Jul 2024 18:52:07 +0000 (UTC) From: Paolo Bonzini To: linux-kernel@vger.kernel.org, kvm@vger.kernel.org Cc: seanjc@google.com, michael.roth@amd.com Subject: [PATCH v2 11/14] KVM: cleanup and add shortcuts to kvm_range_has_memory_attributes() Date: Fri, 26 Jul 2024 14:51:54 -0400 Message-ID: <20240726185157.72821-12-pbonzini@redhat.com> In-Reply-To: <20240726185157.72821-1-pbonzini@redhat.com> References: <20240726185157.72821-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.0 on 10.30.177.40 Content-Type: text/plain; charset="utf-8" Use a guard to simplify early returns, and add two more easy shortcuts. If the requested attributes are invalid, the attributes xarray will never show them as set. And if testing a single page, kvm_get_memory_attributes() is more efficient. Reviewed-by: Michael Roth Signed-off-by: Paolo Bonzini Tested-by: Michael Roth --- virt/kvm/kvm_main.c | 42 ++++++++++++++++++++---------------------- 1 file changed, 20 insertions(+), 22 deletions(-) diff --git a/virt/kvm/kvm_main.c b/virt/kvm/kvm_main.c index d0788d0a72cc..30328ff2d840 100644 --- a/virt/kvm/kvm_main.c +++ b/virt/kvm/kvm_main.c @@ -2398,6 +2398,14 @@ static int kvm_vm_ioctl_clear_dirty_log(struct kvm *= kvm, #endif /* CONFIG_KVM_GENERIC_DIRTYLOG_READ_PROTECT */ =20 #ifdef CONFIG_KVM_GENERIC_MEMORY_ATTRIBUTES +static u64 kvm_supported_mem_attributes(struct kvm *kvm) +{ + if (!kvm || kvm_arch_has_private_mem(kvm)) + return KVM_MEMORY_ATTRIBUTE_PRIVATE; + + return 0; +} + /* * Returns true if _all_ gfns in the range [@start, @end) have attributes * matching @attrs. @@ -2406,40 +2414,30 @@ bool kvm_range_has_memory_attributes(struct kvm *kv= m, gfn_t start, gfn_t end, unsigned long attrs) { XA_STATE(xas, &kvm->mem_attr_array, start); + unsigned long mask =3D kvm_supported_mem_attributes(kvm); unsigned long index; - bool has_attrs; void *entry; =20 - rcu_read_lock(); + if (attrs & ~mask) + return false; =20 - if (!attrs) { - has_attrs =3D !xas_find(&xas, end - 1); - goto out; - } + if (end =3D=3D start + 1) + return kvm_get_memory_attributes(kvm, start) =3D=3D attrs; + + guard(rcu)(); + if (!attrs) + return !xas_find(&xas, end - 1); =20 - has_attrs =3D true; for (index =3D start; index < end; index++) { do { entry =3D xas_next(&xas); } while (xas_retry(&xas, entry)); =20 - if (xas.xa_index !=3D index || xa_to_value(entry) !=3D attrs) { - has_attrs =3D false; - break; - } + if (xas.xa_index !=3D index || xa_to_value(entry) !=3D attrs) + return false; } =20 -out: - rcu_read_unlock(); - return has_attrs; -} - -static u64 kvm_supported_mem_attributes(struct kvm *kvm) -{ - if (!kvm || kvm_arch_has_private_mem(kvm)) - return KVM_MEMORY_ATTRIBUTE_PRIVATE; - - return 0; + return true; } =20 static __always_inline void kvm_handle_gfn_range(struct kvm *kvm, --=20 2.43.0 From nobody Mon Sep 16 19:16:18 2024 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 5C37914A609 for ; Fri, 26 Jul 2024 18:52:12 +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=1722019935; cv=none; b=k1LRqDMXOlTJnS/b2vPVJgWa4fh6yNiIPsbMfr7zj2XPvuuJydQSZW4MwYr7HW6Oeq4sX7JJWRkOJcP2ffdV9e+TJXLt1xMP/zRrK7ySo35Fz1ZB3hJQOrn3YQJ4nW/QRLB7PhyQfqp4GTJopKdtVE5LEmbgojnZC9ckNLW1sow= ARC-Message-Signature: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1722019935; c=relaxed/simple; bh=x4AfumXRuUCrNKB6jGzTbTufQ1jRbPyGvuGx17eLLto=; h=From:To:Cc:Subject:Date:Message-ID:In-Reply-To:References: MIME-Version:Content-Type; b=N33KAsF+Y0XBAT0ClVXhDV34K/uEfMooVx0uJi6ClNSzYJ6mfarRpoxaAF7IQ8tKAFqI0fqioDQZ3st5NsgqX3utwnsTAjUGMOYJsfiBPrHPOcnagNQWf8ELPJU2+4hwGnvljJWH/+XiNiGSR1G1NRZTDvcVRP6JIHFhTluFJ5M= 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=GWe+pKb/; 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="GWe+pKb/" DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com; s=mimecast20190719; t=1722019932; 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=5w5ujZ9fSBKXaelT1PuJvq5xKuklIJNHvITw2V7T7/A=; b=GWe+pKb/xsQImmEF2hQxHwSPKQ2qn6eI/gjv3ABx31zb3dwQpzU1LO3dsZBamYd6U8tIa2 8xygDlSLCXbTIWHNv2clTBiwUsEH/O2UHfDw/S+9GuK04To3CfkojtCw26KIHR8vA541Yp ZtR3Hco2MHRS56GdegA6Ru4t+HirDLI= Received: from mx-prod-mc-01.mail-002.prod.us-west-2.aws.redhat.com (ec2-54-186-198-63.us-west-2.compute.amazonaws.com [54.186.198.63]) by relay.mimecast.com with ESMTP with STARTTLS (version=TLSv1.3, cipher=TLS_AES_256_GCM_SHA384) id us-mta-518-62SZjsF0M7GaoSG11ZcByQ-1; Fri, 26 Jul 2024 14:52:10 -0400 X-MC-Unique: 62SZjsF0M7GaoSG11ZcByQ-1 Received: from mx-prod-int-04.mail-002.prod.us-west-2.aws.redhat.com (mx-prod-int-04.mail-002.prod.us-west-2.aws.redhat.com [10.30.177.40]) (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 mx-prod-mc-01.mail-002.prod.us-west-2.aws.redhat.com (Postfix) with ESMTPS id 7F9871955D53; Fri, 26 Jul 2024 18:52:09 +0000 (UTC) Received: from virtlab1023.lab.eng.rdu2.redhat.com (virtlab1023.lab.eng.rdu2.redhat.com [10.8.1.187]) by mx-prod-int-04.mail-002.prod.us-west-2.aws.redhat.com (Postfix) with ESMTP id C9D3E1955D42; Fri, 26 Jul 2024 18:52:08 +0000 (UTC) From: Paolo Bonzini To: linux-kernel@vger.kernel.org, kvm@vger.kernel.org Cc: seanjc@google.com, michael.roth@amd.com Subject: [PATCH v2 12/14] KVM: extend kvm_range_has_memory_attributes() to check subset of attributes Date: Fri, 26 Jul 2024 14:51:55 -0400 Message-ID: <20240726185157.72821-13-pbonzini@redhat.com> In-Reply-To: <20240726185157.72821-1-pbonzini@redhat.com> References: <20240726185157.72821-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.0 on 10.30.177.40 Content-Type: text/plain; charset="utf-8" While currently there is no other attribute than KVM_MEMORY_ATTRIBUTE_PRIVA= TE, KVM code such as kvm_mem_is_private() is written to expect their existence. Allow using kvm_range_has_memory_attributes() as a multi-page version of kvm_mem_is_private(), without it breaking later when more attributes are introduced. Reviewed-by: Michael Roth Signed-off-by: Paolo Bonzini Tested-by: Michael Roth --- arch/x86/kvm/mmu/mmu.c | 2 +- include/linux/kvm_host.h | 2 +- virt/kvm/kvm_main.c | 13 +++++++------ 3 files changed, 9 insertions(+), 8 deletions(-) diff --git a/arch/x86/kvm/mmu/mmu.c b/arch/x86/kvm/mmu/mmu.c index 26ef5b6ac3c1..43a02891babb 100644 --- a/arch/x86/kvm/mmu/mmu.c +++ b/arch/x86/kvm/mmu/mmu.c @@ -7513,7 +7513,7 @@ static bool hugepage_has_attrs(struct kvm *kvm, struc= t kvm_memory_slot *slot, const unsigned long end =3D start + KVM_PAGES_PER_HPAGE(level); =20 if (level =3D=3D PG_LEVEL_2M) - return kvm_range_has_memory_attributes(kvm, start, end, attrs); + return kvm_range_has_memory_attributes(kvm, start, end, ~0, attrs); =20 for (gfn =3D start; gfn < end; gfn +=3D KVM_PAGES_PER_HPAGE(level - 1)) { if (hugepage_test_mixed(slot, gfn, level - 1) || diff --git a/include/linux/kvm_host.h b/include/linux/kvm_host.h index 45373d42f314..c223b97df03e 100644 --- a/include/linux/kvm_host.h +++ b/include/linux/kvm_host.h @@ -2414,7 +2414,7 @@ static inline unsigned long kvm_get_memory_attributes= (struct kvm *kvm, gfn_t gfn } =20 bool kvm_range_has_memory_attributes(struct kvm *kvm, gfn_t start, gfn_t e= nd, - unsigned long attrs); + unsigned long mask, unsigned long attrs); bool kvm_arch_pre_set_memory_attributes(struct kvm *kvm, struct kvm_gfn_range *range); bool kvm_arch_post_set_memory_attributes(struct kvm *kvm, diff --git a/virt/kvm/kvm_main.c b/virt/kvm/kvm_main.c index 30328ff2d840..92901656a0d4 100644 --- a/virt/kvm/kvm_main.c +++ b/virt/kvm/kvm_main.c @@ -2408,21 +2408,21 @@ static u64 kvm_supported_mem_attributes(struct kvm = *kvm) =20 /* * Returns true if _all_ gfns in the range [@start, @end) have attributes - * matching @attrs. + * such that the bits in @mask match @attrs. */ bool kvm_range_has_memory_attributes(struct kvm *kvm, gfn_t start, gfn_t e= nd, - unsigned long attrs) + unsigned long mask, unsigned long attrs) { XA_STATE(xas, &kvm->mem_attr_array, start); - unsigned long mask =3D kvm_supported_mem_attributes(kvm); unsigned long index; void *entry; =20 + mask &=3D kvm_supported_mem_attributes(kvm); if (attrs & ~mask) return false; =20 if (end =3D=3D start + 1) - return kvm_get_memory_attributes(kvm, start) =3D=3D attrs; + return (kvm_get_memory_attributes(kvm, start) & mask) =3D=3D attrs; =20 guard(rcu)(); if (!attrs) @@ -2433,7 +2433,8 @@ bool kvm_range_has_memory_attributes(struct kvm *kvm,= gfn_t start, gfn_t end, entry =3D xas_next(&xas); } while (xas_retry(&xas, entry)); =20 - if (xas.xa_index !=3D index || xa_to_value(entry) !=3D attrs) + if (xas.xa_index !=3D index || + (xa_to_value(entry) & mask) !=3D attrs) return false; } =20 @@ -2532,7 +2533,7 @@ static int kvm_vm_set_mem_attributes(struct kvm *kvm,= gfn_t start, gfn_t end, mutex_lock(&kvm->slots_lock); =20 /* Nothing to do if the entire range as the desired attributes. */ - if (kvm_range_has_memory_attributes(kvm, start, end, attributes)) + if (kvm_range_has_memory_attributes(kvm, start, end, ~0, attributes)) goto out_unlock; =20 /* --=20 2.43.0 From nobody Mon Sep 16 19:16:18 2024 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 B90E6152191 for ; Fri, 26 Jul 2024 18:52:14 +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=1722019936; cv=none; b=HSPpj0WnDL/ABRK1wU1uAkQlO567u1DuQP5j9skbzpW+6xPIPA3utMUUv9mkt13I/rKSa0p0+Vg1+mEP7Q7Ls7tuaCtcIMjfxn7kHOHJPt4I/fCZX5OZiuqZLM1mC8pH++cr6yf+Y6xQlUifJ2bkr6GLrObYliJssamETUiCywA= ARC-Message-Signature: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1722019936; c=relaxed/simple; bh=0tDBMlV6BdjGUPxLFTdrrnlW+DpzyxiofMfQEx9GPg0=; h=From:To:Cc:Subject:Date:Message-ID:In-Reply-To:References: MIME-Version:Content-Type; b=lELTwZGKyWAYODO0kcv9yX4BWpPsmTyg8pfsR3rvkyq+5bDkwRzSy6jIOP/IbFUMQluTyjAtuFl1tUHmTLv6N1EJF6+XhFRkKv/mlttj6a7RU04uJQ4ydXa3JYYKtCSU5pV5DhU1r5wAc5inhCKM1vHqd56h7jhRuBWODqPM4EM= 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=DdN8nWrt; 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="DdN8nWrt" DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com; s=mimecast20190719; t=1722019933; 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=xHgc0hOcAsIllXWaInTCIOPyM0B3/9AXgNDCDrvkVDw=; b=DdN8nWrtI6LzGZhDmwy165um/0lEeCD7px20Ly9q/3uYnVLJMf6z25zxD0M5fxENPep/oI CuSbxxQR2xvr+pWHDEJdImqaASfEzuDU8Bt1+AIOZ9ZuBrcV7DW744sXcZ5DVsVjXZh1el mlJcaLbO65IEfQ/xcYY5j+u9M3rd47A= Received: from mx-prod-mc-02.mail-002.prod.us-west-2.aws.redhat.com (ec2-54-186-198-63.us-west-2.compute.amazonaws.com [54.186.198.63]) by relay.mimecast.com with ESMTP with STARTTLS (version=TLSv1.3, cipher=TLS_AES_256_GCM_SHA384) id us-mta-280-zBbzQOFNNeukgDUPMXIWMw-1; Fri, 26 Jul 2024 14:52:11 -0400 X-MC-Unique: zBbzQOFNNeukgDUPMXIWMw-1 Received: from mx-prod-int-04.mail-002.prod.us-west-2.aws.redhat.com (mx-prod-int-04.mail-002.prod.us-west-2.aws.redhat.com [10.30.177.40]) (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 mx-prod-mc-02.mail-002.prod.us-west-2.aws.redhat.com (Postfix) with ESMTPS id 524BC1955D55; Fri, 26 Jul 2024 18:52:10 +0000 (UTC) Received: from virtlab1023.lab.eng.rdu2.redhat.com (virtlab1023.lab.eng.rdu2.redhat.com [10.8.1.187]) by mx-prod-int-04.mail-002.prod.us-west-2.aws.redhat.com (Postfix) with ESMTP id A015E1955D45; Fri, 26 Jul 2024 18:52:09 +0000 (UTC) From: Paolo Bonzini To: linux-kernel@vger.kernel.org, kvm@vger.kernel.org Cc: seanjc@google.com, michael.roth@amd.com Subject: [PATCH v2 13/14] KVM: guest_memfd: let kvm_gmem_populate() operate only on private gfns Date: Fri, 26 Jul 2024 14:51:56 -0400 Message-ID: <20240726185157.72821-14-pbonzini@redhat.com> In-Reply-To: <20240726185157.72821-1-pbonzini@redhat.com> References: <20240726185157.72821-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.0 on 10.30.177.40 Content-Type: text/plain; charset="utf-8" This check is currently performed by sev_gmem_post_populate(), but it applies to all callers of kvm_gmem_populate(): the point of the function is that the memory is being encrypted and some work has to be done on all the gfns in order to encrypt them. Therefore, check the KVM_MEMORY_ATTRIBUTE_PRIVATE attribute prior to invoking the callback, and stop the operation if a shared page is encountered. Because CONFIG_KVM_PRIVATE_MEM in principle does not require attributes, this makes kvm_gmem_populate() depend on CONFIG_KVM_GENERIC_PRIVATE_MEM (which does require them). Reviewed-by: Michael Roth Signed-off-by: Paolo Bonzini Tested-by: Michael Roth --- arch/x86/kvm/svm/sev.c | 7 ------- include/linux/kvm_host.h | 2 ++ virt/kvm/guest_memfd.c | 12 ++++++++++++ 3 files changed, 14 insertions(+), 7 deletions(-) diff --git a/arch/x86/kvm/svm/sev.c b/arch/x86/kvm/svm/sev.c index 752d2fff0f10..532df12b43c5 100644 --- a/arch/x86/kvm/svm/sev.c +++ b/arch/x86/kvm/svm/sev.c @@ -2279,13 +2279,6 @@ static int sev_gmem_post_populate(struct kvm *kvm, g= fn_t gfn_start, kvm_pfn_t pf bool assigned; int level; =20 - if (!kvm_mem_is_private(kvm, gfn)) { - pr_debug("%s: Failed to ensure GFN 0x%llx has private memory attribute = set\n", - __func__, gfn); - ret =3D -EINVAL; - goto err; - } - ret =3D snp_lookup_rmpentry((u64)pfn + i, &assigned, &level); if (ret || assigned) { pr_debug("%s: Failed to ensure GFN 0x%llx RMP entry is initial shared s= tate, ret: %d assigned: %d\n", diff --git a/include/linux/kvm_host.h b/include/linux/kvm_host.h index c223b97df03e..79a6b1a63027 100644 --- a/include/linux/kvm_host.h +++ b/include/linux/kvm_host.h @@ -2449,6 +2449,7 @@ static inline int kvm_gmem_get_pfn(struct kvm *kvm, int kvm_arch_gmem_prepare(struct kvm *kvm, gfn_t gfn, kvm_pfn_t pfn, int m= ax_order); #endif =20 +#ifdef CONFIG_KVM_GENERIC_PRIVATE_MEM /** * kvm_gmem_populate() - Populate/prepare a GPA range with guest data * @@ -2475,6 +2476,7 @@ typedef int (*kvm_gmem_populate_cb)(struct kvm *kvm, = gfn_t gfn, kvm_pfn_t pfn, =20 long kvm_gmem_populate(struct kvm *kvm, gfn_t gfn, void __user *src, long = npages, kvm_gmem_populate_cb post_populate, void *opaque); +#endif =20 #ifdef CONFIG_HAVE_KVM_ARCH_GMEM_INVALIDATE void kvm_arch_gmem_invalidate(kvm_pfn_t start, kvm_pfn_t end); diff --git a/virt/kvm/guest_memfd.c b/virt/kvm/guest_memfd.c index 319ec491ca47..95e338a29910 100644 --- a/virt/kvm/guest_memfd.c +++ b/virt/kvm/guest_memfd.c @@ -612,6 +612,7 @@ int kvm_gmem_get_pfn(struct kvm *kvm, struct kvm_memory= _slot *slot, } EXPORT_SYMBOL_GPL(kvm_gmem_get_pfn); =20 +#ifdef CONFIG_KVM_GENERIC_PRIVATE_MEM long kvm_gmem_populate(struct kvm *kvm, gfn_t start_gfn, void __user *src,= long npages, kvm_gmem_populate_cb post_populate, void *opaque) { @@ -665,11 +666,21 @@ long kvm_gmem_populate(struct kvm *kvm, gfn_t start_g= fn, void __user *src, long (npages - i) < (1 << max_order)) max_order =3D 0; =20 + ret =3D -EINVAL; + while (!kvm_range_has_memory_attributes(kvm, gfn, gfn + (1 << max_order), + KVM_MEMORY_ATTRIBUTE_PRIVATE, + KVM_MEMORY_ATTRIBUTE_PRIVATE)) { + if (!max_order) + goto put_folio_and_exit; + max_order--; + } + p =3D src ? src + i * PAGE_SIZE : NULL; ret =3D post_populate(kvm, gfn, pfn, p, max_order, opaque); if (!ret) folio_mark_uptodate(folio); =20 +put_folio_and_exit: folio_put(folio); if (ret) break; @@ -681,3 +692,4 @@ long kvm_gmem_populate(struct kvm *kvm, gfn_t start_gfn= , void __user *src, long return ret && !i ? ret : i; } EXPORT_SYMBOL_GPL(kvm_gmem_populate); +#endif --=20 2.43.0 From nobody Mon Sep 16 19:16:18 2024 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 BA751154C11 for ; Fri, 26 Jul 2024 18:52:15 +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=1722019937; cv=none; b=IeWwP6Fy+/vHaPHVT8qV7zpGrMyomw7FItBVrS7b5qLDiXL5TcVcfKSwkBw5gXJIdwHl/VewUQVb2yhGQdh0wJGy5bPvnApKiLQDYNfmI52ddOLcSYFPBJo6hxisWn62G2oyLfyARL/hFaDeUFH3pXz9AFf7OAtLPVxO/8jzFso= ARC-Message-Signature: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1722019937; c=relaxed/simple; bh=rpFr9pOsEObgXhoyiV5dWdSXS+JT4JKinIpjYSGWly8=; h=From:To:Cc:Subject:Date:Message-ID:In-Reply-To:References: MIME-Version:Content-Type; b=YuZm9m0pl7k5wHs2QLPgKFKM7rosGh6eWvzWEIzYbg80A2fIsbWIDJsykav8iVBSH57MK9FfKT9IBONkZSqqpVav3ayViWdNRf0Y1S9INuDlYo+xp3H7S/i9lOksPTTlam6+h6LIUyYTKcwOAYNR9zkAtRncNCLrOKZwd54qX5Q= 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=YVkNT42d; 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="YVkNT42d" DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com; s=mimecast20190719; t=1722019934; 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=US3dKgYZQqAWMx0OaAPv4mPkaQxRte3t+Kl9UzGuOsI=; b=YVkNT42dSuxFfqXdZLGxNNLFHCkZYmeqD1roYSchFXBnqe8Ug4rOqUJXqiZgQtmicvh8fG 6e2RIabAe7ZauNFtSFosl0RAQ7cgbJsDLmbIt1HRFt3ALdui6wtVVTQ2Hb3Gp1dspALjKO gU1r0Bmm8K/KYzJ/IfXMzJ4yh5CzAF4= Received: from mx-prod-mc-04.mail-002.prod.us-west-2.aws.redhat.com (ec2-54-186-198-63.us-west-2.compute.amazonaws.com [54.186.198.63]) by relay.mimecast.com with ESMTP with STARTTLS (version=TLSv1.3, cipher=TLS_AES_256_GCM_SHA384) id us-mta-445-6EogCyumMt2baG8bGGnDaw-1; Fri, 26 Jul 2024 14:52:12 -0400 X-MC-Unique: 6EogCyumMt2baG8bGGnDaw-1 Received: from mx-prod-int-04.mail-002.prod.us-west-2.aws.redhat.com (mx-prod-int-04.mail-002.prod.us-west-2.aws.redhat.com [10.30.177.40]) (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 mx-prod-mc-04.mail-002.prod.us-west-2.aws.redhat.com (Postfix) with ESMTPS id 2BC6519560BF; Fri, 26 Jul 2024 18:52:11 +0000 (UTC) Received: from virtlab1023.lab.eng.rdu2.redhat.com (virtlab1023.lab.eng.rdu2.redhat.com [10.8.1.187]) by mx-prod-int-04.mail-002.prod.us-west-2.aws.redhat.com (Postfix) with ESMTP id 75FF81955D45; Fri, 26 Jul 2024 18:52:10 +0000 (UTC) From: Paolo Bonzini To: linux-kernel@vger.kernel.org, kvm@vger.kernel.org Cc: seanjc@google.com, michael.roth@amd.com Subject: [PATCH v2 14/14] KVM: guest_memfd: abstract how prepared folios are recorded Date: Fri, 26 Jul 2024 14:51:57 -0400 Message-ID: <20240726185157.72821-15-pbonzini@redhat.com> In-Reply-To: <20240726185157.72821-1-pbonzini@redhat.com> References: <20240726185157.72821-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.0 on 10.30.177.40 Content-Type: text/plain; charset="utf-8" Right now, large folios are not supported in guest_memfd, and therefore the= order used by kvm_gmem_populate() is always 0. In this scenario, using the up-to= -date bit to track prepared-ness is nice and easy because we have one bit availab= le per page. In the future, however, we might have large pages that are partially popula= ted; for example, in the case of SEV-SNP, if a large page has both shared and pr= ivate areas inside, it is necessary to populate it at a granularity that is small= er than that of the guest_memfd's backing store. In that case we will have to track preparedness at a 4K level, probably as a bitmap. In preparation for that, do not use explicitly folio_test_uptodate() and folio_mark_uptodate(). Return the state of the page directly from __kvm_gmem_get_pfn(), so that it is expected to apply to 2^N pages with N=3D*max_order. The function to mark a range as prepared for now takes just a folio, but is expected to take also an index and order (or something like that) when large pages are introduced. Thanks to Michael Roth for pointing out the issue with large pages. Signed-off-by: Paolo Bonzini Tested-by: Michael Roth --- virt/kvm/guest_memfd.c | 32 +++++++++++++++++++------------- 1 file changed, 19 insertions(+), 13 deletions(-) diff --git a/virt/kvm/guest_memfd.c b/virt/kvm/guest_memfd.c index 95e338a29910..f4fa5e040fd1 100644 --- a/virt/kvm/guest_memfd.c +++ b/virt/kvm/guest_memfd.c @@ -42,6 +42,11 @@ static int __kvm_gmem_prepare_folio(struct kvm *kvm, str= uct kvm_memory_slot *slo return 0; } =20 +static inline void kvm_gmem_mark_prepared(struct folio *folio) +{ + folio_mark_uptodate(folio); +} + /* * Process @folio, which contains @gfn, so that the guest can use it. * The folio must be locked and the gfn must be contained in @slot. @@ -55,9 +60,6 @@ static int kvm_gmem_prepare_folio(struct kvm *kvm, struct= kvm_memory_slot *slot, pgoff_t index; int r; =20 - if (folio_test_uptodate(folio)) - return 0; - nr_pages =3D folio_nr_pages(folio); for (i =3D 0; i < nr_pages; i++) clear_highpage(folio_page(folio, i)); @@ -80,7 +82,7 @@ static int kvm_gmem_prepare_folio(struct kvm *kvm, struct= kvm_memory_slot *slot, index =3D ALIGN_DOWN(index, 1 << folio_order(folio)); r =3D __kvm_gmem_prepare_folio(kvm, slot, index, folio); if (!r) - folio_mark_uptodate(folio); + kvm_gmem_mark_prepared(folio); =20 return r; } @@ -551,7 +553,8 @@ void kvm_gmem_unbind(struct kvm_memory_slot *slot) /* Returns a locked folio on success. */ static struct folio * __kvm_gmem_get_pfn(struct file *file, struct kvm_memory_slot *slot, - gfn_t gfn, kvm_pfn_t *pfn, int *max_order) + gfn_t gfn, kvm_pfn_t *pfn, bool *is_prepared, + int *max_order) { pgoff_t index =3D gfn - slot->base_gfn + slot->gmem.pgoff; struct kvm_gmem *gmem =3D file->private_data; @@ -582,6 +585,7 @@ __kvm_gmem_get_pfn(struct file *file, struct kvm_memory= _slot *slot, if (max_order) *max_order =3D 0; =20 + *is_prepared =3D folio_test_uptodate(folio); return folio; } =20 @@ -590,18 +594,21 @@ int kvm_gmem_get_pfn(struct kvm *kvm, struct kvm_memo= ry_slot *slot, { struct file *file =3D kvm_gmem_get_file(slot); struct folio *folio; + bool is_prepared =3D false; int r =3D 0; =20 if (!file) return -EFAULT; =20 - folio =3D __kvm_gmem_get_pfn(file, slot, gfn, pfn, max_order); + folio =3D __kvm_gmem_get_pfn(file, slot, gfn, pfn, &is_prepared, max_orde= r); if (IS_ERR(folio)) { r =3D PTR_ERR(folio); goto out; } =20 - r =3D kvm_gmem_prepare_folio(kvm, slot, gfn, folio); + if (!is_prepared) + r =3D kvm_gmem_prepare_folio(kvm, slot, gfn, folio); + folio_unlock(folio); if (r < 0) folio_put(folio); @@ -641,6 +648,7 @@ long kvm_gmem_populate(struct kvm *kvm, gfn_t start_gfn= , void __user *src, long for (i =3D 0; i < npages; i +=3D (1 << max_order)) { struct folio *folio; gfn_t gfn =3D start_gfn + i; + bool is_prepared =3D false; kvm_pfn_t pfn; =20 if (signal_pending(current)) { @@ -648,13 +656,13 @@ long kvm_gmem_populate(struct kvm *kvm, gfn_t start_g= fn, void __user *src, long break; } =20 - folio =3D __kvm_gmem_get_pfn(file, slot, gfn, &pfn, &max_order); + folio =3D __kvm_gmem_get_pfn(file, slot, gfn, &pfn, &is_prepared, &max_o= rder); if (IS_ERR(folio)) { ret =3D PTR_ERR(folio); break; } =20 - if (folio_test_uptodate(folio)) { + if (is_prepared) { folio_unlock(folio); folio_put(folio); ret =3D -EEXIST; @@ -662,9 +670,8 @@ long kvm_gmem_populate(struct kvm *kvm, gfn_t start_gfn= , void __user *src, long } =20 folio_unlock(folio); - if (!IS_ALIGNED(gfn, (1 << max_order)) || - (npages - i) < (1 << max_order)) - max_order =3D 0; + WARN_ON(!IS_ALIGNED(gfn, 1 << max_order) || + (npages - i) < (1 << max_order)); =20 ret =3D -EINVAL; while (!kvm_range_has_memory_attributes(kvm, gfn, gfn + (1 << max_order), @@ -678,7 +684,7 @@ long kvm_gmem_populate(struct kvm *kvm, gfn_t start_gfn= , void __user *src, long p =3D src ? src + i * PAGE_SIZE : NULL; ret =3D post_populate(kvm, gfn, pfn, p, max_order, opaque); if (!ret) - folio_mark_uptodate(folio); + kvm_gmem_mark_prepared(folio); =20 put_folio_and_exit: folio_put(folio); --=20 2.43.0